Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3

Unit 01 of 06 6 pages

The caching model

Updated 23/10/2026 01:46

What Core dna keeps a copy of and for how long, why signed-in traffic behaves differently, what stops a page being stored, what clears a stored page, and how to measure all of it. For developers and site operators on any site that serves anonymous visitors.

Read The caching tiers first: it names the six copies the platform keeps and is the map the other pages refer to. Authenticated requests and the cache then gives the rule behind every member-area and cart question: a signed-in render is never stored, but a stored page is served to everyone.

What makes a response uncacheable and preventCaching() and fragments are the two sides of one decision: what keeps a page out of the cache by accident, and how to keep a personal part out on purpose without losing the page around it. Cache invalidation says what clears itself when content is published and what never does. Measuring cache effectiveness closes the unit with the headers and timings that turn every claim above into something you can check; keep it open while you read the others.

In this unit

Read in order

01 The caching tiers Six places keep a copy of something between requests, from compiled templates to the CDN and the visitor's browser. What each one holds, for how long and what clears it, so you can tell where a stale value came from. 02 Authenticated requests and the cache The rule behind every member-area and cart performance question: a signed-in render is never stored, while a stored page is served without asking who you are. What follows for member areas, carts and public pages, and how to tell which case you are in. 03 What makes a response uncacheable The rules that decide whether a render is stored, the routes that refuse it themselves, the accidental ways a template breaks caching in either direction, query parameters, and the order to check things in when a page will not cache. 04 preventCaching() and fragments The deliberate tool for a response that differs for every visitor, where to put it so it costs one small render instead of a whole page, when not to use it, and the other cache controls on $_response. 05 Cache invalidation Saving a record clears the stored pages that showed it. What that covers, how wide a listing clear reaches, the changes it never sees, the three clear modes, what a deploy clears, and when a manual clear is the right call. 06 Measuring cache effectiveness How to tell whether a page was served from the cache or rendered, what each case costs, how to find which copy is stale, and the hit rate worth aiming for. Without this the rest of the unit is guesswork.