Wrong Content-Type added to Cloudflare Pages site

Hello, I have a simple website developed using Next js. I’m using Cloudflare Pages to host the website.

In the preview deploys using dev branch everything works well. But in the production deploy, using main branch. The website is broken and there are console errors.

The console errors say Refused to execute script from 'https://annakukla.com/_next/static/chunks/framework-e70c6273bfe3f237.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled. And I see that in the production website JS files have this header content-type: text/html; charset=utf-8 which is wrong since it’s a JS file.

Is this a bug with Pages? and if so how can I remedy it?


It looks like you hit a 404. When a 404 happens we will serve your 404.html file (or index.html file if no 404.html is found). This explains why you got a HTML mime type.

1 Like

Actually no it wasn’t a 404. I changed where I deploy the website and there was a brief time where there was a 404 (this is when I think you tried to access the site).

I grew frustrated with this debugging this issue and moved my site to Vercel and it works there


We’re having the same issue. It doesn’t happen too often but when it happens hundreds of users are affected.
It’s a very localized issue. Here’s what we’ve been observing for the past two months since we started using Pages:

  • New “pages” production build automatically triggered by a merge on main
  • Builds normally, gets deployed normally
  • Website works fine for most users except a few hundreds of them who start reporting that our website “doesn’t load, it only shows a blank page”
  • Invariably, when asking for a screenshot of their browser console, we see that one or two .js assets that are part of the production bundle are served as text/html

Example of what users send us when we ask for a screenshot of their console:

  • Purging these specific JS assets from the cache fixes the issue and all our users can use the website again

@Walshy I think you might be right and for some reason, in one specific cache zone(?), a 404 got cached which then gets served to everyone in this specific zone/region.

Unfortunately it keeps happening.

It does not happen on every Cloudflare Pages production build but still, ~30% of the builds some CDN location serving the files built directly on Cloudflare Pages and served by Cloudflare try to serve a cached HTML page instead of the JS asset, while most users in other geographic locations don’t suffer from the issue.

Caching Level is standard, Cache TTL respects existing headers, nothing fancy.

Is there a way of getting Cloudflare to only purge the URL served by Cloudflare Pages after deploying production build and after the files are available on Cloudflare CDN? That way Cloudflare wouldn’t cache 404s for assets hosted on Cloudflare and we wouldn’t have this recurring issue.

Do you have any Page Rules for caching on this zone?

I do have a few pages rules, none setting any cache-related thing though. I have a page rule redirecting www. → non-www-domain, and two other page rules also doing redirects but on subdomains that are not served via Pages.

It happens way too often

Assets built and deployed by Cloudflare pages not getting served because Cloudflare cached a 404 instead. Sometimes only a single region is affected, users in a small area start complaining that the site is broken. Sometimes it’s several very distinct areas. It’s never all of them.

Only way of fixing it is purging the affected assets from the cache, and only way of detecting the issue is relying on user feedback since it has only a regional impact and often doesn’t happen where we, the devs, are located.

I experienced a similar issue when deploying my site with Cloudflare Pages.
I noticed this was happening because my JS file contained a hyphen in the name. On removing the hyphen from the Javascript file and re-deploying it worked as expected.
So it seems like a bug with Cloudflare Pages where it is returning .js files containing a hyphen (-) with a MIME type of text/html.
Hope it helps in case anyone else is encountering this issue.

similar issue here where js files in the root were being returned with no mime-type at all, no idea why or how

Refused to execute script from 'https://-------------.pages.dev/flutter.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled.
(index):46 Uncaught ReferenceError: _flutter is not defined
    at (index):46:7

Tried wrangler and manual upload deploys but was not able to get it to work correctly.
An upload of the same exact directory worked immediately with netlify… :frowning:

5 posts were split to a new topic: Wrong Content-Type