First look: static asset caching

Phoenix
45

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.

5 Likes
46

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.

47

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

2 Likes
48

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!

49

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.

5 Likes
50

Any updates on this feature? I would like to set my own cache-control header as well so the static files are well cached on the browser.

3 Likes
51

Yeah. This feature is awesome, but it’s missing Cache-Control headers, so I still need a CDN.

It doesn’t have to be something sophisticated. I think even something like this would work:

[[statics]]
  guest_path = "/app/public"
  url_prefix = "/public"
    [statics.headers]
    Cache-Control = XXX
2 Likes
52

What’s the status of this PR? I’m trying to figure out the best way to serve static assets with Fly.io, but configuring NGINX or Varnish for this seems like an overkill. Statics would be awesome if it allowed us to set cache-control headers and/or respected origin’s cache-control headers.

4 Likes
53

I also would like to know the status of this feature. It makes everything a lot simpler and my app is less likely to fall over serving assets from CDN-like endpoint rather than my application server!

54

We’re not actively working on this now. But, our recently launched global object store may fit the bill instead. A public bucket could host and serve your statics if you can upload them yourself.

Hooking this into [statics] would take some work, but this would be easy to implement by uploading assets in your release_command with any stock s3 client. Setting cache control headers should work, and it doesn’t require that your app be deployed in multiple regions to work.

55

Thanks for your reply Joshua, how does my app then reference the public bucket? Maybe I can build something, alternatively just putting nginx in front of the application server is also a simple option I guess?

56

Public buckets can be referenced like: https://bucket-name.fly.storage.tigris.dev/

Putting nginx in front of your app is fine too, but that means your assets are limited to being served from where your app is deployed. Putting assets into a Tigris bucket is essentially getting the ‘global’ part of a CDN without having to use a CDN, or having to run a VM everywhere you want to serve assets closer to users.

1 Like