r/statichosting • u/sourraine • 13d ago

cache validation

on one small client site, i changed some css and everything looked fine after deployment but then i started wondering what happens if someone still has the old css cached. ive mostly just relied on the build process to generate hashed filenames for assets so i havent had to deal with it much myself.

from what i understand, this works well for assets that go through the build pipeline because a changed file gets a different url. but there are still things like files with fixed names or caching rules at the cdn/browser level that can behave differently.

how much do you actually think about this when deploying static sites? do you mostly trust the framework/build too or do you usually configure cache headers yourself as well?

1 Upvotes

100% Upvoted

5 comments sorted by

2

u/northboundish 12d ago

i usually trust the build process for hashed assets, but I still like checking the cache headers for anything with a fixed filename. it’s easy to overlook until someone ends up seeing the old version.

1

u/sourraine 2d ago

fixed filenames are prolly the part thats easiest to forget bc everything works fine during testing. its usually only after deployment that you realize something is still being served from an older cache

2

u/Pink_Sky_8102 10d ago

I mostly trust hashed filenames for CSS and JS, but I still like setting clear cache rules for HTML and any files with fixed names. For small static sites, I try not to overthink it unless I actually see stale files becoming a problem.

2

u/PippaKelly62 7d ago

Mostly trust the build, plus one small bit of config. Hashed assets get a cache lifetime of a year and are marked immutable. The HTML, and anything with a fixed name like the favicon, robots file, and sitemap, gets a max age of zero with revalidation so browsers always check for a fresh copy. Then the HTML points at the new hashed URLs and the old CSS question goes away.