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

Core Web Vitals are three measurements Google uses to describe how a page feels to the people using it: how quickly the main content appears, how quickly the page reacts to a tap or key press, and whether the layout holds still. They’re measured on real visits, and Google’s ranking systems use them, though relevant content still comes first.

If Search Console has flagged URLs as “poor”, here’s what each metric measures, what usually makes a page fail, the first fix to try and how to read the report.

The short answer

Core Web Vitals are three metrics of real-world page experience, each with a “good” threshold published by Google:

• Largest Contentful Paint (LCP) measures loading: how long until the largest image or text block in view appears. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visibly react to a click, tap or key press. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS) measures visual stability: how much content moves unexpectedly. Good is 0.1 or less.

A page passes when all three are good at the 75th percentile of real visits, assessed separately for mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Core Web Vitals thresholds, and who they’re measured on

Google sorts each metric into three bands:

The data comes from real visitors. Google uses the Chrome UX Report (CrUX): anonymised measurements from opted-in Chrome users on desktop and Android, collected over a rolling 28 days. A page that’s instant on office Wi-Fi can still fail for visitors on mid-range phones and patchy mobile data.

Three visits in four must be good. A few very slow visits can’t sink the result, but a fast average isn’t enough either: if more than a quarter of visits wait over 2.5 seconds for the main content, the page doesn’t pass on LCP.

That’s why the Lighthouse score in PageSpeed Insights often disagrees with Search Console: Lighthouse is one simulated page load with nobody interacting, useful for diagnosis but not what Google assesses. Our guide to reading a PageSpeed Insights report explains the difference, and the website speed optimisation guide covers the wider work of making a site fast.

Largest Contentful Paint (LCP): has the main content arrived?

LCP is the time from when a visitor starts loading the page until the largest image, video or text block in the viewport has been drawn. On most business sites that’s the hero image or main headline.

What usually causes a poor LCP

Google’s web.dev guidance splits LCP into four parts, each with a different fix:

1. Server response: how long the HTML takes to arrive. Slow hosting and no page caching are the usual causes.
2. Load delay: how long before the browser discovers the image. Hero images that are lazy-loaded, set as CSS backgrounds or injected by a slider are found late.
3. Load time: how long the file takes to download, often an uncompressed camera photo.
4. Render delay: the gap before the downloaded image appears, usually because stylesheets, scripts or fonts are still blocking the page.

First fixes for LCP

• Identify the LCP element first. PageSpeed Insights names it in its diagnostics. It’s sometimes a headline, not the image you expected.
• Never lazy-load it. Lazy loading is for images further down. Adding fetchpriority="high" to the hero asks the browser to fetch it early.
• Right-size it. A hero sized for the screen and saved as WebP or AVIF is usually a fraction of the original, as our image optimisation guide explains.
• Fix a slow server. If the HTML alone eats much of the 2.5-second budget, no image tweak will help: add page caching or move to better hosting.
• Clear what blocks rendering. Render-blocking resources explained walks through the standard fixes for heavy CSS, scripts and fonts.

Interaction to Next Paint (INP): does the page react when you tap?

INP measures how long the page takes to show a visual response after a click, tap or key press: a menu opening, an accordion expanding, a button showing it’s been pressed. It watches every interaction during the visit and reports one of the slowest. Scrolling and hovering don’t count.

Why INP replaced FID

First Input Delay measured only the wait before the browser could start handling the first interaction, ignoring processing, the screen update and every later interaction. A page could pass FID comfortably and still feel sluggish. INP covers the whole interaction across the whole visit. It replaced FID as a Core Web Vital on 12 March 2024, which is why some sites saw new warnings after the switch.

What usually causes a poor INP

Almost always, JavaScript keeping the browser’s main thread busy: clicks are handled on the same thread that runs scripts, so a tap during a long task waits. Common culprits:

• tag managers carrying years of old marketing tags
• chat widgets, cookie consent tools, review widgets and social embeds
• page builders, sliders and animation libraries loading heavy scripts on every page
• very large pages with thousands of elements, which make every screen update more work
• click handlers that do heavy work before updating the screen

First fixes for INP

• Audit what runs on the page. Remove unused tags and plugins, and load the rest only where needed. Our guide to third-party scripts and website speed shows how to list what’s loading.
• Load widgets on demand. A chat widget, map or video can wait until someone clicks it.
• Respond first, work second. Show the pressed state or a spinner immediately, then do the heavy work. Developers call this yielding to the main thread.
• Test by hand. A standard Lighthouse test can’t measure INP because nobody interacts with the page, so it reports Total Blocking Time instead. To reproduce a problem, use the Performance panel in Chrome DevTools with CPU throttling on, and tap through menus and forms.

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

