No cache headers on the static server, so every repeat visit re-validates every asset

The documented root2 server block includes only `compression.conf` — **no `expires`, no `Cache-Control` on anything**. Assets get Last-Modified/ETag only, so repeat visitors issue a conditional GET per subresource.

A department page with ~15 assets costs ~15 conditional GETs and ~15 access-log lines on every repeat view. On HTTP/1.1 with a 6-connection limit that is 2-4 extra round trips, roughly **150-250 ms added to every repeat page load**. The byte saving is near zero — 304s are tiny — the win is latency, request count and log volume.

**Important caveat:** do **not** jump straight to `immutable`. Image filenames are `sha256(xml_page_pk)`, i.e. a hash of the *page id*, not the file bytes — so replacing an image with the same name reuses the URL. Ship `30d` now; content-address the filenames before going to a year.

---

**Evidence**

```
nginx/conf.d/includes/ (per-subdomain blocks); generator/views/image.py:96
```

- Verified against: `origin/master 44ca47e (2026-07-25)`
- Verdict: **CONFIRMED**

Start by inspecting the root2 server block under nginx/conf.d/includes/ and the image filename logic at generator/views/image.py:96. Verify current static responses and configure 30-day caching without using immutable. Done means repeat asset requests receive the intended cache headers while image URLs remain safe when content changes.

Written by the indexing model from the issue text.