Core Web Vitals is a client conversation
On the scoreboard arriving from outside, the metric that finally names a thing everybody has experienced, and the two ways I expect this to go wrong.
Google published a set of metrics last Tuesday and said they’ll be feeding into search ranking at some point next year. Three numbers: how long the main content takes to appear, how long the page takes to respond to the first tap, and how much the layout jumps around while it’s loading.
The engineering advice hasn’t changed much. Everything I’d have told you to do in April is still what I’d tell you to do in May.
What’s changed is that I now have somewhere to point.
Eight years of losing this argument
Here’s the shape of the conversation I’ve had, with variations, since about 2012.
I say the site is slow and here’s what it’s costing. Marketing says the chat widget is important. The client’s boss can’t evaluate either claim, both of us sound confident, and the tie gets broken by whoever is more senior or more recently persuasive. I win maybe a third of these.
The problem was never the evidence. I’ve had good evidence for years. The problem is that it’s my evidence, produced by me, about my own area of responsibility, and so it reads as advocacy. “The developer thinks we should have fewer marketing tools” is not a neutral finding, and I’d be skeptical of it too.
The problem was never the evidence. It was that the evidence came from me, about my own work, which makes it advocacy rather than a finding.
An external body with a threshold changes that completely. Not because Google is wise, but because it’s disinterested in the specific argument happening in that room, and because the client already cares enormously about what it thinks.
What the three actually measure
They’re better chosen than I expected, and each one corresponds to something a person feels.
Largest contentful paint. When did the biggest thing above the fold actually show up. Not “when did the server respond,” not “when did the DOM finish,” but when did the visitor see the thing they came for. Under two and a half seconds is the line. This is the metric that finally kills “but our time to first byte is great.”
First input delay. They tap something, how long before the page responds. This is a JavaScript metric wearing a disguise: it’s high when the main thread is busy parsing and executing, which is exactly the third-party problem I was measuring last November.
Cumulative layout shift. How much stuff moved while the page was loading.
The third one is the good one
CLS is the interesting arrival, because it’s the first performance metric I’ve seen that measures an annoyance every single person has experienced and nobody had a name for.
You go to tap a link. An ad loads above it. The link moves. You tap the ad.
Everyone has done that. Everyone has been furious about it. And until last week there was no number for it, so it wasn’t on anybody’s list, so it got fixed only when a developer happened to be irritated enough. Naming a thing is most of the work of getting it fixed, and this one has been sitting there unnamed for 15 years.
It’s also the cheapest to fix, and the fixes are almost entirely about reserving space for things that arrive late:
<!-- 1. dimensions back on images. browsers now use these to reserve the
right aspect ratio before the file arrives -->
<img src="hero.jpg" width="1200" height="675" alt="…">
<!-- 2. reserve the box for anything injected: ads, embeds, banners -->
.ad-slot { min-height: 250px; }
<!-- 3. font-display: swap plus a preload, so the swap happens early
rather than a second in -->
<link rel="preload" href="/fonts/body.woff2" as="font" type="font/woff2" crossorigin>
<!-- 4. never inject anything above existing content after load -->The width and height thing is worth dwelling on, because it’s a lovely reversal. We all stripped those attributes out years ago on the grounds that sizing belongs in CSS, which was correct. Browsers now use them to compute an aspect ratio and reserve the space before the image downloads, so the attribute we removed for good reasons has quietly become the fix for a problem we caused. Put them back, keep max-width: 100%; height: auto in the CSS, and everything works.
Field data is the political change
The bit that I think matters most and that nobody’s talking about much.
These are measured on real visitors, on their real devices and connections, and reported at the 75th percentile. Not a lab run. Not your laptop.
Which quietly removes the oldest defense in this business. “It’s fast on my machine” has been the end of a thousand conversations, and it’s usually true, and it has never once been relevant. The number a client will now be shown is what happened to their actual customers on their actual phones, and a quarter of those customers had it worse than the number.
The flip side is that you can’t fully measure one of these in the lab at all. First input delay needs a real person to actually input something. Lab tools give you a proxy, total blocking time, which correlates well enough to work with, and it’s worth knowing they’re different so you don’t get caught out claiming a lab score in a meeting.
What I’d do first
In order, for a normal storefront.
Put dimensions back on every image. An afternoon, fixes most of a CLS problem.
Find the largest element above the fold on the three most-visited pages and make that one thing load early: preload it, don’t lazy-load it, don’t hide it behind a font or a script. Lazy-loading the hero image is the single most common self-inflicted LCP wound I’ve seen and it’s always well-intentioned.
Then go after blocking third parties, which is where the input delay lives, and which I’ve written about at some length and will not do again.
Then measure in the field, because everything above is a guess until real people are in the numbers.
The two ways this goes wrong
Optimizing for the score. All three of these can be gamed, and there’ll be a small industry doing it by fall. You can improve LCP by making the largest element smaller. You can hold CLS down by shipping a skeleton screen that reserves space for content that then takes four seconds to arrive, and the number will be lovely and the experience worse. If the metric and the experience disagree, the metric is wrong.
Performance becoming an SEO task. The risk of a search company owning this is that it gets filed under SEO, and lands on the agency who do the meta descriptions, and becomes a monthly report rather than a design constraint. It’s a design constraint. The decisions that cost you these numbers are made by designers and marketers, months earlier, in rooms with no developers in them, which was the whole point of the budget post last October.
Cautiously pleased
Which is not how I usually feel about a search company deciding what the web should be like, and I’d note that discomfort rather than pretend it away.
But I’ve spent eight years trying to make a case with my own numbers, and next week I get to open a page the client already trusts, on their own site, showing what their own customers actually experienced. I’ll take the help.