[kentonv]

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.

[kentonv]

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.

[kentonv]

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...

[denysvitali]

Wow. Thanks for the explanation and for being humble in considering it (partially) your mistake.

I have to admit it was quite a plot twist, but this is why I love HN: we're both users and developers at the same time!

[benadam11]

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.

[aghilmort]

seconded -- great read / info also as user of Cloudflare Pages for multiple domains

[SergeAx]

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?

[geelen]

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...

[souldeux]

interesting read, thanks for sharing this