Core Web Vitals Guide 2026: LCP, INP & CLS Explained

Your site loads in what feels like a reasonable amount of time, the design looks clean, and the content is genuinely useful, and then Google Search Console flags a Core Web Vitals issue anyway. This happens more often than most site owners expect, because Core Web Vitals don't measure whether a site looks fast to you on a fast laptop with a strong connection. They measure what real visitors, on real devices, actually experience.

Here's what the three metrics are, the current 2026 thresholds, and specific, practical fixes for each one.

Quick answer: Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading speed, with a "good" threshold under 2.5 seconds; Interaction to Next Paint (INP) for responsiveness, with a "good" threshold under 200 milliseconds; and Cumulative Layout Shift (CLS) for visual stability, with a "good" threshold under 0.1. All three are measured from real Chrome user data (not a lab test), and a page needs at least 75% of real visits to hit the "good" threshold on all three metrics to pass overall.

Core Web Vitals Thresholds at a Glance

The Three Metrics, Explained Simply

Largest Contentful Paint (LCP): Loading Speed

LCP measures how long it takes for the largest visible piece of content on the page, usually a hero image, a large block of text, or a video thumbnail, to fully render on screen. It's meant to capture the moment a visitor feels like the page has actually loaded, rather than a technical "page ready" event that doesn't match what someone actually sees.

Across the web, LCP remains one of the two metrics sites most commonly fail, a large share of mobile sites still don't hit the 2.5-second threshold, which makes it one of the highest-leverage places to focus optimization effort.

Interaction to Next Paint (INP): Responsiveness

INP measures how quickly a page responds to a visitor's interaction, a click, a tap, a keystroke, from the moment they interact to the moment the browser visually updates in response. It replaced an older metric called First Input Delay (FID) in March 2024, and any guide still referencing FID as Google's responsiveness metric is out of date.

Unlike FID, which only measured the delay before a browser started processing an interaction, INP measures the full interaction, including how long the actual response takes to render, not just how long it took to start. This makes it a stricter, more complete measurement, and it's currently the metric most sites fail most often.

INP tends to concentrate on pages with heavy JavaScript interactions, checkout flows, filter-heavy listing pages, and landing pages with complex forms are common trouble spots.

Cumulative Layout Shift (CLS): Visual Stability

CLS measures how much visible content unexpectedly shifts position while a page is loading, the frustrating experience of trying to tap a button, only for an ad or image to load above it at the last second and shift everything down, causing you to tap the wrong thing.

CLS is generally considered the easiest of the three metrics to fix, since the causes are usually specific and identifiable, images or ads loading without reserved space, web fonts causing a visible text swap, or dynamically injected content pushing everything else down.

How Google Actually Measures These

This is a detail that trips up a lot of site owners: Core Web Vitals scores in Google Search Console are field data, not a lab test. They come from the Chrome User Experience Report (CrUX), built from real Chrome users who actually visited your site, on their actual devices and connections, measured at the 75th percentile over a rolling 28-day window.

That means a perfect score in your browser's developer tools on a fast office connection means very little if a meaningful share of your real visitors, often on mid-range phones or slower mobile connections, are having a noticeably worse experience. It also means changes take time to show up in official reporting: after deploying a fix, expect to wait several weeks for the 28-day CrUX window to reflect the improvement, even though the fix itself might be instant.

Google's own web.dev Core Web Vitals documentation is the authoritative source for exact methodology and any threshold updates going forward.

How to Fix a Poor LCP Score

Optimize your largest image. Compress hero images, serve them in modern formats (WebP or AVIF instead of JPEG or PNG), and size them appropriately for the display rather than shipping an oversized file the browser has to scale down.

Preload critical resources. Adding a preload hint for your hero image or critical font tells the browser to prioritize fetching it immediately, rather than discovering it later in the page's load sequence.

Remove render-blocking resources. Large CSS or JavaScript files that must fully load before the page can render delay LCP directly. Inlining critical CSS and deferring non-essential scripts reduces this delay.

Use server-side rendering or a fast hosting stack. A slow server response time (Time to First Byte) adds delay before the browser can even start rendering anything, which directly pushes LCP later.

How to Fix a Poor INP Score

Break up long JavaScript tasks. A single long-running script blocks the browser from responding to user input until it finishes. Splitting large tasks into smaller chunks lets the browser stay responsive between them.

Reduce unnecessary JavaScript. Every unused plugin, tracking script, or heavy library adds processing overhead that competes with actual user interactions for the browser's attention. Auditing and removing what isn't earning its cost is one of the highest-impact fixes available.

