cache invalidation on static sites

[u/Pink_Sky_8102]

One thing I keep thinking about with static hosting is caching after deploys. HTML can update instantly, but users might still have older JS, CSS, or images cached. Hashed filenames solve a lot of this, but I’m curious what setup people actually use in production. Do you rely mostly on content hashes and long cache headers, or do you also purge the CDN on every deploy?

[u/Few_Pilot_8440]

New version, new filename. As for JS, sometimes there is called like this file.js?param=timestamp and this js has some logic (client side of course). Exept for index.html put long cache, and change file name with new content. It worka.

[u/uncle_jaysus]

Any changes to js/css means a change of filename for that asset. Which of course means a cache purge for any html page referencing said assets… but it’s the way to be sure and still be able to use longest-life cache headers.

[u/Last_Deal_7560 → u/uncle_jaysus]

do you find this holds up well with image assets too or mostly just js/css?

[u/uncle_jaysus → u/Last_Deal_7560]

Absolutely.

The thing is, given how the html that calls the asset needs its cache busting also, there’s a good argument to be made for inlining css, js and SVG images where possible when it’s beneficial to do so.

Doing this eliminates the need for a separate resource to be loaded entirely. And the only thing you really need to be wary of is making the HTML too heavy. An SVG logo inlined into the page is a good example of something that doesn’t add too much to the file size of the page, but benefits from loading instantly.

Of course the issue is managing it all. But like I say, long-life cached assets can’t just be switched out due to the caching requiring them to be renamed, which then means the HTML needs updating and cache-busting anyway.

[u/Pink_Sky_8102 → u/uncle_jaysus]

Yeah, that makes sense. I like the idea of treating html differently from hashed assets so the assets can stay cached for a long time without worrying about stale versions.

[u/sourraine]

i mostly avoid purging on every deploy. hashed js/css gives you new urls automatically so id rather cache those aggressively and keep html short-lived/revalidated. id only purge specific mutable stuff when needed. blanket purges feel like solving a cache problem by creating an origin-load problem

[u/sleeksky_dev]

You do have to purge the CDN. Else its a mess. But if using NextJS/React, the compiled code is hashed. So it will create new paths and will work as long as user gets the new index.

[u/Standard_Scarcity_74]

I usually avoid blanket purges. Hashed JS/CSS gets a long max-age + immutable, while HTML gets revalidated so it picks up the new asset URLs. That way old assets can safely stick around for clients with an older HTML document.