ChunkLoadError: Loading chunk [number] failed

Fix it yourself

Follow the repair

1. Confirm the pattern before changing anything. Check when the errors started and who they hit. ChunkLoadError reports that spike right after a deployment and affect returning visitors — while you cannot reproduce on a fresh visit — are this bug, virtually every time. Note the timing in your error tracker; it is also how you will prove the fix worked.
2. Understand why hard refresh "fixes" it — and why that is not a fix. A hard refresh throws away the cached HTML and fetches the current version, whose chunk names match the files on the server. Your users will never do this. They will see a broken page and leave. Everything below exists so the site heals itself before a human has to know anything happened.
3. Add a reload-once safety net for chunk errors. Catch the failure globally and reload — exactly once. The flag in sessionStorage is what makes it safe:

   // When a chunk fails to load, reload ONCE for fresh HTML.
   window.addEventListener("error", (event) => {
     const msg = String(event.message || event.error || "");
     if (!msg.includes("ChunkLoadError") && !msg.includes("Loading chunk")) return;
     if (sessionStorage.getItem("chunk-reloaded")) return;  // never loop
     sessionStorage.setItem("chunk-reloaded", "1");
     window.location.reload();
   }, true);
   
   // Clear the flag once the app has loaded successfully,
   // so a future deploy gets its one reload too.

   The same idea inside a React error boundary — catch the error, check the flag, reload once — works if your app already has one. One reload fetches current HTML and current chunks; if it still fails, the flag stops the cycle and the real error surfaces instead of an infinite refresh.
4. Fix the real cause: stop browsers caching the HTML. Chunks deserve long caching — their hashed names change when content does, so a cached chunk is never stale. HTML is the opposite: it is the index, and it must be fresh. Check the response headers on your page (not the chunk files): HTML should come back with Cache-Control: no-cache or a very short max-age, while static chunks can keep max-age=31536000, immutable. On most managed hosts the defaults are already right for framework builds — the problem usually arrives via a custom CDN rule or a "cache everything" setting that treats HTML like an image. Find it and exempt the HTML.
5. If your host supports it, keep the previous build's files alive. Some platforms can retain the prior deployment's static assets for a grace period, so old HTML wandering in from a cache still finds its chunks while it ages out. If yours offers asset retention or skew protection, turn it on. If it does not — many atomic-deploy hosts simply replace everything — steps 3 and 4 are the complete fix on their own.
6. Verify like a returning visitor, not a fresh one. Open your live site and keep the tab. Deploy a trivial change. Go back to the old tab and navigate around. Before the fix, this reproduces the error; after it, the worst case is one brief automatic reload. Then watch the error reports after your next real deploy — the post-deploy spike should be gone.