I made the same comment on Twitter and the pm for Workers said that they are aware and are actively working on it. So I am optimistic it will improve significantly over the coming months.
Nailed it ... they were experts in firmware and systems programming and had never really done web development before (that said, they were working very hard to do a good job, just unfortunate that they were set up for failure in a lot of ways).
https://3be909f6.personal-site-v4.pages.dev/ has the updated styles but the change doesnt seem to have propagated to domain yet (made the background pure white instead of grey)
Yeah that page looks much better, not just the colors but also the headings and paragraphs are now formatted correctly.
Crazily enough, it looks like the missing files are actually a problem on our (Cloudflare's) end. We're looking into it. But a re-deploy should fix it for now, I think.
Hey Ben, we think your re-deploy solved the problem, but the old content is still being served from Cloudflare's cache for many people. Can you do a cache purge in the Cloudflare dashboard?
(It just updated for me, looks much better. But the old version might still be cached in some locations.)
The root cause was actually something we fixed last month, but it seems problems can stick around if the site was originally deployed before that fix... we're working on that.
On further investigation we think this might have been purely a caching issue, not the backend problem we originally suspected.
The problem is that your site generator produces different file names for each version, but doesn't preserve the old files. So when you upload a new version, then the old version of the assets become 404, unless they happened to be cached. But it's possible the HTML is cached and the CSS not cached, in which case people will get the old HTML which refers to a CSS file that is now 404.
This is a classic problem and we need to find a better way to solve it. In principle, though, you could manually avoid it by preserving older versions of the CSS such that they continue to be served under new versions of the site.
Alternatively, if you change the config on your domain so that it doesn't cache at all (or at least turn off the "cache everything" option), and instead rely on Cloudflare Pages itself to manage caching, that also should mostly* avoid the problem. Pages does do its own caching, so adding a second layer of caching on top of that shouldn't be necessary.
* There's still a problem if someone is unlucky enough to load the site exactly when it's being updated, but at least a refresh fixes that. We need a better answer, though...
Thanks for following up! Looks like that setting was on from an old version of the site. Probably not a super common thing for people who are onboarding to CF Pages (previously my origin was on AWS) and I migrated to Pages.
Isn't that a default behavior for modern JavaScript SPAs: bundle all the frontend code into several files with unique hash names and refer them from generic html home page? Changing hash every time code changes?
Yes, which is why Pages has some dedicated logic to help preserve assets that were "seen in the last version now gone". Unfortunately, the "cache everything" setting at the CDN overrides that. We should probably be clearer about that in the docs, and potentially we could autodetect that setting when you register your custom domain, hmmm...
I had my site fronted with CF previously w/ an origin on S3 and it cost about $0.53/mo (super cheap). CF Pages current pricing is free for unlimited bandwidth which is pretty incredible - https://pages.cloudflare.com/#pricing
