What you'll learn

  1. Quick answer
  2. Why these three
  3. LCP — Largest Contentful Paint
  4. INP — Interaction to Next Paint
  5. CLS — Cumulative Layout Shift
  6. Measuring it properly
  7. FAQ

Quick Answer

LCP measures how long the largest visible element takes to render, INP how quickly the page responds to interactions, and CLS how much the layout shifts unexpectedly. All three are measured on real visits, not in a lab.

Why these three

Older metrics measured events users do not experience. Nobody notices when the load event fires; they notice waiting for the headline to appear, tapping a button that does nothing, and a page jumping as they start reading.

Core Web Vitals attempt to measure those three experiences directly: loading, responsiveness and visual stability.

They are also a search ranking signal, though a modest one — relevant content outranks fast content. Treat them as a tie-breaker and, more importantly, as a proxy for whether people abandon your page.

The crucial detail: the scores that count come from real users on real devices, not from your laptop. A mid-range Android phone on a patchy connection is the realistic test, which is why lab tools and field data often disagree.

LCP — Largest Contentful Paint

How long until the largest visible element — usually a hero image, a heading or a block of text — is rendered. Good is under 2.5 seconds.

Common causes of a poor score:

  • Slow server response. Nothing can render before the HTML arrives. If your time to first byte is a second, you have already spent 40% of the budget.
  • Render-blocking CSS and JavaScript in the head, which delay everything.
  • Unoptimised images — a 3 MB hero image is a common single cause.
  • Fonts that hide text until they load.
  • Client-side rendering, where the browser must download and run JavaScript before any content exists — see Next.js vs React.

The highest-value fixes are usually: compress and correctly size the hero image, serve modern formats, preload it, and set font-display: swap so text renders in a fallback font immediately.

INP — Interaction to Next Paint

INP replaced First Input Delay in 2024. It measures how long from a user interaction — a tap, click or key press — until the page visibly updates, across the whole visit rather than only the first interaction. Good is under 200 milliseconds.

The cause is nearly always the same: the main thread is busy. JavaScript is single-threaded, so while a long task runs, nothing responds. A 500ms function means half a second where taps do nothing.

What helps:

  • Break up long tasks. Yield to the browser so it can paint between chunks of work.
  • Ship less JavaScript. Parsing and executing a large bundle is itself a long task.
  • Debounce expensive handlers on input and scroll events.
  • Move heavy computation to a web worker, which runs off the main thread.
  • Audit third-party scripts. Analytics, chat widgets and ad tags frequently dominate main-thread time, and they are easy to forget because they are not your code.

CLS — Cumulative Layout Shift

How much visible content moves unexpectedly during the page's life. Good is under 0.1.

This is the metric users feel most viscerally — reading a paragraph that jumps down, or tapping a button that moves as an advert loads above it.

Causes and fixes are unusually direct:

  • Images without dimensions. The browser cannot reserve space, so everything reflows on load. Always set width and height attributes, or an aspect-ratio in CSS.
  • Ads and embeds injected into unreserved space. Reserve a container of the expected size.
  • Web fonts swapping to a different-sized face. Match fallback metrics with size-adjust.
  • Content inserted above existing content — a banner pushing the page down after render.

Setting image dimensions is genuinely the single highest-return fix on most sites, and it takes minutes.

Measuring it properly

Two kinds of data, and confusing them wastes effort.

Lab data — Lighthouse in developer tools. Reproducible, immediate, ideal for iterating on a fix. But it is one simulated load on your machine, and it cannot measure INP properly because there is no real interaction.

Field data — actual visits, reported in Search Console. This is what counts for ranking and what reflects reality. It lags by weeks, since it is a rolling window.

Use lab data to iterate and field data to decide what matters. A page scoring 100 in Lighthouse can have poor field vitals, usually because real users are on slower devices and networks than your development machine.

Look at the 75th percentile, not the average. Vitals are assessed on the experience of the slower quarter of your users, which is deliberately unforgiving — an average hides exactly the people having a bad time.

Frequently Asked Questions

What are good Core Web Vitals scores? LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of real visits.
Why does Lighthouse show 100 but Search Console reports poor vitals? Lighthouse is a lab test on your machine. Search Console reports real users, who are often on slower devices and networks. Field data is what counts.
What replaced First Input Delay? Interaction to Next Paint, which measures responsiveness across the whole visit rather than only the first interaction, making it a much better reflection of real use.
What is the quickest way to improve CLS? Set width and height attributes on every image, and reserve space for ads and embeds. Unsized images are the most common cause of layout shift.
Do Core Web Vitals really affect search rankings? Yes, as a modest signal. Relevance matters far more, so treat vitals as a tie-breaker between comparable pages — and as a direct measure of whether users abandon yours.