Core Web Vitals and what they are actually worth

A marketing agency runs a client's site through PageSpeed Insights, gets a 58, and opens a ticket titled "fix performance" with a deadline attached. Nobody on the account has asked what a 58 costs the client in leads, because nobody can answer that question, and the number is sitting right there looking like it needs fixing. Three sprints later the score reads 94. Traffic is unchanged. Conversion is unchanged. The invoice, notably, is not unchanged. This happens constantly, and it happens because Core Web Vitals produce something rare in web work: a single number that goes up when you do the assigned tasks. That satisfaction is real. Whether it was worth funding is a separate question, and it is the one almost nobody asks before the ticket gets opened.

The honest starting position has to concede the counter-argument, because it is a good one. A slow, janky site is a genuine problem, and for a specific set of businesses — high-volume retail, anything on a shaky mobile connection, anything where the page is doing real work under load — speed moves money in ways that are measurable and large. The mistake is not believing that speed matters. It is assuming it matters the same amount for every site, which is how a B2B consultancy with forty visits a day ends up with a performance budget sized for a shopping cart.

What the three metrics actually measure

Core Web Vitals is three numbers, and each one maps to something a visitor would actually notice if you pointed it out, which is more than most SEO metrics can claim.

Largest Contentful Paint (LCP) times how long it takes the biggest visible element — usually a hero image or a headline block — to finish rendering. The threshold for "good" is under 2.5 seconds. This is the one people mean when they say a page "feels slow": the blank or half-loaded moment before the thing you came for shows up.

Interaction to Next Paint (INP), which replaced First Input Delay as the responsiveness metric in March 2024, measures how long the page takes to visibly respond after a click, tap or keypress — not the first one, all of them across the visit, reported at the 98th percentile of interactions. Under 200 milliseconds is good. This is the metric behind the specific annoyance of tapping a menu and watching nothing happen for a beat before it opens.

Cumulative Layout Shift (CLS) scores how much visible content moves around unexpectedly after it has already rendered — an image that loads late and pushes the paragraph you were reading down the screen, an ad slot that reflows the layout under your thumb. Under 0.1 is good. Unlike the other two, this one is not a time; it is a unitless measure of how much and how far things jumped.

The detail that changes how you should read any of this is lab versus field. PageSpeed Insights and Lighthouse run a lab test: one simulated visit, on a fixed connection profile, on a specific device emulation, in a clean environment with nothing else running. It is fully reproducible and useful for debugging exactly because it holds everything constant. Google's ranking system does not use it. Ranking uses field data from the Chrome User Experience Report — real visits, real devices, real networks, aggregated to the 75th percentile over a rolling 28 days. A page can lab-test at 95 and field-score poorly because its actual visitors are disproportionately on mid-range Android phones over patchy mobile networks, which the lab test never simulates. Chase the lab number and you can end up optimising for a visitor who does not exist.

The ranking effect is real and it is small

Google has described page experience, of which Core Web Vitals is the technical core, as a signal that helps decide between pages of comparable relevance — a tie-breaker, in its own framing, not an override. That is a meaningfully different claim from "faster pages rank higher," and the difference is the whole argument. A page with thin, generic content and a perfect LCP score does not outrank a page with genuinely better content and a mediocre one. Relevance, backlinks and content depth are doing most of the work that determines where a page lands; Core Web Vitals nudges the order among pages that were already close.

That framing matters most at the tail — the second and third page-experience-eligible result for a competitive query, where several pages are otherwise near-identical in quality and something has to break the tie. If your page is nowhere near that tier because the content underneath it is thin, fixing LCP will not move it there. If your page is already one of two or three genuinely good answers to a query, the vitals may be exactly what decides which one shows first. Knowing which situation you are in is more useful than knowing your score.

Where speed moves conversion, concretely

Set search aside and speed still matters, but it matters unevenly, and the unevenness is the part worth planning around rather than the general principle that "slow is bad."

It concentrates on mobile networks, where the gap between a good and a bad connection is large and unpredictable in a way broadband mostly is not — a 2.5-second desktop load can become an 8-second mobile one on a weak signal, and that gap is where visitors actually leave mid-load rather than after judging the content. It concentrates in high-volume commerce, where even a small percentage shift in conversion multiplies across enough transactions to be worth a dedicated engineering budget — the reason Amazon-scale retailers have invested in shaving fractions of a second for two decades. And it concentrates on pages with a task the visitor is actively trying to complete under time pressure — checkout, a booking flow, a form with a deadline — where every extra second is a chance for hesitation or a second tab to open.

None of that describes a five-page consultancy site getting a hundred visits a month from people who found it through a referral or a LinkedIn post and are already inclined to read it. Those visitors are not comparison-shopping load times against a competitor's tab open next to it; they clicked one link because someone they trust sent it. A site in that position with an LCP of 3.5 seconds is not losing meaningful business to that number. It may be losing business to the actual content of the page, which is a completely different problem with a completely different fix — one covered in more detail in the lead quality problem, which is usually the bigger lever for exactly this kind of site.

The trap is optimising the number instead of the experience

Score-chasing has a specific failure shape, and it is worth naming because it is common: work gets done that moves the metric without changing what anyone using the site actually feels.

Lazy-loading an image that was already below the fold and never counted toward LCP moves nothing anyone perceives, but it can move a lab score. Deferring a script until after the Lighthouse test window closes, without changing when it actually needs to run for a real user, is optimising the test rather than the page. Reserving space for an ad slot to kill a CLS penalty, while leaving the actual layout just as busy and just as slow to settle, fixes the number and not the feeling of using the page. Each of these is legitimate work in some context and pure theatre in others, and the difference is whether a real visitor on a real device notices anything changed. If a fix cannot be described in terms of what a visitor experiences, it is optimising the measurement instrument, not the thing being measured — a distinction covered at more length in measuring what a website does, which applies here as much as it does to conversion reporting.

The tell that a team has crossed into score-chasing is usually the meeting itself: if the conversation is "how do we get the number from 72 to 90" rather than "what is actually slow for our visitors and does it matter to them," the number has become the client, not the proxy it was supposed to be for.

A threshold for when to stop

The practical rule is simpler than the metric explanation makes it sound. Once LCP, INP and CLS all sit inside "good" for the real field data on the pages that carry your traffic and your conversions — not the homepage in isolation, the actual landing pages people arrive on — further optimisation is producing a bigger margin over a threshold that already stopped mattering the moment you crossed it. Google's own scoring does not reward "very good," only "good" versus "needs improvement" versus "poor." An LCP of 1.1 seconds and an LCP of 2.3 seconds are treated identically by the system you are optimising for, even though the second one took considerably less engineering time to reach.

That is the number worth writing down before the next round of tickets gets opened: are the vitals currently green for the pages that matter, yes or no. If yes, the budget for the next sprint belongs somewhere else — content, the offer, the path from click to enquiry, which is the more common actual problem behind a website that needs replacing far more often than raw load time is. If no, fix the specific thing that is slow for the specific visitors who are slow, and stop at green rather than chasing a hundred. The scorecard was never the client.