a year on assets, now that their URLs change

Seven days was correct while the URLs were bare: a stable name with a long life means somebody running
last week's script against this week's markup.

The site's layout now stamps every asset URL with the build's id, so a build that changes a file
changes its URL, and the HTML carrying those URLs is no-cache and revalidated every visit. The two
cannot disagree, which is what earns `immutable` and a year.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-29 23:55:19 +01:00
co-authored by Claude Opus 5
parent 94eb308e78
commit cd4cb18ccc
+8 -6
View File
@@ -245,13 +245,15 @@ const NGINX_CONF = `server {
add_header Cache-Control "public, immutable";
}
# Everything a build produces. Seven days and no more: these names are stable across builds and the
# HTML that references them is revalidated every time, so a longer life means a visitor running last
# week's stylesheet against this week's markup. Fingerprinted filenames are what would earn a year
# here, and the build does not write them.
# Everything a build produces. A year, and immutable — earned, not assumed: every asset the layout
# links carries `?v=<build id>`, so a build that changes a file changes its URL, and the HTML that
# carries the new URLs is `no-cache` and revalidated on every visit. The two cannot disagree.
#
# This was seven days for as long as the URLs were bare, which was correct then: a stable name with a
# long life means somebody running last week's script against this week's markup.
location ~* \\.(css|js|webp|png|jpg|jpeg|gif|svg|ico|mp4)$ {
expires 7d;
add_header Cache-Control "public";
expires 1y;
add_header Cache-Control "public, immutable";
}
location / {