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

Core Web Vitals are three metrics Google uses to measure real-world user experience: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less.

Key takeaways

• LCP asks "when did the main content show up?" Good: 2.5 s or less.
• INP asks "when I clicked or typed, how long before the screen reacted?" Good: 200 ms or less. It replaced FID as a Core Web Vital in March 2024.
• CLS asks "did things jump around while I was reading?" Good: 0.1 or less.
• Google judges you on field data from real Chrome users, not on a single lab test.
• Core Web Vitals are a ranking signal, but relevance and content quality matter far more. Fix them for users first.

The thresholds at a glance

Each metric has three bands. Google evaluates the 75th percentile of page loads, separately for mobile and desktop. That means 75% of visits need to hit the "good" number, not just the average visit.

LCP: when does the main content appear?

Largest Contentful Paint is the time from when the user starts loading the page to when the largest visible image or text block in the viewport finishes rendering. On a blog post that is usually the hero image or the headline. On a product page it is often the main product photo.

Elements that can count as the LCP element include <img> elements, <image> inside SVG, video poster images, elements with a CSS background image loaded via url(), and block-level elements containing text.

What usually makes LCP slow

• Slow server response. If the HTML takes 1.5 seconds to arrive, you have only one second left for everything else. Check Time to First Byte (TTFB) first.
• The hero image is discovered late. Images set as CSS backgrounds or injected by JavaScript cannot be fetched until the CSS or script runs.
• The hero image is lazy-loaded. loading="lazy" on the above-the-fold image delays it on purpose. Only lazy-load images below the fold.
• Oversized files. A 2,400-pixel-wide JPEG served to a phone wastes bandwidth.
• Render-blocking CSS and fonts. Large stylesheets and web fonts can hold back the first paint.

How to fix it

Put the hero image in the HTML as a real <img>, give it explicit dimensions, serve a responsive size, and tell the browser it matters:

<img src="/images/hero-800.webp"
     srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
     sizes="(max-width: 800px) 100vw, 800px"
     width="800" height="450"
     fetchpriority="high"
     alt="Product dashboard on a laptop">

Then work on the server: page caching, a CDN for static assets, and fewer slow database queries on the template. If your LCP element is text, make sure web fonts use font-display: swap or are preloaded so text is not invisible while the font downloads.

INP: how fast does the page react?

Interaction to Next Paint observes clicks, taps and key presses during the whole visit and reports roughly the worst one (for pages with very many interactions, a few outliers are ignored). The measured time runs from the user's input until the browser paints the next frame showing a response, such as a menu opening or a button changing state.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction started being processed, so a page could pass FID while still feeling sluggish. INP is stricter because it covers every interaction and the full time to visual feedback.

What usually makes INP slow

• Long JavaScript tasks. While the main thread is busy running a 300 ms script, it cannot respond to a tap.
• Heavy third-party scripts. Chat widgets, tag managers loading many tags, A/B testing tools and ad scripts all compete for the main thread.
• Expensive event handlers. A click handler that re-renders a large list or recalculates layout for the whole page.
• Large DOM size. Thousands of elements make every style recalculation and repaint slower.

How to fix it

• Audit third-party scripts and remove the ones nobody uses. This is often the fastest win.
• Give immediate visual feedback first, then do the heavy work. For example, show a spinner, then yield to the browser (with setTimeout or scheduler.yield() where supported) before running the expensive logic.
• Break long tasks into smaller chunks so the browser can handle input in between.
• Defer non-critical scripts with defer or load them after user interaction.

CLS: does the layout stay put?

Cumulative Layout Shift scores how much visible content moves unexpectedly. The score combines how much of the viewport moved and how far it moved. Shifts are grouped into "session windows" and the worst window is reported. Shifts that happen within 500 ms after a user's click or key press are excluded, because the user expected something to change.

The classic bad experience: you go to tap "Read more", an ad loads above it, the text jumps down, and you tap the ad instead.

Common causes and fixes

Field data vs lab data

This distinction confuses a lot of site owners, so it is worth getting right.

• Field data comes from real Chrome users via the Chrome User Experience Report (CrUX). It reflects a rolling 28-day window. This is what Google uses for the Core Web Vitals assessment and what Search Console's Core Web Vitals report shows.
• Lab data comes from a simulated load (Lighthouse) on a fixed device and network profile. It is repeatable and great for debugging, but it is one synthetic visit.

Lab tools cannot measure INP directly because no real user is interacting. Lighthouse reports Total Blocking Time (TBT) instead, which correlates with responsiveness problems. If your lab TBT is high, expect INP trouble in the field.

Small or new sites often have no field data at all, because CrUX only includes pages and origins with enough traffic. In that case you will see lab results only, and you should rely on them as a guide.

Because field data covers 28 days, a fix you deploy today will take up to four weeks to fully show in the field numbers. Do not panic if the report does not move the next morning.

How to check your pages

1. Run your most important templates (home page, a category page, an article, a product page) through the Page Speed Checker, which uses Google PageSpeed data and shows both field and lab results where available.
2. Look at the field section first. If it says "passed", your real users are fine, even if the lab score is not 100.
3. If a metric fails, read the diagnostics in the lab section. They usually name the LCP element, the scripts blocking the main thread and the elements that shifted.
4. In Google Search Console, open the Core Web Vitals report to see which groups of similar URLs fail. Fixing a template fixes every URL that uses it.
5. Test on mobile. Most sites fail on mobile long before desktop because phones have slower CPUs.

How much do Core Web Vitals affect rankings?

Core Web Vitals are part of Google's page experience signals, and Google has confirmed they are used in ranking. Google has also been clear that great page experience does not override relevance: a highly relevant, helpful page with average vitals can outrank a fast page that does not answer the query. Google does not publish a weight for these metrics, and anyone claiming a precise number is guessing.

The practical view: treat Core Web Vitals as a tie-breaker in search and a real factor in conversions and user satisfaction. Pages that load quickly and do not jump around are simply easier to use.

Common mistakes

• Chasing a lab score of 100. The pass or fail assessment is based on field data. A lab score of 85 with passing field data is fine.
• Testing only the home page. Your home page is often the most optimized page on the site. Test the templates that get search traffic.
• Lazy-loading everything. Lazy-loading the hero image is one of the most common causes of poor LCP.
• Adding a speed plugin and stopping there. Plugins help with caching and minification but cannot remove a slow chat widget or a bloated theme.
• Still optimizing for FID. FID is retired. Old guides that focus on it are out of date.

Quick checklist

• Hero image is a real <img> with width, height and fetchpriority="high", and is not lazy-loaded.
• TTFB is low thanks to page caching and a decent host or CDN.
• Third-party scripts are audited, deferred or removed.
• All images, embeds and ad slots have reserved space.
• Banners overlay content instead of pushing it down.
• Field data checked for mobile and desktop, then rechecked about four weeks after fixes.