Core Web Vitals
21 checks: LCP, INP, CLS and the delivery problems behind them.
Core Web Vitals are Google's measurements of what a page feels like to use: how quickly the main content appears, how quickly it responds, and whether it moves around while you are reading. 21 checks, covering the vitals themselves and the things that cause them.
Field data and lab data
Every vitals reading is one of two things, and they are not interchangeable. Each figure on the report says which it is.
| Source | What it is | What it is good for |
|---|---|---|
| Field | What real visitors actually experienced, collected from Chrome over the past 28 days. Only exists once a page has enough traffic. | This is what Google uses. It is the truth, and it is slow to move: a fix today shows up over the following weeks as the window rolls. |
| Lab | A synthetic run against the page on a simulated device and connection. | Available immediately for any page, repeatable, and useful for comparing before and after. It is a model of one visit, not a measurement of your visitors. |
A page can pass in the lab and fail in the field, and that is not a contradiction. It usually means real visitors are on slower devices or connections than the simulation, or that something in your real stack, a consent banner or a tag manager, does not run in the lab. When the two disagree, the field data is the one that counts.
The three vitals, and two more
| Metric | Measures | Good | Usual cause when it fails |
|---|---|---|---|
| LCP Largest Contentful Paint | How long until the biggest thing on screen has rendered. The closest single proxy for "has the page loaded". | Under 2.5s | An unoptimised hero image, a slow server response, or render-blocking resources ahead of the content. |
| INP Interaction to Next Paint | How long the page takes to visibly respond after somebody interacts with it. Replaced FID in March 2024 because FID only measured the first interaction. | Under 200ms | Long JavaScript tasks blocking the main thread while somebody is trying to use the page. |
| CLS Cumulative Layout Shift | How much the page moves around during load. The reason you tap the wrong thing. | Under 0.1 | Images and ads without reserved dimensions, and web fonts swapping in at a different size. |
| FCP First Contentful Paint | How long until anything at all is drawn. Not a Core Web Vital, but it tells you whether a slow LCP started slow or finished slow. | Under 1.8s | Server response time, or blocking resources in the head. |
| TTFB Time to First Byte | How long the server took to start replying. Everything else waits on this. | Under 800ms | Slow application code, no caching, or distance from the visitor with no CDN in between. |
What the report checks behind the vitals
A vitals number tells you a page is slow. These tell you why, and they are where the fix is.
| Check | What it looks for |
|---|---|
performance.ttfb | Server response time measured on our own fetch. |
performance.no_compression | HTML served without gzip or brotli. Usually a one-line server change for a large reduction in bytes. |
performance.large_html | An HTML document big enough to be slow to parse before anything else happens. |
performance.render_blocking | Stylesheets and scripts in the head that stop the page drawing until they have loaded. |
performance.many_requests | More separate resources than the page needs. |
performance.inline_styles | Style attributes scattered through the markup, which cannot be cached. |
performance.deprecated_tags | Presentational HTML that browsers keep supporting and nobody should still be sending. |
performance.body_truncated | The document was too large to read in full. Reported rather than hidden, because it means some checks saw only part of the page. |
Delivery
| Check | What it looks for |
|---|---|
delivery.page_weight | Total bytes for the page and everything it pulls in. |
delivery.cache_policy | Cache headers on static assets, so a repeat visit does not re-download them. |
delivery.third_parties | How many other domains the page loads from. Each one is a DNS lookup, a connection, and somebody else's downtime in your critical path. |
Acting on this category
Speed work has a worse effort-to-impact ratio than almost anything else on the report, which is why vitals sit below indexability and content. A page that fails LCP but is indexed, titled and answering the question will outrank a fast page that is none of those things.
That said, two findings here are usually cheap and usually significant:
performance.no_compression and
media.missing_dimensions. Both are configuration rather than
engineering, and the second is the most common single cause of a failing
CLS score.