freeseobot

Core Web Vitals Explained: LCP, INP and CLS Made Simple

A plain-English guide to Core Web Vitals: what LCP, INP and CLS measure, the pass thresholds, how to check your site, and the usual fixes for each.

By FreeSEOBot Editorial · Published · 7 min read

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: LCP (how fast the main content appears), INP (how fast the page reacts when you tap or click), and CLS (how much the layout jumps around while loading). A page passes when at least 75% of real visits score "good" on all three: LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less.

Google confirms that Core Web Vitals are used by its ranking systems. It also says a good score does not guarantee top rankings, so treat them as a way to stop losing visitors, not a magic lever.

What are the three Core Web Vitals?

Metric What it measures in plain English Good Needs improvement Poor
LCP, Largest Contentful Paint Time until the biggest image or text block on screen has appeared 2.5 s or less 2.5 s to 4.0 s Over 4.0 s
INP, Interaction to Next Paint Delay between a tap, click or key press and the screen visibly responding 200 ms or less 200 ms to 500 ms Over 500 ms
CLS, Cumulative Layout Shift How much visible content unexpectedly moves 0.1 or less 0.1 to 0.25 Over 0.25

"ms" means milliseconds. 200 ms is one fifth of a second.

INP replaced an older metric, First Input Delay (FID), as a Core Web Vital on 12 March 2024. FID only measured the delay before the first interaction started; INP looks at the responsiveness of interactions across the whole visit, so it is a much stricter test. If an older guide tells you to fix FID, it is out of date.

Why the 75th percentile matters

Google does not judge your page on one test. It looks at real Chrome users' visits over time and takes the 75th percentile, separately for mobile and desktop. In plain terms: three out of four visits need to be "good" for the page to pass. Your fast office broadband is not what counts; your customers' phones on patchy mobile data are.

How do you check your Core Web Vitals?

Use two free Google tools:

  1. Search Console > Experience > Core Web Vitals. Shows groups of similar URLs as Good, Needs improvement or Poor, based on real-user data. Start here to see which templates (product pages, blog posts) have problems.
  2. PageSpeed Insights (pagespeed.web.dev). Enter any URL. The top section, "Discover what your real users are experiencing", uses the previous 28 days of real Chrome data. The lower "Diagnose performance issues" section is a single lab test on a simulated device.

Two things confuse people:

  • Lab and real-user scores often disagree. The lab test runs once on fixed settings; real data covers many devices and networks. When they conflict, the real-user data is what Google uses.
  • Small sites may have no real-user data. If a page lacks enough traffic, PageSpeed Insights falls back to data for your whole domain, and if that is too thin it shows none. Use the lab results as a guide in that case.

INP needs real people interacting with the page, so the standard lab test does not report it. You will see it in the real-user section and in Search Console.

Our SEO checker flags common causes, such as images without dimensions, alongside the rest of your on-page checks.

How to fix LCP (slow main content)

LCP is usually your hero image, a banner, or the first big block of text. Google's web.dev team breaks LCP into four parts: time for the server to respond, delay before the main image starts downloading, download time, and delay before it is drawn. Fixes, roughly in order of impact for small sites:

  • Speed up the server response. Cheap shared hosting and uncached pages are common culprits. Turn on page caching in your CMS or use a CDN (a content delivery network that serves files from locations near the visitor).
  • Do not lazy-load the main image. Lazy loading delays images until they are near the screen, which is great for images lower down and bad for the one at the top.
  • Make the main image discoverable early. It should be a normal <img> in the HTML, not injected by a script or set as a CSS background. If it must come from CSS, preload it:
<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">
  • Compress and resize images. Serve WebP or AVIF at the size it is actually displayed, not a 4,000-pixel camera original.
  • Cut render-blocking code. Large CSS and JavaScript files in the page head can delay everything.

How to fix INP (slow response to taps and clicks)

Poor INP means the browser is busy when someone interacts, usually running JavaScript. It feels like a button that does nothing for a moment.

  • Remove scripts you do not need. Old tracking pixels, unused chat widgets, and abandoned A/B testing tools all compete for the same processor time.
  • Audit third-party embeds. Review widgets, social feeds and some consent banners can be heavy. Load them only on the pages that need them.
  • Break up long tasks. For developers: web.dev recommends splitting long-running JavaScript into smaller tasks and yielding to the main thread so the browser can respond in between.
  • Keep the page lighter. Very large pages, with thousands of HTML elements, take longer to update after each interaction. web.dev lists minimising DOM size as an INP fix.
  • Check plugins. On WordPress and similar platforms, page builders and plugins add scripts site-wide. Disable one at a time and retest.

How to fix CLS (jumping layout)

CLS is the one visitors notice most: you go to tap a link and an advert pushes it down. web.dev lists the usual causes as images and videos without set dimensions, web fonts that render a different size from the fallback font, ads and widgets that resize themselves, and content inserted above what is already on screen.

  • Give every image and video a width and height so the browser reserves the space:
<img src="/images/team.webp" width="800" height="450" alt="Our team outside the Leeds workshop">
  • Reserve space for ads, embeds and banners with a fixed minimum height, so they fill a slot instead of pushing content.
  • Do not insert banners above existing content after the page loads. Cookie notices and promo bars should overlay or sit at the bottom.
  • Match fallback fonts to your web font's size, or preload the font file, so text does not reflow when the font arrives.

What to fix first

Situation Start with
All three metrics poor on mobile Hosting and caching (helps LCP), then remove unused scripts
Only CLS failing Image dimensions and ad or banner slots, usually a quick fix
Only INP failing Third-party scripts and plugins
Only one page template failing That template's hero image or embed

After you fix something, Search Console's report updates slowly because it is based on 28 days of data. Use the Validate fix button in the report to have Google monitor the affected URLs.

Core Web Vitals are one part of a wider health check. Our step-by-step free SEO audit puts them in context, and the technical SEO checklist covers the other 29 checks.

FAQ

Do Core Web Vitals affect Google rankings?

Yes, Google says Core Web Vitals are used by its ranking systems. It also says it will still show the most relevant content even if its page experience is weaker, so a fast page with thin content will not outrank a slower, much better answer.

Why is my PageSpeed score high but Core Web Vitals failing?

The 0 to 100 performance score comes from a single lab test. Core Web Vitals pass or fail on 28 days of real-user data. Real visitors on slower phones and networks can have a much worse experience than the lab simulation.

Is FID still a Core Web Vital?

No. Interaction to Next Paint (INP) replaced First Input Delay (FID) on 12 March 2024. Any report or tool still grading you on FID is out of date.

Does Google measure desktop and mobile separately?

Yes. web.dev recommends measuring the 75th percentile separately for mobile and desktop, and Search Console shows a separate Core Web Vitals report for each.

Sources

More guides