We should use "Cache-Control: immutable" for every file served that we're sure will never change

bitsup.blogspot.com

Submitted by nitori in meta

Since Postmill versions the filenames of all the CSS, JavaScript, SVG, and font files served, and all submitted images have their hashes as filenames, there's no point in serving 304s every browser reload because we know they're never going to change anyway. This way reloading will only load up the requested URI (which will most likely be a dynamic one anyway like / or /f/meta) and any new resources that an updated URI's resource links to. Less load for our server (since the browser will not request any immutable resource again) and faster reloading for the user!

I just noticed this while comparing the devtools network tab of Raddle and jstpst where the former does the immutable trick (probably added by its Cloudflare CDN which we don't have) and therefore don't 304 its immutable resources on a browser reload.

An addition to the nginx config could look like this:

location ~ \.(jpg|gif|png|webp|css|js|svg|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}
3

Comments

You must log in or register to comment.

nitori OP wrote

u/emma I wonder if this can also be done in Postmill proper so that sysadmins don't have to manually add the header themselves in their reverse proxies?

Sagume thinking

3

emma wrote (edited )

It certainly could be added to the nginx that Postmill includes.

Edit to add: Cloudflare doesn't add that stuff, the caching's been tweaked by me over years. I plan to document it in the Postmill wiki sometime in the future.

4

twovests wrote

Ooh I really appreciate this. We're using Caddy, so I'll have to translate the config, but that shouldn't be too hard (+ easy to reverse if I mess it up lol).

3

nitori OP wrote

Hmm I just looked at what today's Firefox does (since I used Pale Moon's devtools when I checked this out), and apparently it doesn't request the static resource again and therefore does not let the server return a 304, even if there's no Cache-Control header. I wonder what sorcery Mozilla did to determine whether a resource is immutable and therefore safe to just rely on cache when reloading... Or maybe they just decided that they shouldn't bother to look for 304 in every resource whose initiator/cause in the devtools network tab is not "document"... I don't think this aggressive caching is smart since that just increases the likelihood of outdated resources being served when the browser should've revalidated its cache. So I say go for it regardless of what mainstream browsers think lol

3