Core Web Vitals Explained: LCP, INP and CLS in Plain Words

Short answer: Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, for at least 75% of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. They are a ranking signal, but a modest one; their bigger value is a faster, calmer experience for visitors.

What Core Web Vitals are for

Speed used to be measured with dozens of technical metrics that did not always match what people experienced. Core Web Vitals reduce this to three questions a visitor would ask:

• Is it loading? How fast does the main content appear? That is LCP.
• Is it responding? When I tap or click, does the page react quickly? That is INP.
• Is it stable? Does content jump around while I am reading or about to click? That is CLS.

Google uses them as part of its page experience signals. They do not outweigh relevance and content quality, but among otherwise similar pages, better experience can help. The definitions and thresholds are documented on web.dev.

The thresholds

Each metric is assessed at the 75th percentile of page loads, separately for mobile and desktop. That means three out of four visits must be at or below the threshold. A page that is fast on your office connection but slow for a quarter of mobile visitors does not pass.

Largest Contentful Paint (LCP)

LCP marks the moment when the largest image, video poster or text block visible in the viewport finishes rendering. On most pages it is a hero image, a product photo or the main heading and first paragraph. It reflects how quickly the visitor sees what they came for.

LCP time is made of four parts: the server response (time to first byte), the delay before the browser starts loading the LCP resource, the time to download that resource, and the time to render it. Common causes of slow LCP:

• slow server responses, often from uncached dynamic pages;
• large, uncompressed hero images, or images in old formats;
• the LCP image being lazy-loaded or discovered late because it is set in CSS or injected by JavaScript;
• render-blocking CSS and JavaScript in the head;
• web fonts that delay text rendering;
• client-side rendering, where content appears only after a large script runs.

Interaction to Next Paint (INP)

INP replaced First Input Delay as a Core Web Vital in March 2024. It observes interactions during the whole visit, such as clicks, taps and key presses, and reports a value close to the slowest one. It measures how long it takes from the interaction until the browser paints the next frame showing a response.

Poor INP almost always comes from JavaScript keeping the main thread busy:

• heavy third-party scripts such as tag managers, chat widgets, ad scripts and trackers;
• large JavaScript frameworks doing a lot of work on each interaction;
• long tasks during page load that block early interactions;
• expensive event handlers that update large parts of the page at once;
• very large DOM sizes that make each update slow.

Cumulative Layout Shift (CLS)

CLS adds up unexpected movements of visible content. If you start reading and the text jumps down because an image loaded above it, or you try to tap a button and an ad pushes it away, that is a layout shift. Shifts that happen right after a user interaction, like opening a menu, do not count.

Typical causes:

• images and videos without width and height attributes or CSS aspect ratio;
• ads, embeds and iframes inserted without reserved space;
• cookie banners or promotional bars inserted at the top of the page after load;
• web fonts that swap in with different sizes than the fallback font;
• content injected by JavaScript above existing content.

Field data vs lab data

This distinction causes more confusion than anything else about Core Web Vitals:

• Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report. It is what Google uses for page experience. You see it in Search Console’s Core Web Vitals report and at the top of PageSpeed Insights, when enough data exists.
• Lab data comes from a single simulated load, for example Lighthouse in PageSpeed Insights, with a fixed device and network. It is useful for debugging but is not the assessment.

The two often disagree. A lab score of 60 can come with passing field data because real visitors have faster devices, and a lab score of 95 can hide poor INP because a lab test does not click around. INP in particular can only be measured properly in the field. Use field data to decide whether you have a problem and lab data to find out why.

Where to see your Core Web Vitals

1. Search Console, Core Web Vitals report. Groups similar URLs and shows which groups are poor, need improvement or are good, separately for mobile and desktop.
2. PageSpeed Insights. Shows field data for a URL or the whole origin, plus a Lighthouse lab test with diagnostics.
3. Browser developer tools. The Performance panel shows LCP, CLS and INP as you interact with the page.
4. Real user monitoring. Adding a small measurement script to your site gives you your own field data with page-level detail.

Small sites often lack enough traffic for URL-level field data. In that case the origin-level data and lab tests on key templates are the best available guide.

The fixes that usually help most

Every site is different, but the same fixes come up again and again:

• For LCP: enable page caching and a CDN, compress and resize hero images, serve modern formats such as WebP or AVIF, never lazy-load the main image, preload it or give it high fetch priority, and reduce render-blocking CSS and scripts.
• For INP: remove or delay third-party scripts you do not need, load non-critical JavaScript after the page is interactive, break long tasks into smaller pieces, and keep the DOM reasonably small.
• For CLS: set width and height on every image and video, reserve space for ads and embeds, show banners as overlays instead of pushing content, and use font loading strategies that minimise size changes.

Work template by template. Fixing the product template improves every product page at once, which is why grouping URLs, as Search Console does, is so useful.

Also remember that field data is a rolling average of the previous 28 days. After you deploy a fix, the reports improve gradually over about four weeks, not overnight. Note the date of each change so you can connect improvements to the work that caused them, and use lab tests or your own monitoring to confirm the fix works before the field data catches up.

Common misconceptions

• “A Lighthouse score of 100 is the goal.” The goal is passing field data. Lab scores are a debugging tool.
• “Core Web Vitals decide rankings.” They are one signal among many. Relevance and content quality matter more.
• “Only the home page matters.” Every template counts. Product and article pages often get more search traffic than the home page.
• “Desktop is enough.” Mobile is usually slower and is what most visitors use; check both.

How Site SEO AI Audit measures speed

Speed and Core Web Vitals is one of the seven areas in the audit. It combines Google PageSpeed data, including LCP and CLS, with measurements the crawler takes on every page it fetches: server response time, compression and page weight. Because slow templates usually affect many pages, issues are weighted by the share of pages they touch, so you see which fix helps the most. See plan details for how many pages each plan covers.

Related reading

• What is technical SEO? A plain guide for site owners
• Crawl budget explained: when it matters and how to save it
• Image alt text: how to write it for SEO and accessibility

The bottom line

Core Web Vitals measure three things visitors notice: how fast the main content loads, how quickly the page responds and whether it stays still. Aim for LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 for three out of four real visits. Judge by field data, debug with lab data, and fix templates rather than single pages.

DUK

Are Core Web Vitals a ranking factor?

Yes, as part of Google’s page experience signals, but a relatively light one. Great content with average vitals usually outranks weak content with perfect vitals. Their bigger benefit is a better experience for visitors.

What replaced First Input Delay?

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. INP looks at all interactions during a visit rather than only the first one, so it reflects responsiveness more fully.

Why do PageSpeed Insights and Search Console show different results?

Search Console shows field data from real users, grouped across similar pages. PageSpeed Insights shows field data when available plus a single lab test. Lab tests use a fixed device and network, so they often differ from real visits.

My site has no field data. What should I do?

Low-traffic sites often lack enough real-user data. Use origin-level data if available, run lab tests on your main templates, and consider adding your own real user monitoring to collect data directly.

Which Core Web Vital should I fix first?

Start with whichever metric fails on the templates that bring the most search traffic. On many sites that is LCP on mobile, often caused by slow server responses and large hero images.