Core Web Vitals: what they are and how to measure them without fooling yourself

What are Core Web Vitals: LCP, INP and CLS

Core Web Vitals are three field metrics: LCP measures loading, INP responsiveness and CLS visual stability, each judged at the 75th percentile of real visits, on mobile and desktop separately. Each has a good threshold and a poor one:

What's at stake isn't just Google: it's the people who buy. Vodafone compared two versions of a landing page in an A/B test. According to the case study on web.dev (Mar 17, 2021), a 31% better LCP brought 8% more sales.

That's one large company, not a promise for yours. But it shows what to look at in the end: sales and leads, not the score.

“Largest” in LCP means largest by visible area inside the viewport, which is rarely the element you would have guessed.

INP replaced FID on March 12, 2024. FID only measured the input delay of the first interaction; INP observes all of them. If a guide still talks about FID, it's out of date.

And CLS doesn't care whether the movement annoyed anyone: it scores the shift whether or not a person was looking. That detail matters later.

Lab or field: why is the score not the metric?

The 0 to 100 number PageSpeed shows comes from Lighthouse, in a lab, on a simulated device. The three metrics that Google actually uses come from the Chrome UX Report, which collects data from real Chrome users. PageSpeed Insights shows them over the trailing 28 days.

If your site is new or has little traffic, the field section says “no data” and keeps saying it until there is enough traffic. That isn't a failure: a lab number isn't a field number, and until the field data exists you say it doesn't exist.

Two details change how you read field data. If your page doesn't have enough visits, PageSpeed may show you the whole site's data instead of that page's. And Search Console rates each group of pages by its worst metric: one bad CLS sinks a good LCP.

If your site was built with an AI builder, it's most likely a single-page app. Then Chrome attributes to the first page everything that happens while the person moves around inside the site. Field data for an inner page isn't exact, and the public data can't separate it.

Why does a single PageSpeed run lie?

Lighthouse's own documentation is explicit that a lot of the variability in a score isn't due to Lighthouse but to changing conditions. A/B tests or changing ads, internet traffic routing, different devices, browser extensions and antivirus software all move it. One run is a sample of one.

result A   performance 80
result B   performance 64
→ Every run gave A or B. Never anything in between.

I measured it on a site I audit. If I'd stopped at the first runs, I'd have reported a drop that didn't exist.

I take five, keep the median and report the range next to it. A page with a median of 2.1 s and a range of 1.8 to 5.9 s has one problem. A page that sits at 2.1 s every time has another.

To show a change worked, I'd rather use a number that doesn't bounce around: how many kilobytes of JavaScript the page needs.

On that same site, the contact page's JavaScript dropped from 142 to 84 KB once what it didn't use was split out. I measured it in the build files on September 12, 2026. That number comes out the same every time it's measured; the score doesn't.

With the median and the range, I compared the home pages of my two sites with seven Colombian agencies and designers that sell websites. On mobile PageSpeed, cardonaseo.com scored 92 and regresoempresarial.com 95; the median of the seven was 62 (lab, median of three runs, Oct 17, 2026).

That was three runs per site, not the five of my rule, and a single night: it's good for comparing, not for promising a score. If you're getting a new website, ask for this measurement before you pay for delivery, whoever builds it. I publish mine on SEO website design.

On Oct 29, 2026, I measured two prototypes that score 99 for mobile performance the same way (PageSpeed Insights, median of three runs). They're prototypes for Bogotá businesses with no field data yet, so this is lab data.

These are five PageSpeed Insights runs of my page, with the LCP of each, in seconds: [the five numbers].
This is what the real-user data section says: [what it says, or write “no data”].
Calculate the median and the range. If you call the page stable or unstable, say by what criterion. Use only my numbers.

Rules for this review:
1. Quote the exact text you found. Don't paraphrase it.
2. If something can't be seen from the browser, write “not verifiable from the browser.” Don't assume.
3. Give me a table: element · what you found · fine / review / missing · why it matters in one sentence.
4. Don't make up traffic, visits or rankings. Don't promise anything will rank higher on Google.
5. If you can't open an address yourself, say so in the first line and work only with what I pasted. Don't describe a page you didn't see.

If someone quotes you a speed fix based on a single run, you're paying to fix a number that jumps around. Ask for five runs, the median and the range before you approve anything, and the same five runs afterwards to prove it worked. That's how I measure in the technical audit; the free diagnostic tells you first whether there's a serious error.

Which element is your LCP?

On a site I audit, in September 2026, the LCP element was the H1 heading, not the much larger hero image. Chrome leaves out elements that cover the full viewport, treating them as background, so optimizing the image wouldn't have moved LCP at all.

Optimizing the obvious candidate would have cost an afternoon and changed nothing. The fix isn't to guess: Chrome DevTools marks the LCP element on the Performance panel, and the PerformanceObserver API reports it in four lines.

new PerformanceObserver((list) => {
  const e = list.getEntries().at(-1);
  console.log(e.element, Math.round(e.startTime));
}).observe({ type: 'largest-contentful-paint', buffered: true });
→ paste it, reload, and read which element it actually was

Two measurements from this site, one of them useless

First measurement: LCP with and without an above-the-fold image, on localhost. The two numbers came out almost the same, and I nearly reported that the image didn't matter.

