Caching and freshness
Reuse immutable page bytes and warm templates while accepting deliberate template staleness.
Everything caches work in the memory of a warm application Lambda instance. This makes repeated navigation cheaper without adding a paid cache service or a second content registry. Each instance has its own disposable cache; restart, scaling and eviction can remove the benefit.
Page source bytes
The source-byte cache holds immutable assets by asset ID: at most 8 MiB, 128 entries, and 15 minutes per entry, with least-recently-used eviction. A new page revision has a different asset ID.
Every page fetch still selects the eligible published revision for its route. Rendering uses the tags returned by that selection, without extra tag reads before and after rendering. A concurrent tag edit can finish the current selected response; a later request selects again, subject to wf-store's eventual index visibility. This is deliberately not an atomic publication snapshot.
The byte cache does not cache page publication decisions, rendered HTML, errors or ranked search results.
Templates: no timeout
A separate cache retains a successful template selection and its validated layout definition by logical template ID. It has no time expiry and at most 64 entries, with least-recently-used eviction. The definition stays usable even after the separate byte cache expires.
Active-template changes can therefore remain stale until the entry is evicted or the instance is replaced. Different instances can temporarily show different template revisions. Reloading your browser does not flush these server caches or guarantee a different instance.
A page referring to a different template ID uses that ID's cache entry, selecting it if absent. A fresh ID can be useful when a presentation change needs a distinct identity; revisiting an already cached ID can still reuse its older definition. Missing or invalid packages and storage failures are not pinned as successful templates, so ordinary repairs can be picked up.
What a page fetch costs
A typical page with one template needs four storage calls when both are cold: page selection, page source, template selection and template source. With page bytes and the template warm, it needs one call: page selection. Expired page bytes add a content read. Pagination, media and related results are additional work.
The application also reuses its established storage connections when possible. Request deadlines still bound storage work, and public visibility is determined separately on each page selection.
There is no browser article cache or prefetch campaign, and CloudFront still does not cache page/MCP responses. Cold starts and dependency latency remain. Progressive loading provides feedback while that work happens; connection troubleshooting helps with reader-side failures.