Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of “text/html”. Strict MIME type checking is enforced for module scripts per HTML spec.
Wrong mime type is served when visiting the same deployment from different domains. (https://main.dval-in.pages.dev/
https://main.dval-in.pages.dev/ will serve the correct mime type for all files, while https://staging.dval.in/ serves wrong mime types, resulting in a blank screen.
staging is cname`d to https://main.dval-in.pages.dev/
A couple of your script files were being served as text/html, but while I was trying to figure out what was going on, it changed, they are all application/javascript now, and the site works. Did you fix something?
Thanks for checking it out and trying to help me!
From what i understand is that the browser caches the response after visiting main and reuses it for staging. After clearing the cache for both pages the error returns.
The browser cache shouldn’t be shared between the two. The main cause (and the thing I was looking for) would be if something had a wrong URL, and was a 404 (“not found”), and you fixed it, but Cloudflare’s cache still had the “not found” in it. That would have a text/html mime type.
First of all, on your custom domain, don’t add any extra caching. Pages does its own caching. Second, in the Cloudflare dashboard, in your domain, try going to Caching → Configuration and purge the cache.
Also – add a 404.html page at the root so you get a proper 404 response.
I removed all custom caching configs from Cloudflare and purged the cache. Will deploy the 404 page later but im unsure if this error is related to a 404 'cause you paths resolve fine on commit url and branch url.
Not really sure what happens here but there is definetly some kind of cache sharing happening between both domains (be it cf or browser). Visiting main will always cause staging to resolve fine for a certain periode of time
It’s just a guess, but this is normally how text/html ends up where it shouldn’t be. If you don’t have a 404 page, Pages returns the index page with a 200 response code (single-page-app behavior) and that will have text/html as the content-type. That ends up in the cache and causes problems. (This is a “surprising” opinionated behavior of Pages that is totally different from how Apache and other traditional servers behave.)
That’s why I mentioned not adding any caching in the custom domain. When we see a difference between the pages.dev and the custom domain it’s often because of settings in the custom domain that shouldn’t be done with Pages sites. Basically you should let Pages be Pages and not overthink it: you don’t need anything special on top of it because Cloudflare already thought of the usual things and implemented them, so when you for example add some kind of caching you’re actually getting in the way.
I’m experiencing a similar issue since a couple of days. I’m certain it’s not a caching issue, although caching makes it more apparent.
For my custom domain CF sometimes serves the index.html of my CF Pages site for some JS / CSS files. This is irregular and sometimes a request will get served the correct JS/CSS file only seconds after/before a request that fails.
I found this post from a couple of years ago, which states:
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.
So the theory I’m currently having is that CF is experiencing some internal issues which result in some pages assets not being able to load and therefore resulting in an 404, which is then turned into the index.html of the pages site.
Couldn’t find any solution yet 
Would you mind explaining how a 404.html page would help this?
Okay, instead of a 200 you’ll get a proper 404, but in the end the issues is not that no 404 is returned, the issue is that the pages site does not serve the correct JS / CSS, although the file does exist…
Deployed a 404.html, purged caches and let them propagate for about an hour.
Still get 200 responses with text/html from cf while https://staging.dval.in/404 is available
The 404.html is probably just helping to see if its a pathing issue (= source code) or if its a general issue with cf
My thought was that the incorrect 200 response was ending up in Cloudflare’s cache. This may not be the case since the problem persists.
I inspected the responses between staging and branch deployment further and noticed that staging is served by LAX datacenter, instead of a datacenter close to my location, while branch is served from a different (closer) datacenter. Also staging responses still carry caching headers while branch deployment doesn’t.
I’m getting exactly the same issues, we serve a Svelte SPA through Cloudflare Pages. ~2 days ago new deployments started to have blank pages, the console showed the same error. Could this be related to the problems on 28 fev, https://www.cloudflarestatus.com .
Found a fix from this → Transform rules
Since my sites were serving javascript files as text/html…
I set a transform rule that for those
Same issue in, just on the Preview environment.
The @jpokan temporary solution helps.
So we observe issues since 27th Feb. around noon.
Since this problem seems to occur with several people, we can probably rule out a simple misconfiguration by one user.
Did anyone already get in touch with CF support about this?
This sadly did not address my issue. Mime types are “correct” now but the delivered files are still wrong. (Returns index.html instead of original file content or 404.html)
Am not able to contact cf due to being in free tier.
(Or is there a way to contact them regardless for issues like this?)
