The Lighthouse score indicates 98, but Search Console continues to indicate the red “Poor” warning on 50% of your URLs. If the above sounds familiar to you, then this is the first big lesson of Core Web Vitals in 2026 – real users decide whether you pass or fail, not your laptop.
Core Web Vitals (CWV) are Google’s real-user metrics that cover loading performance, interactivity and visual stability. CWVs are used in Google’s Page Experience signals and correlate with KPIs you care about more than rankings: bounce rate, conversions and trust. The ranking effect can be viewed as a tiebreaker rather than a magic lever. Content relevance comes first. However, when comparing similar pages, the faster and more steady page wins, keeping most of the traffic it generates.
This guide provides information on what to measure, how to diagnose problems and how to fix each metric using coding-level fixes.
Three Metrics and Their Thresholds in 2026
The list hasn’t changed since March 2024, when Interaction to Next Paint (INP) replaced First Input Delay (FID). FID has been retired, so if some tool indicates it, then this tool is obsolete. You will see claims online about tighter thresholds, but the widely published “good” targets remain the same:
Metric
What it measures
Good
Poor
LCP (Largest Contentful Paint)
Loading speed
≤ 2.5 s
> 4.0 s
INP (Interaction to Next Paint)
Responsiveness
≤ 200 ms
> 500 ms
CLS (Cumulative Layout Shift)
Visual stability
≤ 0.1
> 0.25
There are two things that need to be noted. The first is that each metric will be evaluated on the basis of the 75th percentile of actual visits, meaning that your slowest quarter of users determines your score. The second is that mobile and desktop are evaluated separately, and mobile is often the more difficult to pass.
Measure First: Field Data Beats Lab Data
Determine the metric that fails prior to altering any single line of code. For that purpose, the two types of data are required:
Field data is gathered from actual users. Use the Chrome User Experience Report (CrUX), the Core Web Vitals report in Search Console, as well as the field portion of the PageSpeed Insights tool. That is what matters for an assessment and represents a rolling 28-day period.
Lab data is generated by simulated tests on Lighthouse or Chrome DevTools. Lab data is repeatable and perfect for debugging purposes, however, cannot reflect all types of devices, networks, and user behavior patterns.
In order to do a proper job, use your own real-user testing along with the web-vitals JavaScript library offered by Google. With the attribution build of the library, determine the source of LCP, slow interaction leading to INP and layout shift movements.
import { onLCP, onINP, onCLS } from ‘web-vitals/attribution’;
Debugging procedure in practice: discover which metric is broken, figure out which component or interaction is causing the problem, replicate it using DevTools with CPU and network throttling, fix it, and verify it through real-world data. Let’s go through the metrics one by one.
Fixing LCP: Make the Main Content Arrive Faster
LCP marks when the largest visible element, usually a hero image, a large heading or a video poster, finishes rendering. Think of total LCP as four parts added together:
LCP = TTFB + resource load delay + resource load time + element render delay
PageSpeed Insights and CrUX break this down for you, so use that breakdown to find which part is the bottleneck instead of guessing.
➜ Slow server response (TTFB)
If it takes a second for the server to reply, everything else will lag behind. Some causes include slow hosting, non-cached database queries, and too many redirects. Use a CDN on top of your website, cache your HTML files, switch to HTTP/2 or HTTP/3, and get rid of any extra redirects. Server-side rendering with edge caching often outperforms client-side rendering for LCP.
➜ Late discovery of the LCP image
An often made error is that of the image used for the LCP being discovered late by the browser because it is part of the CSS background, JavaScript injection, or lazy loading. The browser cannot fetch what it is unaware of. Let your image become a regular <img> tag in the HTML and increase its priority:
<img src=”hero.avif” width=”1200″ height=”600″
fetchpriority=”high” alt=”Product hero”>
Never put loading=”lazy” on the LCP image. Lazy-loading is for images below the fold. You can also preload the image with <link rel=”preload” as=”image” href=”hero.avif” fetchpriority=”high”> when it can’t be discovered early otherwise.
➜ Heavy images
Serve modern formats such as AVIF or WebP, size images for the actual display area and use srcset and sizes so phones don’t download desktop-sized files. A 2 MB hero image on a mobile connection will fail LCP no matter how clean your code is.
➜ Render-blocking resources
CSS and synchronous scripts in the <head> delay the first paint. Inline critical CSS, defer the rest, load scripts with defer or async, and cut unused CSS. If a web font blocks your LCP heading, use font-display: swap and preload the key font file.
Fixing INP: Keep Interactions Snappy
INP is the hardest metric for developers to work with, and there is a good reason why. It measures all clicks, taps, and keystrokes during a visit and gives an estimate of the worst one. A site might have lightning-fast pages but still fail on INP if something like the navigation, filters, or shopping cart feels slow.
Interactions have three stages: input latency (waiting until the main thread becomes available), processing latency (your event listeners), and presentation latency (painting the results by the browser). Almost all cases of INP issues are caused by a busy main thread.
🡪 Break up long tasks
Any task over 50 ms can block input. Split heavy work into smaller chunks and yield to the browser between them:
async function processItems(items) {
for (const item of items) {
heavyWork(item);
// Let the browser handle pending input
if (globalThis.scheduler?.yield) {
await scheduler.yield();
} else {
await new Promise(r => setTimeout(r, 0));
}
}
}
🡪 Do less work in event handlers
Provide visual feedback ASAP, and do anything else later. Update the state first before sending data analytics, storing, and doing other calculations later. Debounce scroll, resizing and search-as-you-type events.
Taming third-party scripts
Third-party scripts including tag managers, chat boxes, A/B testing software and ad scripts can be the cause of the most intensive tasks on your pages. Inspect third-party scripts in the DevTools Performance pane. Eliminate them if possible; postpone execution for the moment when needed, or run some processing in Web Worker if applicable.
Controlling rendering cost
DOMs that are big by size will cause expensive changes even for every small update. Use lightweight DOM structures, implement list virtualization, avoid layout thrashing, which occurs when code queries layout information and changes CSS properties in an alternating loop. Frameworks like React and others use memoization, component splitting, start transitions and other techniques to prevent unnecessary re-renders. Deliver less code through code splitting and tree-shaking because every byte will be loaded and run.
Fixing CLS: Stop the Page from Jumping
CLS measures how much visible content moves unexpectedly. Everyone knows the annoyance of tapping a button just as an ad loads and pushes it away. CLS is usually the easiest metric to fix because the causes are predictable.
🢣 Images, videos and embeds without dimensions
Always declare width and height, or use the CSS aspect-ratio property, so the browser reserves space before the file loads:
.video-wrapper { aspect-ratio: 16 / 9; }
img { max-width: 100%; height: auto; }
🢣 Ads, banners and injected content
Reserve a fixed slot for ads and embeds using min-height. If an ad doesn’t fill, keep the empty space instead of collapsing it. Never insert content above existing content after load unless it is in response to a user action. Cookie banners should overlay the page or sit in reserved space instead of pushing everything down.
🢣 Web fonts
Swapping a fallback font for a web font can reflow text. Reduce the shift by preloading key fonts, using font-display: swap or optional, and tuning fallback metrics with size-adjust, ascent-override and similar descriptors so the fallback matches the final font’s dimensions.
🢣 Animations
Animate with transform and opacity rather than properties like top, height or margin. Transform-based animations don’t trigger layout and don’t count against CLS.
🢣 Back/forward cache
Make your pages eligible for the browser’s back/forward cache by avoiding unload handlers and certain blocking features. Restored pages skip loading and layout work entirely, which helps all three metrics for returning navigation.
A Realistic Fix-It Workflow
Chasing every warning wastes time. Use this order instead:
Pull field data in Search Console and group failing URLs by template (product page, article, category).
Pick the worst metric on the highest-traffic template. One fix to a shared template improves hundreds of URLs.
Diagnose with attribution data from web-vitals and DevTools.
Fix and test in the lab under throttled conditions.
Ship, then monitor for the next 28 days. Field data lags, so don’t judge too early.
Add performance budgets in CI, using Lighthouse CI or similar, so regressions are caught before release.
Treat this as continuous work. New marketing tags, a redesigned banner or a framework upgrade can undo months of progress overnight.
Common Mistakes to Avoid
Reliance on the single Lighthouse score. One simulated visit doesn’t mean anything compared to the 75th percentile.
Optimization of the homepage alone. Core Web Vitals scores are evaluated for each URL group, and deep templates always perform worse.
Neglecting mobile devices. Check results on mid-range Android devices, because flagship ones mask many issues.
Lazy-loading everything. This strategy will work well below the fold but will be detrimental above it.
Focusing on front-end issues only. Sometimes slow hosting affects LCP performance no matter what optimization techniques you use.
Conclusion
In 2026, Core Web Vitals will reward discipline rather than tricky hacks. The required levels are quite obvious: the key content should be loaded within 2.5 seconds, interactions need to be answered in less than 200 milliseconds and layout shifts must stay below 0.1, everything calculated for 75th percentile. However, the way of obtaining those scores is also quite understandable.
Start small. Focus on the metric which is failing your core pages, implement one solution and check its effectiveness. Faster and consistent site will do more than just satisfy Google algorithms.
