Hi there! This is just to add a short comment saying that I’ve had a very similar issue as well, and I believe that @madhattersez is absolutely correct in his ‘guess’.
My setup is rather complex — lots of caching levels, Proton, lots of optimisations, very intricate nginx configuration, several plugins (some of which manually hacked to be compatible with PHP 8.0…). On a multi-site installation, I was getting on the Dev Console a lot of 404 errors, some related to Photon, some related to Jetpack, and, well, some related to all sorts of other plugins. It’s a mess. Here’s an example:
(index):476 GET https://<WP_PATH>/wp-content/plugins/jetpack/vendor/automattic/jetpack-lazy-images/src/js/intersectionobserver-polyfill.min.js?ver=1.1.2 net::ERR_ABORTED 404
(index):478 GET https://<WP_PATH>/wp-content/plugins/jetpack/vendor/automattic/jetpack-lazy-images/src/js/lazy-images.min.js?ver=1.1.2 net::ERR_ABORTED 404
Now, this doesn’t say much, but fortunately Brave/Chrome/Chromium’s Developer Tools will show something first (grouping many of the errors together):
Refused to apply style from '<URL>' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
This baffled me, because clearly those stylesheets are being called with the correct MIME type, i.e. type='text/css' — I checked them all, one by one, and all are correct.
So, what was going on? This wasn’t very easy to track down, but apparently, it seems that one of the many, many rules I’ve got on nginx failed to account for the extra ?ver=1.0.0 that some of the styles add (I’m not quite sure where it comes from — I guess I could check, but I’m lazy) — as a consequence, the server returned a 404 for that file (because it technically does not exist on disk, after all…), and that 404 is redirected to a ‘standard’ HTML file with some information about the error, so, naturally, when the browser gets an HTML file when it was expecting a CSS file… it complains (because HTML5 is strict with that kind of thing). And it caches the error ‘forever’.
I’ve fixed it, tweaking with the nginx configuration, and, indeed, all other browsers I’ve got installed (even MS Edge, which technically is based on Chromium) have no issue whatsoever when reloading that particular site, so I know that it’s working. Alas, my ‘main’ browser may cache those things for half an eternity, and not even restarting it will ‘fix’ the issue (I suppose it keeps a disk copy of whatever is cached on the browser, and conveniently reloads it again when it starts…). I might be able to clear all browser caches, but — gasp! — I have far too many open tabs with important things that have in cache and do not want to lose…
What was confusing me was mainly that things such as ?ver=1.0.0 are intended to work as ‘cache-busters’ — i.e. preventing the browser from caching those files, when they get reloaded. Right… unless you have the many levels of caching/optimisation I got! Ultimately, what happened was that at one of the levels, there was some sneaky URL rewriting, which automagically transformed things such as style.css?ver=1.0.0 into style.css_ver=1.0.0.html or something similar — and this was picked up at some caching level (possibly Cloudflare!) as being a legitimate, HTML file — which gets served statically and flagged for the browser to keep it for 6 months or more! And, of course, reloads/refreshes/reboots will not affect the browser, because it will still think that this pseudo-file is legitimate and ought to remain on the browser cache forever and ever… until something gets tweaked again, and, say, the stylesheet gets updated to show style.css?ver=1.0.1 instead, and then I presume that the whole caching stack will push the old file out of the browser cache and work normally…
Depending on what exactly on my complex configuration has tagged things to stay ‘forever’ on the cache, it might take a few days, weeks, or even months, until that particular website shows up again (i.e. when the browser cache expires for that particular set of files). That’s why things may ‘suddenly’ start to work again without doing anything. At least, that’s my experience…
Of course, as said, I was being lazy: I can delete all caches, not only at the browser level, but at the server(s) level as well. The only thing which I cannot directly clear is Proton (although I think that my caching plugin, WP Fastest Cache, communicates in some way with Proton and might be able to flag some files for refreshing, but I’m just wildly speculating here). And that’s why turning Jetpack off will temporarily let everything work again in perfection — the extra layers of caching & performance enhancement provided by Jetpack will be gone, the CSS file names will be slightly different this time, and the whole caching/optimisation stack will reload/refresh everything properly. Sadly, though, deactivating and reactivating Jetpack will also fail — since, once active, Jetpack/Proton will revert to whatever naming convention it uses, and all the other caches will say ‘aha, I’m sure I’ve seen this file before, let’s see if I’ve still got it in cache… oh yes, here it is!’
Gah!
Again, as said, in my case, this is not an issue with Jetpack, it’s just an unfortunate (and unwanted) side-effect from having a very complex configuration, and not all levels of the caching stack are aware of the others, so they can — and will! — interfere with each other, especially when I’m tinkering with configurations, thinking I’ve got them right this time, just to add more confusion to the whole mess…
I’m just adding this comment for the sake of completeness; if someone googles for this particular issue, they might just check their many levels of caching and optimisation and go through one by one until they can figure out which one is messing up.
But, unlike @skyandsavvy, I could navigate to https://www.jetpack.com/ and see it perfectly formatted, without errors.
