ChunkLoadError right after a deploy is almost always stale HTML still naming chunk hashes that the new build no longer publishes. Treat the document and the hashed assets as two cache classes: HTML (and any non-hashed entry shell) needs a short s-maxage or explicit purge on release, while content-hashed JS/CSS can carry long-lived immutable Cache-Control so POPs keep them warm. If the CDN serves yesterday’s index that points at /_next/static/chunks/478.abc.js while the bucket or origin only has 478.def.js, browsers fail the chunk fetch even though the edge is “healthy.” Align proxy_cache_valid or CDN TTL with that split, and make sure Surrogate-Key / purge tags cover the HTML paths you rewrite every build.

After each release I hit the public homepage twice and inspect Cache-Control plus the script src hashes in the HTML against what the origin just uploaded; a MISS/HIT on the document with matching chunk names is the green path. If HTML stays HIT across a deploy, purge or bump the cache key for document routes before blaming the bundler. Keep Set-Cookie and Authorization off the cacheable HTML key so personalised shells do not poison the shared entry that every anonymous client reuses.