Core Web Vitals explained: LCP, INP and CLS in plain words

Core Web Vitals are three measurements of how a page feels to a real visitor: how quickly the main content appears, how quickly the page reacts when someone taps or clicks, and whether things jump around while it loads. Google uses them as part of its page experience signals, and, more usefully, they describe the things visitors actually notice. This note explains each one, the numbers Google treats as good, and the fixes that tend to matter most.

The three measurements

Largest Contentful Paint (LCP): is the main content here yet?

LCP is the time from the start of the page load until the largest visible element, usually a hero image, a large heading or a block of text, has been drawn. It is a stand-in for "the page looks ready". Google's guidance is that 2.5 seconds or less is good, and more than 4 seconds is poor.

Interaction to Next Paint (INP): does it respond when I touch it?

INP looks at the delay between a visitor's tap, click or key press and the next time the screen visibly updates, across the whole visit, and reports one of the slowest interactions. It replaced First Input Delay as a Core Web Vital in March 2024, because it covers every interaction rather than only the first one. Good is 200 milliseconds or less; poor is more than 500 milliseconds.

Cumulative Layout Shift (CLS): does the page stay still?

CLS adds up unexpected movements of visible content while the page loads, such as a button that jumps down because an image above it finished loading a moment late. It has no unit: 0.1 or less is good, and more than 0.25 is poor.

For all three, Google judges a page by the 75th percentile of real visits. In plain terms, at least three out of four visits must meet the "good" number. A fast result on your own laptop and fibre connection does not settle it, because the slower quarter of your visitors counts too. The definitions and thresholds are published on web.dev.

Lab data and field data are different things

There are two ways to measure, and they answer different questions.

• Field data comes from real visitors' browsers. It is what the ranking signal uses. You can see it for your own site in the Core Web Vitals report in Google Search Console, and for any public page in PageSpeed Insights when enough visits exist.
• Lab data comes from a test run on a simulated device and connection, for example Lighthouse. It is repeatable, so it is the right tool for finding a problem and checking a fix, but it is a guide, not the verdict.

A small site may have too few visits for field data to exist. In that case, use lab tests, test on a real mid-range phone, and treat the numbers above as targets.

What usually moves LCP

• Make the main image smaller. An oversized photo is the most common cause. Resize it to the size it is shown at, use a modern format such as WebP or AVIF, and compress it.
• Do not lazy-load the main image. Lazy loading is right for images below the fold. The image that is the LCP element should load as early as possible; the fetchpriority="high" attribute can tell the browser it matters.
• Answer quickly. A slow server, no caching or a long chain of redirects delays everything after it.
• Do not block the first paint. Large stylesheets and scripts that must finish before anything is drawn push LCP later. Keep the critical CSS small and load the rest later.
• Be careful with fonts. Hosting fonts yourself, loading only the weights you use and using font-display: swap keeps text visible while they arrive.

What usually moves INP

INP is mostly a JavaScript problem. The browser can only do one thing at a time on the main thread, so a long task blocks the response to a tap.

• Send less JavaScript. Remove libraries you do not use and be sceptical of heavy page-builder and widget code.
• Break long tasks into smaller ones so the browser can respond between them.
• Audit third-party scripts: chat widgets, tag managers, ad and tracking code. They are frequent causes and easy to overlook, because you did not write them.
• Keep handlers light. When a tap needs heavy work, show feedback straight away and do the work afterwards.

The INP guide on web.dev explains how to find the slow interaction in your own pages.

What usually moves CLS

• Give images and videos a width and a height (or an aspect ratio in CSS), so the browser reserves the space before the file arrives.
• Reserve space for anything that appears later: embeds, cookie banners that push content down, adverts, late-loading headers.
• Avoid inserting content above what is already visible, unless the visitor asked for it.
• Handle font swaps carefully. A fallback font with similar metrics reduces the jump when the real font replaces it.

A sensible order of work

1. Measure the pages that matter most: home, your main service or product page, and a typical article. Note the field data if it exists.
2. Fix the worst metric on the most visited pages first. One oversized image fixed on a page that many people land on is worth more than ten small tweaks.
3. Change one thing at a time, retest, and keep a note of the before and after numbers.
4. Check again a few weeks later, because field data is collected over a rolling period and reflects what has changed on the site since.

What this does not do

Passing all three metrics does not promise a ranking. Google has said that relevance and the quality of the content still count most, and Core Web Vitals are one signal among many. The better reason to care is the visitor: pages that appear quickly, respond at once and stay still are simply easier to use, on a phone with an uncertain connection most of all.