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 · The caching model

Measuring cache effectiveness

The caching model Page 6 of 34 Updated

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.

Who this is for. Anyone who has to prove a caching claim: the developer before launch, the operator after a complaint. Afterwards you can read a response's headers, time the three cases, find the stale copy, and measure a hit rate.

Every caching claim should be checked against the response itself, and the platform makes that easy: each response says how it was produced. Measure the hit rate yourself, from the response headers below.

Reading the headers

HeaderValueMeans
X-Cache-StatushitServed from the page cache, without rendering
miss, storeRendered now and stored (CDN caching for pages off)
miss, no-storeRendered and not stored (why)
Cache-Controlmax-age=N, public or private, or no-storeSeconds of life left in the stored copy; public when the CDN may keep it
Last-ModifiedA dateOn a hit: when this copy was stored
X-Authenticated0 or 1Whether the platform rendered it for a signed-in user. Always 0 on a hit

With CDN caching for pages on, a page that was just rendered and stored carries Cache-Control: public, max-age=… and no X-Cache-Status; once stored, the copy the CDN passes on says hit. The CDN adds headers of its own: on Core dna's CDN, CDN-Cache is HIT when the CDN answered, MISS when it asked the server, STALE or UPDATING while it refreshes a copy, and BYPASS when it did not cache at all.

Read them signed out: in a private browser window with the developer tools' Network panel open, or from a terminal:

Shell 
curl -s -o /dev/null -D - -w 'time to first byte: %{time_starttransfer}s\n' \
  https://www.example.com/about | grep -iE '^HTTP|x-cache-status|cache-control|last-modified|cdn-cache|time to'

What each case costs

Measured on 19 October 2026 on a production Core dna site with CDN caching for pages on, from a connection in the same country, five requests each:

CaseHow it was producedTime to first byte
CDN hitThe home page, CDN-Cache: HIT0.06 to 0.21 s
Page cache hit, CDN missThe home page with an unused query parameter: a new URL for the CDN, the same stored copy for the server0.30 to 0.37 s
RenderA not-found page, which renders on every request and is about the lightest render a site has0.51 to 0.64 s

A real content page renders slower than a not-found page, so the difference in practice is larger still. A render also costs the server: database queries, template execution, memory. A site that serves most anonymous views from the cache has capacity left for the requests that must render: the member area, the cart and the checkout.

Development is not a benchmark

On a development environment no page is stored, every template is compiled again on every request, the shared Memcached layer is not used and debugging is on. On this documentation site's development copy in October 2026, pages took 1.2 to 5.6 seconds to start answering, and more than 10 seconds on a cold first request. So:

  • A development environment never shows a hit: every response there is miss, no-store. Test caching on an environment that runs in production mode.
  • Compare development timings only with each other: before and after a template change, on the same page.
  • Whether an environment runs in production or development mode is part of its server configuration, not its name. Ask which of yours run in production mode: those are the ones that cache, and the ones to time a render on before launch.

Is this copy stale, and which one is it

When an edit does not show, find out which copy you are looking at before clearing anything:

  1. Request it signed out with curl. If curl shows the new content and your browser does not, the old copy is your browser's own. A reload fixes it for you; other visitors' browsers keep theirs until it expires.
  2. Read Last-Modified on the hit. If the copy was stored after the edit, the cache is not the problem: the edit is a draft, is unpublished, is on another record, or is a change the cache does not track (what it never sees).
  3. If CDN caching is on, add an unused query parameter, such as ?check=1. The CDN treats it as a new URL, while the page cache ignores parameters the template did not declare. New content with the parameter and old without it means the CDN's copy is the stale one.
  4. If the page cache itself is stale (a hit stored before the edit), the change did not clear it: see Cache invalidation for the changes that do not.

The hit rate worth aiming for

Two numbers are worth knowing, and you collect both yourself.

Cacheability: of the public page types, how many can be cached at all. Take one URL of each type from the sitemap, request each twice signed out, and read the second answer:

Shell check-cacheability.sh 
while read -r url; do
  curl -s -o /dev/null "$url"
  curl -s -o /dev/null -D - "$url" | tr -d '\r' | awk -v u="$url" 'tolower($1)=="x-cache-status:" {print $2, u}'
done < page-types.txt | sort

Aim for every public type to answer hit. The expected exceptions are the cart, the checkout, member pages and anything you prevented caching on deliberately. A public type that answers miss goes through the diagnostic. With CDN caching on, read CDN-Cache as well.

Hit rate: of real anonymous page views, how many are served without a render. Where CDN caching is on, the CDN's own statistics give it. Otherwise sample: request the twenty most-visited URLs from your analytics every few minutes over a day and count hit against the rest. On a content site, aim for 90% or more on those pages; this is a working target, not a platform figure. Well below it, look for three things: a lifetime set too short, a declared query parameter that splits the cache (campaign links are the usual one), or a clear mode of Purge on a site that is edited all day.

Go deeper
GuideMeasure first How-toFind out why a page is slow FAQThe first visitor to a page waits noticeably longer than the second How-toDiagnose "my change is not showing up"

Was this page helpful?

Your answer goes to the docs team.