Our Angular app works normally after deploying to staging, but deploying the identical build to production leaves the page broken until the SRE team purges the CDN cache. The console reports module scripts and stylesheets being refused because they were served with a text/html MIME type. It seems production may be using a stale index.html or referencing JavaScript and CSS bundles that are no longer available. How can I determine whether the root cause is index.html caching, CDN behavior, missing assets, or something else, and what should I investigate first?
3 Answers
Hashed filenames solve most fresh-load problems, but users with an already-open tab can still request lazy-loaded chunks from the previous deployment. Keep assets from the previous release available for at least a day or two, and handle Angular chunk-load failures by triggering one controlled reload. Also confirm that the CDN is forwarding the correct asset paths and isn’t rewriting missing files to the app’s HTML shell.
The text/html MIME error usually means the request for a JavaScript or CSS file is receiving an HTML 404 or fallback page instead. Check the failed asset URL in the browser’s network panel and verify its status code and response body. Also make sure your production build uses content-hashed filenames rather than reusing names like main.js or styles.css.
This is commonly caused by index.html being cached too aggressively. An old index.html can point to bundle filenames from a previous release, while those files have already been removed from the origin. Configure the CDN to avoid caching index.html, or give it a very short TTL, while allowing hashed JS and CSS files to be cached for a long time.
That explains why a new browser session may work while an existing tab still fails. Retaining the previous deployment’s chunks is safer than deleting them immediately after the rollout.