Core Web Vitals in 2026: LCP, INP and CLS explained

Quick check: what counts as good Core Web Vitals?

LCP should be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less at the 75th percentile of real user visits. Check mobile and desktop separately. A Lighthouse score is useful for debugging, but it is not the same thing as passing real-user Core Web Vitals.

The three metrics and their thresholds

Each metric has a "good" and a "poor" boundary. A page passes when it is good at the 75th percentile of real visits, measured separately for mobile and desktop.

• Largest Contentful Paint (LCP): good at 2.5 s or less, poor above 4 s. It marks when the largest image or text block in the viewport has rendered.
• Interaction to Next Paint (INP): good at 200 ms or less, poor above 500 ms. It measures the delay between a tap, click or key press and the next visual update, across the whole visit.
• Cumulative Layout Shift (CLS): good at 0.1 or less, poor above 0.25. It sums unexpected layout movements, such as text jumping when an image or banner loads late.

The thresholds are the ones Google publishes on web.dev and in the individual metric articles. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024; any tool or report that still grades you on FID is out of date.

Field data versus lab data

Field data comes from real Chrome users through the Chrome UX Report (CrUX), aggregated over the previous 28 days. This is what Google uses. Small sites often have no field data because there is not enough traffic to publish it.

Lab data comes from a single simulated load in Lighthouse, usually on a throttled mid-range phone. It is reproducible and great for debugging, but it cannot measure INP because nobody interacts with the page. Lighthouse reports Total Blocking Time (TBT) instead, which correlates well with INP problems.

Use the lab data to find causes and the field data to confirm that a fix worked for real visitors. Expect field numbers to change gradually, because the 28-day window has to roll over first.

How to diagnose a slow page in five minutes

• Test the exact URL on mobile. Note the LCP element, render-blocking requests and large images.
• Check field data separately. If CrUX is unavailable, record that as insufficient traffic data, not a pass or a failure.
• Find the dominant delay. A large hero image needs a different fix from a slow server response or JavaScript that blocks interaction.
• Fix one cause and test again. Keep the same URL and document what changed.
• Watch the trend. Lab scores may move immediately, but real-user Core Web Vitals roll over gradually.

Check your website's speed for free: the analysis runs Google PageSpeed for mobile and desktop on one URL. The website speed test page explains how the mobile and desktop results are combined into one score.

How to improve LCP

Most slow LCP values come from four places: a slow server response, a render-blocking stylesheet or script, a hero image that is discovered late, or an image that is simply too large.

• Keep server response time (TTFB) low with page caching and a CDN.
• Do not lazy-load the hero image. Give it fetchpriority="high" and, if it is set in CSS, preload it.
• Serve the hero in a modern format (AVIF or WebP) at the size it is displayed, with srcset for different screens.
• Inline the critical CSS or keep the main stylesheet small, and defer scripts that are not needed for the first view.
• Replace hero sliders and autoplay videos with one strong static image where possible.

How to improve INP

Poor INP almost always means the main thread is busy when the user interacts. Heavy JavaScript is the usual cause, and third-party scripts are often the biggest share of it.

• Remove scripts you no longer use, especially leftovers from old apps, plugins and tag manager experiments.
• Load chat widgets, heatmaps and review widgets after the page is interactive, or only when the user opens them.
• Break long tasks into smaller ones and keep click handlers light, so the browser can paint quickly after each interaction.
• Avoid huge DOM trees: very large menus and product grids make every update slower.

How to improve CLS

Layout shifts happen when the browser does not know how much space something will need until it loads.

• Set width and height (or aspect-ratio) on every image, video and iframe.
• Reserve space for ad slots, cookie banners and embeds instead of pushing content down when they appear.
• Use font-display: swap with a fallback font of similar size, or preload the main web font, to reduce text reflow.
• Never insert content above existing content unless the user asked for it.

What the Sitequiry report shows

Sitequiry runs Google PageSpeed Insights for mobile and desktop and shows LCP, FCP, TBT and CLS on bands that use the thresholds above, together with the loading filmstrip and page weight by resource type. When Google has CrUX field data for the URL or origin, the report uses it as well. When PageSpeed is unavailable, the report says so and labels the speed score as an estimate instead of inventing numbers.

Frequently asked questions