Improve Core Web Vitals in this order: read your field data in PageSpeed Insights and Search Console, fix Largest Contentful Paint (LCP) first, then Cumulative Layout Shift (CLS), then Interaction to Next Paint (INP), and confirm the fix over a 28-day window. In 2026 the pass line is the same one web.dev has published: LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less, all at the 75th percentile of real page loads. The HTTP Archive Web Almanac 2025 found only 48% of mobile sites and 56% of desktop sites had good scores on all three, so most sites still have work to do.
What are the Core Web Vitals thresholds in 2026?
A page passes when all three metrics are good at the 75th percentile. Google’s web.dev documentation sets the targets, and Google Search Central tells site owners to “achieve good Core Web Vitals for success with Search.” Search Console and PageSpeed Insights both use the same bands.
| Metric | What it measures | Good | Needs improvement | Poor | Fix priority |
|---|---|---|---|---|---|
| LCP | Time until the largest visible element renders | 2.5 s or less | Up to 4 s | Over 4 s | First: biggest gap on most sites |
| CLS | Unexpected layout movement | 0.1 or less | 0.1 to 0.25 | Over 0.25 | Second: usually quick fixes |
| INP | Delay between a tap or click and the next frame | 200 ms or less | 200 to 500 ms | Over 500 ms | Third: needs JavaScript work |
The 75th percentile means that three out of four visits must meet the target. A fast median does not save you if a quarter of your visitors, often on mid-range phones, have a slow experience. Search Console also assigns a URL group the worst status among its metrics, so one failing metric fails the group.
For the ranking-effect debate, read our separate piece on whether Core Web Vitals affect ranking. This guide covers only how to fix the numbers.
Where do you start: field data or Lighthouse?
Start with field data. PageSpeed Insights shows real-user results from the Chrome User Experience Report (CrUX) over a rolling 28-day window, plus a Lighthouse lab test. The Search Console Core Web Vitals report uses the same CrUX source and groups similar URLs together, so one template fix can clear hundreds of pages.
Use the two data types for different jobs:
- Field data (CrUX, Search Console) tells you whether you pass. It is the score that counts.
- Lab data (Lighthouse, WebPageTest) tells you why you fail. It runs in a controlled setup, so results vary between runs and can disagree with field data.
Google’s PageSpeed Insights documentation notes that if a URL lacks enough samples, the tool falls back to origin-level data, and if the origin also lacks data, no field data appears. Low-traffic pages may show lab data only. In that case, fix the template using a higher-traffic page that shares it.
Want to know if ChatGPT recommends you? Run the free AI visibility audit.
Lighthouse also does not report INP in its lab metrics. It reports Total Blocking Time as a proxy, per Google’s PSI documentation. To debug real interaction delays, use Chrome DevTools to record a trace while you click and type, or the web-vitals JavaScript library to collect field attribution from your own visitors. WebPageTest, an open source testing tool, adds filmstrips and waterfalls that show exactly when the largest element arrives.
How do you fix a slow LCP?
Fix LCP by getting the largest element, usually a hero image or headline block, requested early and rendered fast. Web.dev’s LCP optimization guide breaks the time into four parts and gives the ideal split: about 40% time to first byte (TTFB), under 10% resource load delay, about 40% resource load duration, and under 10% element render delay. Measure all four before you change anything, because speeding up one part can simply move time into another.
1. Make the LCP resource discoverable early
If the hero image is a CSS background or injected by JavaScript, the browser finds it late. Put it in the initial HTML as an img tag, add fetchpriority="high", and never lazy-load it. The Web Almanac 2025 found fetchpriority="high" on only 17.3% of mobile pages, and about 10.4% of mobile pages lazy-load the LCP image with native loading="lazy", which delays the very element being measured.
2. Shorten the download
Web.dev recommends right-sizing images, using modern formats, compressing, shrinking fonts, serving from a CDN near the visitor, and using effective caching. Our guide on how to optimize images for AI search covers format and sizing choices that help both speed and visibility.
3. Cut render delay
Reduce or inline render-blocking CSS, avoid synchronous scripts in the head, and consider server-side rendering or prerendering if a client-side framework builds the page after load. Break up long JavaScript tasks so the browser can paint.
4. Deliver the HTML faster
Web.dev advises minimizing redirects and making sure the CDN can serve cached HTML from the edge. Cache-busting query parameters often defeat edge caching without anyone noticing. A slow TTFB sets a floor that no image work can beat.
The Web Almanac 2025 shows why LCP comes first: 62% of mobile origins have good LCP, against 81% for CLS and 77% for INP. LCP is the metric most sites fail.
How do you fix layout shift (CLS)?
Fix CLS by reserving space for everything that loads late. Web.dev lists four common causes: images or videos without dimensions, web fonts that swap in at a different size, dynamic third-party content such as ads and widgets, and elements inserted above existing content. Most CLS fixes take a developer an afternoon, which is why they come second.
1. Set dimensions on media
Add width and height attributes, or a CSS aspect-ratio, to every image, video and embed. The browser then reserves the box before the file arrives.
2. Reserve space for ads, embeds and banners
Give ad slots, cookie banners and chat widgets a fixed minimum height. Insert new content below the viewport or in space you already set aside, never above what a visitor is reading.
3. Control font swapping
Preload your main web font, choose a fallback font with similar metrics, and use CSS descriptors such as size-adjust to narrow the size gap between fallback and final fonts.
Two exclusions help you debug. Web.dev notes that shifts within 500 milliseconds of a click, tap or key press are not counted, and animations done with transform do not cause shifts. Use transforms for movement and expand panels only in response to a user action.
The Web Almanac 2025 reports 72% good CLS on desktop and 81% on mobile, so CLS is often the cheapest metric to turn green.
How do you fix a slow INP?
Fix INP by shortening the main thread work that runs between a tap and the next frame. Web.dev splits each interaction into three phases: input delay, processing duration and presentation delay. A long task blocking the main thread causes input delay. Heavy event handlers cause processing delay. Large DOM updates cause presentation delay. Find which phase dominates before you edit code.
1. Break up long tasks
Split long JavaScript work into smaller chunks and yield to the browser between them, so a click is handled within a frame or two instead of waiting behind a large task.
2. Slim the event handlers
Do the minimum needed to update the screen inside the handler. Defer analytics calls, logging and non-visual work until after the next paint.
3. Remove or delay third-party scripts
Tag managers, chat widgets, A/B testing scripts and ad code often hold the main thread. Audit each one, load it after interaction readiness where possible, and drop any you cannot justify.
4. Shrink the DOM and rendering cost
Fewer elements and simpler layout work shorten presentation delay. Avoid forcing layout recalculation inside input handlers.
INP is the metric where the device gap is widest. The Web Almanac 2025 found 97% of desktop origins with good INP but 77% on mobile. Test on a mid-range phone, not your development laptop. Lighthouse’s mobile test simulates a mid-tier phone on a mobile network, which is a sensible lab default.
How do you confirm the fix worked?
Confirm with field data, which moves slowly. Search Console’s Core Web Vitals report reflects the 75th percentile over the last 28 days. When you click “Start Tracking” on a fixed issue, Search Console runs a 28-day validation, and the issue counts as fixed only if it appears on no URLs for the entire window.
| Tool | Data type | Best for | Limitation |
|---|---|---|---|
| PageSpeed Insights | Field (CrUX, 28 days) plus lab (Lighthouse) | Quick check of one URL or origin | Falls back to origin data when URL samples are thin |
| Search Console CWV report | Field (CrUX) | Fixing groups of similar URLs, validation | Only 28-day lagging view |
| Lighthouse (DevTools) | Lab | Debugging LCP and CLS before release | No INP, scores vary between runs |
| WebPageTest | Lab | Waterfalls, filmstrips, different devices and locations | Lab conditions are not your real users |
| Chrome DevTools trace | Lab | Pinning down INP delays | Needs manual interaction testing |
A sound routine looks like this:
- Fix on a staging site and confirm in lab tests.
- Ship to production.
- Watch PageSpeed Insights daily, since it updates daily, for movement in the 28-day window.
- Start Search Console validation.
- Check again after the full 28 days.
Do not expect instant green. Expect the rolling average to improve gradually as old slow visits age out.
How often do sites actually pass?
Fewer than half of mobile sites pass. The Web Almanac 2025 reports good Core Web Vitals on 48% of mobile and 56% of desktop sites. That means a pass is still a differentiator, and a failing score is normal rather than catastrophic. Treat the work as a user experience improvement with measurable thresholds, not a guaranteed ranking lever.
| Metric | Good, desktop | Good, mobile |
|---|---|---|
| LCP | 74% | 62% |
| INP | 97% | 77% |
| CLS | 72% | 81% |
Source: HTTP Archive Web Almanac 2025, Performance chapter, built on CrUX data.
Read the table as a map of where to look first. On mobile, LCP is the weakest metric. On desktop, CLS is slightly weaker than LCP. INP rarely fails on desktop but fails often enough on phones that it deserves a real mobile test.
FAQ
What is a good Core Web Vitals score in 2026?
A good score means LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, each at the 75th percentile of real page loads, segmented by mobile and desktop. All three must pass for the page or URL group to count as good. These thresholds come from web.dev and are used by PageSpeed Insights and Search Console.
Which Core Web Vital should I fix first?
Fix LCP first on most sites, because it fails most often. The Web Almanac 2025 shows 62% of mobile origins with good LCP, compared with 77% for INP and 81% for CLS. Then fix CLS, which usually needs small changes, and then INP, which often requires deeper JavaScript work. If your own field data shows a different worst metric, follow your data.
Why does PageSpeed Insights show different results than Lighthouse?
PageSpeed Insights shows two data sets. The top section is field data from real Chrome users over 28 days, and the lower section is a Lighthouse lab test run once in simulated conditions. Lab scores vary between runs and can disagree with field data because they measure different conditions. Pass or fail is judged on the field data.
How long does it take for Core Web Vitals to improve after a fix?
Expect up to 28 days. CrUX data is a rolling 28-day window, and Search Console validation also monitors for 28 days. PageSpeed Insights updates daily, so you can watch the trend move, but a full pass in the Search Console report needs the whole window with no failing URLs. Fixes ship quickly; the reporting lags.
Does Lighthouse measure INP?
No. Lighthouse’s lab metrics include Total Blocking Time rather than INP, as listed in Google’s PageSpeed Insights documentation. INP is a field metric based on real interactions. To investigate it, use CrUX data in PageSpeed Insights, record interactions in Chrome DevTools, or collect attribution with the web-vitals JavaScript library from your own visitors.
Can I pass Core Web Vitals on a low-traffic site?
Possibly, but you may not see data. PageSpeed Insights falls back to origin-level data when a URL lacks samples, and shows no field data if the origin also lacks it. Search Console does the same for URL groups. On a low-traffic site, rely on lab tests of your template, follow the same fixes, and check field data once traffic accumulates.
The short version
Measure with field data, fix LCP, then CLS, then INP, and wait out the 28-day window. The thresholds are fixed: 2.5 seconds, 200 milliseconds, 0.1, at the 75th percentile. Most sites that fail do so because the hero image loads late, media has no reserved space, or third-party scripts block the main thread. Those are fixable in a sprint. Speed is also one input to how visitors and AI answer engines experience your site, so a clean technical base supports everything else you publish.
Curious how AI assistants describe your site today? Check your visibility with the free audit.
Tagged