Page speed: what actually matters and what is theatre

Page speed conversations have a way of drifting into theatre: teams chasing a green 100 in a testing tool, installing optimisation plugins on top of the bloat that made the site slow, and celebrating score changes no visitor will ever feel. Meanwhile the thing that matters is simple and human: a page that paints fast gets read, and a page that makes someone wait gets abandoned by people who were ready to buy.

Here is the honest hierarchy of what moves speed, and the equally important question of when to stop.

What the metrics are actually measuring

Google’s Core Web Vitals reduce to three human experiences. Largest Contentful Paint: how long until the main content is visible. Interaction to Next Paint: when you tap something, does it respond. Cumulative Layout Shift: does the page jump around under your finger. These are ranking inputs, mildly, as a tiebreaker among comparable pages. They are conversion inputs much more strongly, because they are just measurements of frustration.

Which resolves the “does speed matter for SEO” question sensibly: obsessing over it for rankings is misplaced, and ignoring it is expensive, because the visitor was always the point.

The hierarchy, in order of impact

1. How the HTML is produced. A server-rendered or static page arrives ready to paint. A client-rendered app arrives empty and assembles itself in the browser. No optimisation applied to the second approach beats the first approach; this is the architectural decision that outweighs every plugin, which is why our builds are static by default.

2. Images. The most common heavyweight by far: a 2 MB photograph serving a 400-pixel slot. Modern formats, dimensions matched to display size, and lazy loading below the fold routinely cut page weight by more than everything else combined. We have watched a single hero image conversion, 900 KB to 30 KB, do more than a month of other tuning.

3. Third-party scripts. Every tag, widget, chat bubble and pixel is code your visitor downloads and your page waits on. Scripts accumulate because adding one is easy and removing one requires a decision. Quarterly, list them all and make each earn its place. The fastest script is the deleted one.

4. Fonts. Self-host them, subset them, preload the ones above the fold. A Google Fonts link adds third-party round trips to the critical path on every page load, for no benefit over serving the same files yourself.

5. Compression and caching. Table stakes, cheap, occasionally forgotten entirely: compress text responses, cache hashed assets hard, let repeat visits cost almost nothing.

Everything else, the minified-this and deferred-that of audit checklists, lives in the margins after these five.

The plugin trap

WordPress sites accumulate speed plugins the way slow code accumulates comments. Caching layers, script optimisers, image compressors, each patching symptoms of a theme and page-builder stack that produces too much page. Sometimes that is still the pragmatic play. But when a site needs four plugins to reach mediocre, the honest comparison is against a rebuild on a stack that is fast by construction, which often costs less than the ongoing drag of keeping the patched version upright. We will tell you which side of that line your site is on; the answer is genuinely not always rebuild.

When to stop

Speed work has steep diminishing returns, and the stopping point is visible in the numbers: when your pages paint in about a second on a mid-range phone over a mediocre connection, your users have stopped noticing, and further optimisation is hobbyism. A 92 that could be a 99 is not a business problem. The budget belongs in content, offers and measurement, which at that point will each return more than another hundred milliseconds.

The test worth running is not a tool score at all: open your site on an ordinary phone, on cellular data, somewhere with two bars. That thirty-second experience is what your visitors get, and it either needs work or it does not.