Debounce or throttle expensive interaction handlers. For interactions that trigger complex logic (live search-as-you-type, dynamic filtering), limiting how often that logic actually runs, rather than firing on every single keystroke, reduces the processing load per interaction.

Avoid layout thrashing during interactions. Reading and writing to the DOM repeatedly within a single interaction handler forces the browser to recalculate layout multiple times unnecessarily, adding measurable delay to the response.

How to Fix a Poor CLS Score

Set explicit width and height on every image, video, and iframe. This is the single most common CLS fix. Without explicit dimensions, the browser doesn't know how much space to reserve before the content loads, so everything below it jumps once it does.

Reserve space for ads and dynamically injected content. Any element that loads asynchronously (ads, embedded widgets, cookie banners) needs a defined space reserved in the layout ahead of time, rather than being allowed to push content around once it arrives.

Use font-display: swap carefully, and preload key fonts. Web fonts that load after the page's initial render can cause a visible text swap that shifts layout as the final font renders at a different size than the fallback. Preloading critical fonts reduces this gap.

Avoid inserting content above existing content. Adding a new element (a promotional banner, for example) above content a visitor is already looking at causes an immediate, jarring layout shift, if this pattern is necessary, reserve the space for it from the start rather than inserting it dynamically.

Why This Matters Beyond Search Rankings

Core Web Vitals are part of Google's broader page experience signals, and they do factor into search ranking, but the ranking impact, while real, is usually smaller than the direct business impact of a faster, more stable site.

Bounce rate. Visitors abandon slow-loading pages at a measurably higher rate, and that abandonment happens before your content, offer, or design ever gets evaluated.

Conversion rate. A form that lags when submitted, or a button that shifts position right as someone taps it, are silent conversion leaks, the visitor was ready to convert and the page got in the way.

AI crawlability. As covered in our guide on optimizing for Google AI Overview, technical performance affects whether a page gets crawled and indexed efficiently in the first place, which is a prerequisite for being cited by AI systems at all, content quality alone isn't enough if the page itself is slow or unstable.

A Practical Checklist for Auditing Your Site

1. Run your key pages through Google's PageSpeed Insights tool to see both lab data (Lighthouse) and, where available, real field data from CrUX
2. Check Google Search Console's Core Web Vitals report for site-wide field data across all three metrics
3. Prioritize fixing whichever metric is currently in the "poor" band first, before fine-tuning metrics that are already in "good" or "needs improvement"
4. Re-test after each significant change, but expect official Search Console data to lag behind actual fixes by several weeks due to the rolling 28-day measurement window
5. Set an internal threshold slightly stricter than Google's official "good" range (for example, treating anything within 20% of the poor threshold as a warning sign) to catch regressions before they fully cross into failing territory

Frequently Asked Questions

What are the three Core Web Vitals?

The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading speed; Interaction to Next Paint (INP), which measures responsiveness; and Cumulative Layout Shift (CLS), which measures visual stability.

What replaced First Input Delay (FID)?

Interaction to Next Paint (INP) replaced First Input Delay as Google's official responsiveness metric in March 2024. Any current guide referencing FID as an active Core Web Vital is outdated.

What is a good LCP score?

A "good" Largest Contentful Paint score is under 2.5 seconds, measured at the 75th percentile of real Chrome user visits.

What is a good INP score?

A "good" Interaction to Next Paint score is under 200 milliseconds, measured at the 75th percentile of real Chrome user visits.

What is a good CLS score?

A "good" Cumulative Layout Shift score is under 0.1, measured at the 75th percentile of real Chrome user visits.

Do Core Web Vitals directly affect Google rankings?

Yes, they're part of Google's page experience signals and factor into ranking, though the effect is generally smaller than the direct impact on bounce rate and conversion rate from a faster, more stable page.

How long does it take to see Core Web Vitals improvements in Search Console?

Because official scores are based on a rolling 28-day window of real user data, expect to wait several weeks after deploying a fix before Search Console reflects the improvement, even if the technical fix itself is immediate.

Where to Go From Here

Fixing Core Web Vitals often requires changes at the code and hosting level, not just plugin settings, which is where most DIY attempts stall out. Manoratech's Website Development & Sales Funnels service builds every site with Core Web Vitals, mobile performance, and on-page SEO wired in from the start, not bolted on after launch. Book a free strategy call if your current site is failing these metrics and you want a direct audit of what's causing it.

Reference: web.dev Core Web Vitals documentation and Google Search Central.