Skip to content

Improve serving of static assets

feld requested to merge feld/pleroma:feature/static-headers into develop

Since we merged ETags it had the unintended side effect of enabling Cache-Control headers for static assets. By default Phoenix sets Cache-Control when ETags are on with the default ruleset of cache-control: public.[1] This does not set an expiration for the content, so it effectively caches forever.[2] (kinda, sorta; different browsers interpret this differently in my research)

The correct ruleset for our static assets is probably cache-control: public, no-cache which tells the client and caching proxies that these are publicly cacheable assets, but it (proxy or browser) should not serve from its cache blindly without validation (e.g, comparing the ETags).

This also enables gzip support for our static assets. Currently we are not serving the gzipped copies of our javascript, etc, even though we have it. This is redundant if your Nginx config is set to gzip uncompressed assets for clients that advertise support via Accept-Encoding header, but not everyone has that configuration (Apache, Varnish, Cloudflare, etc). Not having to gzip on the fly saves you a few CPU cycles, too.

[1] https://code.i-harness.com/en/docs/phoenix/plug/plug.static

[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Edited by feld

Merge request reports