Service worker plan
Offline later, deliberately
Not shipped. A service worker is the one asset you cannot un-ship: once a browser has registered one it controls requests until it is replaced, so it goes out after the API does, not before.
Measured from the completed build on 2026-09-12 06:33 UTC (build eoCv1yhT4VQe) by npm run build && npm run measure, and committed as docs/build-report.json. The numbers are not re-derived while the page renders, because a build cannot see its own output.
HTML to precache
24599.7 KB
498 prerendered files
Assets to precache
323.4 KB
2 stylesheet + 2 fonts
Chunks on demand
76
3087.1 KB — hashed, so cache-first is safe
Shared assets
1013.5 KB
shell JS + one stylesheet + both fonts
Lightest page
31.1 KB
the smallest prerendered body
Cold offline shell
1044.6 KB
one page plus the assets above
The decision, written down
Decision: no service worker ships yet. The shell an offline reader would need (shared JS + the one stylesheet + both fonts, plus a single prerendered page) is small enough that a worker would not make the site faster today — the prerendered HTML is already one request, and the hashed assets are already cache-first. The only remaining reason to add one is offline reading, and offline reading needs the API's revalidation story first; a cache you cannot invalidate is a stale catalog, and a stale catalog is worse than no offline copy. This page is the decision record: it names the cost, the trigger and the blocker, and it will change in the same commit that ships the API hook.
What would be cached
- The stylesheet and the two font files — small, versioned by hash, and the whole visual identity of the site.
- The prerendered HTML for the pages a visitor actually reads, stored under a versioned cache name so a deploy replaces the set instead of mixing two.
- Nothing under /admin. A console cached on a device that has been handed to someone else is a data-leak shape, not a performance win.
Strategy
- Precache the shell on install, network-first for HTML, cache-first for hashed assets.
- Version the cache name with the build ID that Next already writes, so a deploy invalidates cleanly.
- Never cache a response whose URL contains a search parameter — the catalog's filters would produce an unbounded set of near-identical pages.
- Serve stale only for the changelog and the guides; the catalog is what people quote, so it revalidates.
What it needs from the API
- A way to tell a stale cache to update without a full reload (the API's revalidate hook, or a version endpoint to poll).
- A decision about how long an offline copy may be shown as current, which is a copy question as much as a caching one.
For scale: this build's static output is the whole thing a worker would cache — the numbers are on the build report page, and none of them are large enough to need a worker today. The reason to add one later is offline reading, not speed.