First look: static asset caching

Something I’m noticed with statics is that the cache-control headers are set to require revalidation on every request.

Cache-Control: public, max-age=0, must-revalidate.

For websites that deploy using unique asset names it’s more common to bump up that max-age so that browsers won’t make a request to the server for a resource once it has it in the cache.

Is there a way to control the cache control for statics?

Someway to control generic headers for statics would be awesome.

2 Likes

Control over cache headers isn’t there just yet, but it might be in the works.

There’s also the possibility of using the Fly frontend as a general cache with cache headers returned by the application: First look: static asset caching - #41 by thomas - when that lands it’ll make more sense to turn off the static section and return cache (and other) headers from the application itself, and have the Fly proxy respect and pass them on.

Any news on the cache headers front? It’s an exciting feature! :heart_eyes:

1 Like

This is fantastic, really nice to have!

I’d like to upload gzip’d versions of my CSS, etc., and have it set the content-type properly so the browsers get The Right Thing™.

Thanks!

Any updates on the 304 and cache headers support? This otherwise wonderful feature saves some backend load but does nothing to optimize the browser experience without those.

3 Likes