# What Are Core Web Vitals? — LCP, INP and CLS, and Why Lighthouse Disagrees With Them

Canonical: https://commareports.com/glossary/core-web-vitals
Published: 2026-11-11

> Core Web Vitals are Google's three user-experience metrics: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. The good/poor thresholds, field data vs a Lighthouse lab run, why INP is missing from Lighthouse, and how the Performance score is weighted.

# Core Web Vitals

**Core Web Vitals** are the three metrics Google uses to describe how a
page feels to the person loading it: how fast the main content appears,
how quickly the page answers a click, and whether things jump around
while it loads.

| Metric                              | Measures       | Good     | Poor     |
| ----------------------------------- | -------------- | -------- | -------- |
| **LCP** — Largest Contentful Paint  | Loading        | ≤ 2.5 s  | > 4 s    |
| **INP** — Interaction to Next Paint | Responsiveness | ≤ 200 ms | > 500 ms |
| **CLS** — Cumulative Layout Shift   | Stability      | ≤ 0.1    | > 0.25   |

A page passes when the **75th percentile** of real visits is in the good
band for all three. INP replaced First Input Delay (FID) in March 2024;
FID only timed the first interaction's input delay, INP times the slowest
interactions across the whole visit, through to the next frame painted.

## Field data and lab data

The numbers come from two places, and most confusion about Core Web
Vitals is these two disagreeing.

- **Field data** is measured in real users' Chrome browsers and
  published in the Chrome UX Report (CrUX) as a rolling 28-day window.
  PageSpeed Insights shows it at the top as "Discover what your real
  users are experiencing", and Search Console groups URLs by it. This is
  the assessment that counts.
- **Lab data** is one Lighthouse run: a single load, on one machine,
  with simulated throttling. It is reproducible and it explains _why_ —
  which script blocked the main thread, which image was the LCP
  element — but it is not what real users got.

A lab run can be green while field data fails (your laptop and CDN cache
are faster than your users' phones) or the reverse (the slow page only
appears for logged-in users, whom Lighthouse never is).

## Where Lighthouse fits

Lighthouse's Performance score is not a Core Web Vitals score. Since
Lighthouse 10 it is a weighted average of five lab metrics:

| Metric                   | Weight |
| ------------------------ | -----: |
| Total Blocking Time      |    30% |
| Largest Contentful Paint |    25% |
| Cumulative Layout Shift  |    25% |
| First Contentful Paint   |    10% |
| Speed Index              |    10% |

INP is absent because a page-load run never clicks anything. **Total
Blocking Time** stands in for it: long main-thread tasks that block
input during load are the same tasks that make interactions slow later.
To measure INP in the lab, script the interactions in a Lighthouse user
flow and run it in timespan mode.

## Reading the report

The scores start the conversation; the audits under them settle it. In
a Lighthouse report each failed audit carries an estimated saving and
the URLs or elements behind it — "Reduce unused JavaScript, 1.9 s,
`vendor.js`" is something an engineer can act on, "Performance 41" is
not. The [Lighthouse report viewer](/tools/lighthouse-viewer) turns the
JSON from the CLI, Lighthouse CI or the PageSpeed Insights API into
that list, ordered by savings, with a Markdown summary for the pull
request.

When the person who decides what gets fixed is a client or a PM, send
them the report rather than a screenshot of four circles — and send a
link that will still work next month, which Lighthouse CI's public
links do not ([why](/fix/lighthouse-ci-report-link-expired)).

## Related

- [Lighthouse report viewer](/tools/lighthouse-viewer) — Lighthouse or PageSpeed Insights JSON to a readable report
- [Lighthouse CI link expired](/fix/lighthouse-ci-report-link-expired) — temporary-public-storage, and keeping the link
- [HTML report](/glossary/html-report) — the format most tools write for humans
- [Flame graph](/glossary/flamegraph) — the other half of finding what blocks the main thread
- [Glossary](/glossary) — every term