Core Web Vitals

Core Web Vitals are the three metrics Google uses to score the experience of a real page load. They are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Each one has a threshold. A page passes only when it meets all three.

They are field metrics. Google collects them from real Chrome users, not from a lab run. That one fact explains most of the confusion around them, and it explains why your Lighthouse score and your Search Console report disagree.

What are the three Core Web Vitals?

Anything between the good and the poor value needs improvement.

LCPTime until the largest thing in view (hero image, headline) has painted. times the render of the largest image or text block in the viewport. It answers one question: did the page arrive?

INP measures the gap between a tap, a click or a key press and the next frame the browser paints. It reports close to the slowest interaction of the whole visit. INP replaced First Input Delay on 12 March 2024, because a single first-input measurement missed the delays that annoy people most.

CLSHow much the page jumps around as it loads. Lower is better; 0 is rock-steady. scores unexpected movement of content that is already on screen. It has no unit. A CLS of 0.1 is a ratio, not a duration.

The threshold is a percentile, and the clock runs for 28 days

Google doesn't grade your median visitor. It grades the 75th percentile of page loads, and it grades mobile and desktop separately. Three quarters of your visits must clear the bar.

The data comes from the Chrome UX Report, over a rolling 28-day window. Two things follow from that window:

• A fix you ship today doesn't land in Search Console today. It gains weight slowly as the window rolls over the old code. Full effect takes about four weeks.
• A page with too little traffic has no Core Web Vitals at all. CrUX needs opt-in Chrome users, a publicly discoverable page, and enough visitors for a stable sample. Below that, PageSpeed Insights falls back to origin-level data, and Search Console omits the URL.

Can Lighthouse measure Core Web Vitals?

A Lighthouse run is one scripted page load on one machine. Nobody is in front of it. That gets you LCP, and the part of CLS that happens during load. It can't get you INP at all. INP needs a real interaction, and there is nobody there to make one.

The INP gap is structural. In Lighthouse 12.8.2 the INP audit declares supportedModes: ['timespan']. Its weight in the default config is 0, and a navigation run drops the audit — and its entry — entirely. See Interaction to Next Paint for what a timespan run measures instead.

So Lighthouse substitutes Total Blocking Time. It gets the largest single weight in the score: 30 percent. TBT is a reasonable stand-in for a busy main thread, but it is not INP. Google publishes a lab target for TBT, under 200 ms on average mobile hardware, but no field threshold and no Search Console report.

CLS is the quieter problem. Lab tools only see the shifts that happen while the page loads. Real visitors scroll, click, and trigger lazy-loaded content. A field CLS is usually worse than a lab CLS.

A clean lab CLS isn't proof of a stable page.

Of the five metrics in the Lighthouse performance score, two are Core Web Vitals: LCP at 25 percent and CLS at 25 percent. First Contentful Paint and Speed Index carry 10 percent each. A performance score of 100 and a failed Core Web Vitals assessment can describe the same URL. That isn't a bug in either tool.

What we measure, and what we cannot

Lightscore runs Lighthouse, so the boundary above is our boundary too. Every completed result carries six timings: lcp_ms, cls, tbt_ms, fcp_ms, speed_index_ms and tti_ms. The raw Lighthouse JSON and HTML come back with them. There's no inp_ms. Our worker loads your page with no visitor and no clicks, so there is no interaction to time.

Here is one of our own runs. wikipedia.org on mobile, 13 August 2026, Lighthouse 12.8.2, measured from Frankfurt and Washington inside the same audit:

Read the LCP column first. Frankfurt clears the 2.5-second threshold and Washington misses it, by 88 ms. Same page, same minute, same Lighthouse build. Where you measure from decides which side of a Core Web Vital threshold you land on.

Then read the rest. CLS was 0 from both regions, which tells you the run saw no layout shift during load — not that no visitor ever sees one. And TBT explains 10.5 of the 11 points between them, even though it isn't a Core Web Vital.

That last part is why we think the performance score is the most over-read number in a Lighthouse report. It's a lab composite, and three of its five metrics aren't Core Web Vitals.

What a lab run gives you instead is control. We pin the Lighthouse and Chromium version. The result carries the Lighthouse version that produced it. A change in your score then means a change in your site, not a change in the tool. Regions are selectable, which matters for the server-time part of TTFBHow long the browser waited before the first byte of the response arrived. and LCP. The free tool takes two of them; the API takes any subset of your allowed regions.

You can also ask for up to 5 runs. We return the median run, picked by performance score, so one slow load does not decide the answer.

Use both. The lab tells you what changed and where; the field tells you whether the people who visit your site noticed.