Core Web Vitals for Marketers: The Three Numbers That Matter

Your developer says the site is “performing well.” Your agency’s report shows a big green circle. Meanwhile your bounce rate on mobile is 68% and the paid traffic you’re buying seems to evaporate somewhere between the click and the page.

Somewhere in this gap sit three numbers. They have unfriendly acronyms, they’re measured in units nobody uses in conversation, and they quietly govern both how your site ranks and whether visitors stay long enough to convert.

You don’t need to know how to fix them. You do need to know what they are, what “good” looks like, and how to tell whether the green circle is telling you the truth. That’s a fifteen- minute investment with an unusually good return.

The one thing to understand first

Core Web Vitals are measured on real visitors, not in a lab.

Google evaluates them at the 75th percentile of your actual traffic. Which means: three out of four visitors must have a good experience for the URL to pass. Not your average visitor. Not your developer on office fibre with a warm cache and a new laptop.

This single fact explains most of the confusion in performance reporting. A lab test - the kind that produces the satisfying green score - simulates one visit under controlled conditions. Field data records what actually happened to real people on a patchy 4G connection in a lift.

If your lab score is excellent and your field data is failing, the field data is right. It’s not a measurement error. It’s your audience.

LCP - Largest Contentful Paint

What it measures: how long until the main content appears. Usually the hero image, the headline, or the big block that makes the page feel arrived.

Good: under 2.5 seconds. Needs work: 2.5 to 4 seconds. Poor: over 4 seconds.

Why it matters commercially: LCP is roughly “how long the page felt blank.” It maps almost directly to bounce rate on paid traffic, because someone who clicked an ad and got a white screen has no loyalty to spend on waiting.

Usual culprits: an enormous unoptimised hero image, slow server response, render- blocking scripts, web fonts that delay text, and - perennially - a tag manager container carrying eleven marketing scripts, several of which belong to campaigns that ended in 2023.

What to ask: “What’s our LCP element on the main landing pages, and what’s delaying it?” A good developer will name the element and the blocker in one sentence.

INP - Interaction to Next Paint

What it measures: how quickly the page visibly responds when someone interacts - taps a button, opens a menu, types in a field. It replaced First Input Delay in 2024 and is a considerably harsher, more honest metric, because it measures all interactions across the visit rather than just the first one.

Good: under 200 milliseconds. Needs work: 200 to 500ms. Poor: over 500ms.

Why it matters commercially: INP is the “is this thing broken?” metric. A tap that doesn’t respond within about 200ms feels unresponsive, and the universal human response is to tap again - which frequently triggers a duplicate submission, then confusion, then abandonment.

Worth knowing: INP is the most commonly failed Core Web Vital in 2026, with around 43% of sites still missing the 200ms threshold. If you’re going to fail one, statistically this is it.

Usual culprits: heavy JavaScript blocking the main thread, oversized third-party scripts, chat widgets, A/B testing tools, and analytics stacks that have accumulated like sediment over several agency relationships.

What to ask: “Which interactions have the worst INP, and what’s blocking the main thread when they happen?”

CLS - Cumulative Layout Shift

What it measures: how much the page jumps around while loading. It’s a unitless score, not a time.

Good: under 0.1. Needs work: 0.1 to 0.25. Poor: over 0.25.

Why it matters commercially: CLS is the metric behind the universally infuriating experience of reaching for a link and having an ad load above it, so you tap something else entirely. It damages trust immediately and correlates with form abandonment - and it’s the one your customers will actually complain about, because it’s the only one they can see happening.

Usual culprits: images without width and height attributes, ads and embeds injected without reserved space, web fonts causing text to reflow, cookie banners appearing late, and dynamically inserted content pushing everything down.

Good news: CLS is usually the cheapest of the three to fix. Reserving space for known elements is straightforward engineering, and the improvement is often dramatic and immediate.

What to ask: “Which elements are shifting, and can we reserve space for them?”

Reading the report without being misled

Field data beats lab data. Always. In PageSpeed Insights, the top section is real-user data from the Chrome User Experience Report. The bottom section is a simulated Lighthouse test. Marketers habitually quote the Lighthouse score because it’s a single tidy number. It’s the less important one.

Check by page type, not sitewide. Your homepage might pass while your highest-spend landing page fails. Since Core Web Vitals are assessed at URL level, sitewide averages can hide exactly the pages you’re paying to send traffic to.

Separate mobile and desktop. They’re measured separately and they usually differ substantially. Mobile is where the problems live and where most of your traffic is.

Set alerts below the thresholds. A sensible early-warning practice is to alert at roughly 80% of Google’s limits - INP above 160ms, LCP above 2.0s, CLS above 0.08 - so you catch drift before it becomes a failure.

Fixing them in the right order

You’re not going to do the engineering, but you are going to prioritise it - and prioritisation is where most performance projects waste their budget, because teams start with whatever is most technically interesting rather than whatever is most commercially expensive.

A workable order:

1. Fix CLS first. It’s usually the cheapest, the fastest and the most visible to users. Reserving space for images, ads and banners is well-understood work with an immediate, obvious result. Good for morale, good for the visitor, cheap.

2. Audit your third-party scripts. This one fix frequently improves both LCP and INP simultaneously, and it’s a marketing decision rather than an engineering one. Open your tag manager, list every script, and identify who owns each and what it’s for. On most sites, a third of them are orphans from campaigns, vendors or agencies that are no longer involved. Removing them costs nothing and requires no code.

3. Attack LCP on your highest-spend pages. Not sitewide - start where the money lands. Compress and correctly size the hero image, serve modern formats, preload the LCP element, and check server response time. Fixing three landing pages is a fortnight’s work; fixing the whole site is a quarter’s.

4. Then INP. This is the genuinely hard one, because it usually means reducing or deferring JavaScript, which touches how the site is built. It’s a roadmap item, not a sprint task. Budget for it honestly rather than promising it by Friday.

One warning: performance regresses. It always regresses. A site fixed in March fails again by September because six new scripts, a chat widget and a video embed have arrived in the meantime. Put field data on a monthly dashboard someone actually looks at, or you’ll be commissioning this project again next year.

What this is actually worth

Two honest caveats.

First, Core Web Vitals are a genuine but modest ranking factor. They’re a tiebreaker between comparably relevant pages, not a substitute for relevance. Nobody has ever out- ranked better content by having a faster page.

Second, and more importantly: the conversion impact is generally larger than the ranking impact. A page that loads fast, responds immediately and doesn’t move around converts better than one that doesn’t, regardless of what Google thinks. That’s the business case, and it doesn’t depend on any algorithm continuing to care.

Which reframes the whole conversation. Core Web Vitals aren’t an SEO chore to be tolerated. They’re a proxy for whether your site is pleasant to use - and that has never needed a search engine’s endorsement to matter.