It was an instrument failure, not a finding. On localhost there's no latency, so the two arms couldn't differ.

Then I applied mobile throttling (1.6 Mbps, 150 ms round trip, CPU slowed four times). The same comparison gave 688 ms against 276 ms (lab, September 2026), and the conclusion reversed.

The second one: this site scored CLS 0.3246 on all 45 of its lazy-loaded routes. It was a lab run on September 27, 2026 (390 px, throttled mobile network). Only the home page, which isn't lazy-loaded, was clean.

The cause was a loading placeholder shorter than the screen, so the footer was visible and then moved down. One CSS line took it to 0.000.

What should you fix first?

Start with what has the biggest impact and costs the least to fix, after you have found the real LCP element. This is the order I use, one metric at a time. The last step is the one that's easiest to skip: measuring again under the same conditions.

• LCP: find the real element first. If it's an image, give it explicit width and height, serve it in a modern format and let it load eagerly. If it's text, the problem is usually a web font blocking the paint.

• CLS: reserve the space of anything that arrives late. Images without dimensions, ads, embeds, and loading placeholders shorter than the viewport, which is the one that caught me.

• INP: it's almost always JavaScript holding the main thread. Break long tasks up and postpone whatever isn't needed for the first interaction.

• And measure again, with the same instrument and the same conditions. A change you can't compare is a change you can't defend.

You can run all of this yourself at PageSpeed Insights, five times, and write down the median and the range. That's the whole method.

If your site depends on JavaScript to paint its content, that hits performance and what Google receives at the same time. I explain it in why a website doesn't show up on Google. If you haven't built it yet, it's cheaper to avoid this from the start: see how to build a website with AI.

In the technical SEO audit I measure it this way: five runs, the median and the range. And I identify the LCP element before I recommend anything.

How do you optimize Core Web Vitals with AI?

Use AI as an assistant, not a judge: measure with PageSpeed Insights and ask an agent to pull the diagnosis into a report. Then fix things with Claude Code on your repository, one change at a time, and measure again with the same instrument. Finally, ask Google to recrawl what changed.

It's the workflow I use on this site. The AI does the heavy lifting; I specify, review and verify.

• 1 · Measure. Run each important URL through PageSpeed Insights five times and write down the median and the range. Lighthouse, in Chrome DevTools, runs the same kind of lab test.

• 2 · Ask an agent for the diagnosis. The Claude in Chrome extension can run those tests for you and hand you a report as a .md file. The prompt I use is below this list.

• 3 · Take the report to Claude Code. Connect your repository and ask it to check the report against the code and review the site's technical SEO in depth. Have it propose one change at a time and wait for your yes; if you don't know where to start, ask Claude inside your project.

• 4 · Fix and verify. Measure again with the same instrument, five runs. Also check that the fix didn't remove anything Google used: the title, the canonical, the H1 and the text.

• 5 · Request indexing for what changed. You do it URL by URL in Search Console's URL Inspection, and there's a quota; for many URLs, submit the sitemap. If you'd rather not, the extension can do it while you watch, as long as you're an owner or full user of the property.

I want a Core Web Vitals and technical SEO diagnosis of these URLs: [paste your URLs here].
1. Run each URL through PageSpeed Insights (https://pagespeed.web.dev/), on mobile, five times. Write down the median and the range of the score, LCP, CLS and TBT.
2. Copy the field data (from real users) if PageSpeed shows it. If there isn't any, write "no field data"; don't estimate it.
3. Name the LCP element of each page, as the diagnostics report it.
4. On each page, check the title, the meta description, that there's a single h1, the canonical, images without width and height, and third-party scripts.
5. Give it to me in Markdown, ready to save as core-web-vitals-diagnosis.md, with the date and the tool behind each figure.
Don't change anything on any site or in any account. If a test fails, say so and don't count it.

Pinterest learned this in 2017, when it rebuilt its pages to load faster. According to its engineering team, the wait time it measures dropped 40% and SEO traffic rose 15%. But first it took weeks to bring SEO traffic level with the old pages, because of differences in tags like the h1 or the canonical.

What about Screaming Frog? It's great for reviewing a whole site at once, but it doesn't measure Core Web Vitals by itself. It pulls them in if you connect it to the PageSpeed Insights API, a feature of the paid version.

Three warnings before you start. PageSpeed and Lighthouse are lab tools, and what counts for Google is field data from real users. An AI doesn't replace reading the documentation it cites, and a speed fix on its own won't lift your rankings.

If you'd rather not do it yourself, the free diagnostic tells you whether there's a serious error. And if you're getting a new website, in SEO website design speed counts from the design stage. If one of your references clashes with it, speed wins.

Watch it explained, by the people who built it

Three short videos from Google's own channels. They're the same source the links above point to, in video form:

• What is Interaction to Next Paint (INP)? · Chrome for Developers, 52 seconds. The shortest correct definition of INP there is.

• How to improve Largest Contentful Paint · Google Search Central, 22 minutes. From 2021, so it still says FID where you should read INP; the LCP part is unchanged.

• Monitor live Core Web Vitals in Chrome DevTools · Chrome for Developers, 6 minutes. This is how you find your real LCP element without writing any code.

Frequently asked questions