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 02 · Making pages fast
Measure first
Making pages fastPage 7 of 34Updated
The tools and the order to use them in: the server's time to first byte, then the browser waterfall, then the template. Optimising before measuring is how teams speed up the wrong thing.
Who this is for. The developer handed a page that "feels slow". Afterwards you can say whether the time goes on the server or in the browser, and narrow a slow render down to the part of the template that costs it, before changing anything.
A slow page has one or two causes that matter and a dozen that do not. Measuring first finds the one or two; guessing usually finds a real problem that was not the slow one, fixes it, and leaves the page as slow as it was. The order below goes from the cheapest, widest measurement to the narrowest, and each step tells you whether the next is worth doing.
1. The server: time to first byte
Time to first byte (TTFB) is how long the server took before it started sending. It splits every performance question in two: if TTFB is small, the problem is in the browser; if it is large, it is on the server, usually in the template.
Measure it signed out, and note which case you measured (reading the headers):
Shell
for i in 1 2 3; do
curl -s -o /dev/null -D - -w 'ttfb %{time_starttransfer}s total %{time_total}s\n' \
https://www.example.com/products | grep -iE 'x-cache-status|^ttfb'
done
A hit is the floor. If the cached page is slow, the cost is the network or the size of the page, not your templates.
A render is the number to improve. To get one on a cacheable page, request it right after a save of the record has cleared it, or time it on a staging environment that runs in production mode. A development environment is several times slower than production, so compare development timings only with each other (development is not a benchmark).
Compare against a plain page. Time a simple text page on the same site and environment. What a slow page takes beyond that is what its template costs.
2. The browser: the waterfall
If TTFB is fine and the page still feels slow, the cost is in what the page asks the browser to fetch and run. Open the developer tools' Network panel in a private window, disable the browser cache, reload, and read the waterfall from the top:
Bytes by type. Sort by size. On listing pages the largest items are nearly always images at their uploaded size (Images).
What blocks rendering. Stylesheets, and scripts in the head that are not defer or async, hold up the first paint (Bundle size).
Who else is on the page. Group by domain. Every third-party domain is a connection, a script and someone else's server time (Fonts and third-party scripts).
Layout shift. The Performance panel, or a Lighthouse run, reports the largest contentful paint and the layout shift, and names the element responsible for each.
Run Lighthouse against production, signed out, on its mobile setting. Its score is a summary; the list of opportunities under it, each with the bytes or milliseconds it would save, is what to act on.
3. The template
If the render is slow, find which part of the template costs it. Work by elimination, on a development environment where every request renders:
Time the page as it is, three times, and take the middle value.
Remove one include, one component area or one loop (comment it out), time again, and put it back. The section whose removal saves the most time is the one to look at.
Use {debug_vars} to inspect variables, not timing. On a development environment, Smarty's {debug_vars} shows the variables a template received; it is for development only, for inspecting variables rather than timing them.
Write the numbers down before you change anything: the TTFB of a render and of a hit, the page's total bytes, its largest contentful paint. A change that moves none of them was not the problem, whatever it fixed.