The Web Performance Shift Behind Core Web Vitals

The sites with the most engineering money behind them are the ones doing worst at responsiveness. In the 2025 Web Almanac — an annual study of millions of real websites — 77 per cent of mobile sites responded to taps and clicks quickly enough to pass Google’s threshold. Among the thousand largest sites, only 63 per cent did.

That is not a skills gap. The largest sites employ the best-informed performance engineers on the web. It is a coordination gap. The bigger the organisation, the more people are allowed to add weight to a page and the fewer of them are accountable for what the page then costs to use.

That is the real shift behind Core Web Vitals, and it is not a technical one.

Google made a private engineering concern into a public one

Before the vitals, performance was an internal quality argument. Engineers knew the page was too heavy. Nobody outside engineering had a number to point at, so the argument lost to the roadmap every quarter.

Core Web Vitals changed the audience, not the physics. Google’s documentation says plainly that they feed into ranking, while cautioning that there is no single page-experience signal and that relevance still wins. That is a deliberately modest claim and we will not inflate it: nobody outside Google can quantify the weight, and anyone selling you a number is guessing.

What the metrics genuinely did was hand a shared vocabulary to people who previously had none. A marketing lead can read a Search Console report. A designer can be shown the cost of a full-width hero image. Performance became a conversation between departments because it finally had units everyone could see.

Responsiveness is the metric nobody owns

The change of metric matters more than most coverage admits. In March 2024 Google replaced its old measure of responsiveness with a stricter one. The old measure looked at how quickly the page reacted to the first thing you did. The new one looks at every interaction across the whole visit, and reports the worst.

Loading is mostly an engineering and infrastructure problem. Responsiveness is not. Responsiveness is what happens after the marketing tag manager fires, after the personalisation script decides which variant to show, after the consent banner resolves, after the component library redraws a list that a designer specified as infinitely scrolling and a product owner specified as filterable five ways.

Every one of those decisions was reasonable on its own. Nobody in that chain believed they were making a performance decision. That is precisely the problem, and it is why responsiveness is the metric that most reliably exposes how a company is organised.

The fix usually sits with whoever did not cause the symptom

This is the pattern we see repeatedly in web engineering work: the team that can fix a performance problem is almost never the team that produced it.

A page that jumps around as it loads gets reported as a frontend bug. The cause is a field in the CMS allowing an optional promotional banner with no reserved space, because the content model was designed for flexibility and nobody attached a size to it. The fix is a content model change, argued for by an engineer, approved by whoever owns the CMS.

A responsiveness problem gets assigned to the frontend team. The cause is a third-party script added by growth for a two-week campaign that ended eleven months ago and was never removed, because removal was nobody’s ticket.

Neither is an engineering failure. They are ownership failures with engineering symptoms. Which is why we treat performance as a joint concern of engineering, design and growth rather than a backlog item — and why the first question in an audit is not “what is slow” but “who is allowed to make this page heavier, and who finds out when they do”.

Constrained devices tell the truth earlier

We have led frontend architecture for a product whose slowest target was a panel bolted to machinery and whose fastest was a desk browser. That range is the most useful performance teacher we know.

A desktop browser on a good connection hides an enormous amount: an oversized page, a wasteful redraw, a font that arrives late. A television app or an embedded panel does not. There is no spare capacity, so a decision a laptop forgives becomes a visible stutter someone complains about. The same is true of a mid-range phone on a weak signal — which is what the gap between mobile and desktop in the data actually represents.

The lesson we carry into browser work from connected TV and mobile is that the constrained surface is not an edge case to handle last. It is the honest test of the architecture, run early. If a design only works where the hardware is generous, it has a defect the desktop mock-up will never show you.

Field data changes who is accountable, and when

The measurement model quietly rewrote release practice too, and that part is under-discussed.

Core Web Vitals are judged on real visitors rather than lab tests, and on the experience of the slower quarter of them rather than the average — Google’s position is that only real-world measurement captures the full picture. That data arrives as a rolling 28-day average. Individual pages only get their own score if they are public and popular enough; everything else is rolled into one score for the whole site.

Three consequences follow. You cannot demonstrate a fix in a sprint review — you ship, and wait weeks for the average to move. Your worst pages drag down a site-wide score your best pages cannot rescue. And a lab tool showing green tells you almost nothing about the visitors you actually have.

That forces a different discipline: measuring real visitors on your own terms, tied to releases, so a regression traces to a deployment rather than to a month. That is work we have owned directly, and the recurring lesson is that measurement is only useful when somebody is rostered to read it — an ongoing care responsibility, not a launch task.

One gap deserves naming. Apps that swap content without loading a new page have never been fully covered by these measurements. If your product is something people log into, your scores may be flattering you.

Not every improvement is worth buying

The strongest argument against everything above is that performance work is easy to over-buy.

Google’s published case studies report real outcomes — more sales, more organic traffic, a Black Friday uplift. We cite those as directional only: self-reported, no control group, and drawn from the sites that succeeded and chose to say so. Nobody publishes the redesign where the score improved and revenue did not move.

The failure mode is score chasing: weeks moving a metric from adequate to excellent on pages carrying no commercial weight, while the checkout stays slow because it is harder. A dashboard turns green, everyone feels the work landed, and no user noticed.

It is also why we ignore the current wave of articles claiming Google tightened its loading threshold in 2026. We found no primary source, and the documented thresholds are unchanged. Chasing a rumoured target is the purest form of the mistake.

Weigh the work, do not rank it

Score is the diagnostic, not the objective. A priority list built by walking a checklist in order will always put the cheap fix above the one that matters.

So weigh instead. Three factors, multiplied rather than ranked, because a zero on any one should sink the item.

User impact — the multiplier that can be zero. Real-visitor data, on the devices and networks your customers actually use. If a problem does not appear there, its impact is zero and the rest is decoration. This is where most performance backlogs quietly fail: they are populated from lab tools.

Commercial weight — the multiplier nobody applies. A problem on a template serving few visits and no sales is worth less than a smaller one on the path to revenue. What a page is worth belongs in the calculation before its score does, and engineering-led backlogs omit it because it appears in no performance tool.

Cost, counted in approvals. The denominator. Separate the change one engineer ships on a Tuesday from the one needing a design decision, a content migration or a supplier contract reopened. Two fixes with identical engineering effort can differ by a quarter in delivery, entirely in how many people must say yes.

One condition sits outside the arithmetic: if nobody owns the budget after the fix, the weight returns within two release cycles.

The output is not a ranked list. It is a few items with a high score on all three and a named owner, and a longer list you have explicitly decided not to do — the more useful half, because it is the one you defend when somebody produces a red dashboard.