CLS measures unexpected movement: text that drops as an image loads above it, or a button that slides away as you tap it. Each shift is scored by how much of the screen moved and how far, and CLS reports the worst burst during the visit. Movement within half a second of the visitor’s own tap or key press doesn’t count, because opening a menu is meant to change the layout.

What usually causes a poor CLS

• images, videos and iframes without a width and height
• maps, review widgets and ads that load late and push content down
• cookie or promotion banners inserted at the top after the page renders
• web fonts that swap in at different proportions from the fallback font
• animations that change position or size instead of using CSS transforms

First fixes for CLS

• Give images and embeds dimensions. width and height attributes, or a CSS aspect-ratio, let the browser reserve the space. A minimum height does the same for late-loading widgets.
• Overlay banners, don’t insert them. A cookie notice fixed to the bottom of the screen shifts nothing.
• Match your fallback font with adjustments such as size-adjust, so the swap barely moves the text.
• Check the whole visit. A standard lab test only records shifts while the page loads. If Search Console flags CLS that Lighthouse doesn’t, scroll the page on a phone: unsized images further down and resizing sticky headers are common culprits.

How to read the Core Web Vitals report in Search Console

The report sits in the Experience section of Search Console, with separate charts for mobile and desktop showing how many indexed URLs are Poor, Needs improvement or Good. A URL takes the status of its worst metric: good LCP and CLS with a poor INP still makes it a poor URL.

If the report shows no data at all, the Chrome UX Report usually lacks enough real visits to your site. That’s common on lower-traffic sites, not a fault. Test your main templates in the lab, and check whether PageSpeed Insights has field data for your whole site (the origin).

Why URLs are grouped

Search Console doesn’t judge URLs one by one. It groups pages that offer a similar experience, usually those built from the same template, reports one 75th-percentile value per group and gives every URL in the group that status. A warning on 400 URLs rarely means 400 problems. Usually one template (every blog post, product or project page) has one problem, and fixing it fixes the group.

Working through an issue

1. Start with Poor issues on mobile, where problems are usually worst.
2. Open the issue to see the affected groups, their values and example URLs.
3. Test an example URL in PageSpeed Insights and use the diagnostics to find the cause.
4. Fix the template, then confirm the improvement with a lab test.
5. Click Start tracking on the issue page. Search Console then watches fresh field data for the issue over a 28-day window.

Why fixes take about 28 days to show

Field data is a rolling 28-day window. The day after a fix, the sample still holds 27 days of slower visits, so the 75th percentile improves gradually over about four weeks as they drop out. Until then, lab tests are your confirmation.

How much do Core Web Vitals matter for Google rankings?

They count, but they don’t outrank relevance. Google Search Central’s page experience documentation says Core Web Vitals are used by its ranking systems and recommends good results. It also says the most relevant content can still rank when page experience is sub-par, that there’s no single page experience signal, and that good scores don’t guarantee top rankings.

So speed won’t beat a far better answer, but between similarly useful pages, experience can help. Treat Core Web Vitals as one item on a technical SEO checklist, not a score to chase.

The stronger reason to care is your visitors. A slow hero loses people before they see your offer, a laggy button makes a form feel broken, and a jumping layout causes mis-taps. Those costs arrive whether Google is watching or not, as how page speed affects conversions explains.

Frequently asked questions

Do I need a Lighthouse score of 100 to pass Core Web Vitals?

No. The score summarises one simulated lab test, while the assessment uses real visits. A page scoring in the 70s can pass, and a high score can still fail.

Are iPhone visitors included in Core Web Vitals data?

Not in Google’s field data, which comes from Chrome on desktop and Android. iPhone users still feel slow images, laggy buttons and shifting layouts, so the same fixes help them.

Are Time to First Byte and First Contentful Paint Core Web Vitals?

No. They’re supporting metrics shown in PageSpeed Insights and useful for diagnosis: a slow Time to First Byte often explains a poor LCP. Only LCP, INP and CLS count towards the assessment.

Can a WordPress website pass Core Web Vitals?

Yes, when the hosting, theme, page builder and plugins are chosen with speed in mind. Our guide to speeding up a WordPress website sets out the order to work in.

What to do next

Most failures trace back to a slow server, an oversized hero image, too much JavaScript or space nobody reserved. Fix one template at a time, starting with Poor issues on mobile, and let the 28-day window catch up.

Keeping the results is harder. Every new plugin, tag, widget and oversized photo pulls the numbers back, so speed belongs in routine care, not a one-off project. Our website care plans keep WordPress updated, backed up and monitored, and the Growth plan adds monthly improvements and speed work. Want a second opinion on a Search Console warning first? A free website audit checks your site’s speed and shows where to start.