Performance, caching, deployment and go-live

Who this is for. The site operator's guide: for the developer who ships code, the lead who owns releases and launch day, and whoever gets the call when the live site misbehaves. It assumes you can already build and render a page in a theme repository (Guide 3) and know your way around layouts and components (Guide 4). It sits at levels L2 and L3: the failure modes, and the reasons behind them.

Most of a Core dna site's speed is decided by one question: was this response served from the cache, or rendered? A rendered page runs your templates and every query they cause. A cached one is a file, read and sent before the platform has looked at cookies or connected to the database. And most deployment and launch surprises come down to one fact: code travels with a push, while pages, layouts, jobs, forms and settings live in the database and do not.

The units, in reading order

1. The caching model: the copies the platform keeps, why signed-in traffic is different, what keeps a page out of the cache, what clears it, and how to measure it. Read this first; everything after it refers back.
2. Making pages fast: measuring first, the query-per-row shapes and their fixes, component nesting, images, bundle size, fonts and third-party scripts.
3. The deployment model: what a push does, a branching flow with its hotfix path, building before you push, FTP, and CI.
4. Environments and what travels between them: telling environments apart, configuration and secrets, and moving what a push does not carry.
5. Go-live: the printable checklist and the pages behind its hardest items, redirects and test providers above all.
6. Running a site after launch: the logs, failover and maintenance, health checks, and handing the site over.

The first three units are for anyone building the site; the last three are for whoever ships it and looks after it. On a launch deadline, read units 1 and 3, then work through the checklist in unit 5.

What the platform gives you

• A page cache. Each anonymous GET that renders a 200 is stored as a file per hostname, path and declared query parameter, for Cache settings › Default cache expiration setting for pages (one day unless changed).
• Smart invalidation. A stored page remembers which records and which kinds of listing it used; saving one of those records clears it, and creating or deleting a record clears the pages that listed its kind.
• A CDN in front, for images and theme files always, and for pages when Enable CDN caching for pages is on.
• Template controls on $_response: preventCaching(), enforceCaching(), setCacheTTL(), setCacheExpiryDate() and addCacheVaryParameter().
• Headers that say what happened: X-Cache-Status and X-Authenticated on every page response.
• Git-based deploy. A push to the branch an environment is connected to resets its folder to that branch and clears its caches, with a Deployments list per environment.
• Redirects as records, exact or pattern-matched, which the REST API can create in bulk, and an export and import of layouts, input types, custom fields, settings and jobs between sites.

Ten things to know first

1. The page cache is read before authentication. A page stored from an anonymous visit is served unchanged to a signed-in member (Authenticated requests and the cache).
2. Declare any query parameter the cache should key on. The cache key includes only the parameters a template declares; otherwise the first visitor's version is stored under the bare path and served for every value of it (query parameters).
3. Time a render on an environment that runs in production mode. A development environment never stores a page: every response there is miss, no-store and every template is compiled on every request, so a timing taken there says little about production (development is not a benchmark).
4. Clear the cache after a settings change or an edited person record. Smart invalidation does not follow either one; a deploy or the environment's Clear Cache does (Cache invalidation).
5. A getter called inside a loop is a query per row. Thirty posts that print their authors and categories cost at least 61 queries (The three query-per-row shapes).
6. A deploy resets the server to the branch. Any file changed on the server outside git is replaced by the branch's version at the next push, by anyone (FTP and tracked files).
7. Commit the build together with the source that changed it. A deploy serves whatever was last committed, so a push without its build still succeeds, and the site keeps serving the previous build (Build before you push).
8. A site's environments share one database, so content edited on staging is edited on production, and a push carries no layouts, jobs, forms or settings (Code deploys, content does not).
9. Clear the cache after adding a redirect for a URL that is already live. The page cache answers before redirects are checked, so a cached page keeps serving until the cache is cleared (Redirect mapping).
10. Code can be rolled back; orders, payments and content cannot (Rollback).

Where else to look

When a page is already slow and you need the cause, the performance troubleshooting page works from the symptom. The fragment pattern these units rely on for personal content on cached pages is written up once, in Hybrid builds, and from the member's side in A member site and the page cache. Jobs, which this guide mentions for moving configuration and for health checks, were called hooks before the module was renamed Orchestration (Guide 9). Step-by-step versions of the common tasks are in the how-to library.