Core Web Vitals in 2026: What Still Matters and What Does Not

Core Web Vitals generate more panic than they deserve and less action than they need. They are a real signal, but a small one, and most of the effort spent on them goes into chasing lab scores rather than fixing the two or three things real users actually feel.

Here is where the metrics stand, how much weight to give them, and the fixes that return the most per hour of development time.

The framing I use with clients: Core Web Vitals are a tie breaker, not a lever. They rarely lift a page that has nothing to say, and they rarely sink a page that is clearly the best answer. What they do reliably is decide close calls, and they compound with conversion, because the same delay that fails a threshold also loses enquiries.

The Three Metrics and Their Thresholds

All three are assessed on field data at the 75th percentile, so the slowest quarter of your real visits decides the verdict. A fast developer machine on a fast connection tells you almost nothing about that.

What each metric is really measuring

LCP is the render time of the largest element in the viewport, usually a hero image, a background image, or a large block of text. It is a composite: time to first byte, plus resource load delay, plus resource load time, plus render delay. That breakdown matters, because each part has a different fix and PageSpeed Insights will tell you which part dominates.

INP replaced First Input Delay and is much harder to pass, because it measures the full latency of nearly every interaction on the page, from the tap to the next paint, and reports close to the worst one. FID only measured the delay before processing started, which flattered pages that did heavy work after the click.

CLS is a unitless score, not a duration. It accumulates the shift distance times the impacted area for every unexpected movement across the page lifetime, so a late loading banner or a font swap that changes line height can fail the metric on an otherwise fast page.

One more detail worth knowing: field data in Search Console and the Chrome UX Report uses a rolling 28 day window. When you ship a fix, the reported metric improves gradually rather than immediately, and the improvement only appears once enough real visits have accumulated. Judge the fix by lab measurement on the day, and confirm it in field data weeks later.

What Still Matters

• Field data over lab data. Start every investigation in the Core Web Vitals report in Search Console, grouped by template. Fixing one template usually fixes hundreds of URLs.
• The LCP element. Identify the actual largest element, then preload it, serve it as a modern format at the right dimensions, and never lazy-load it. This is consistently the single highest-return fix.
• Third-party script budget. INP failures are usually caused by tags nobody owns any more. Audit them, remove the dead ones, defer the rest, and load chat widgets on interaction.
• Reserved space. Width and height on every image, fixed containers for embeds and ads, and no banners injected above content already on screen.
• Font loading. Self-host, subset, and use font-display swap. Web fonts routinely delay LCP by hundreds of milliseconds.
• Server rendering. Delivering real HTML rather than an empty shell helps LCP and is a prerequisite for reliable indexing and AI retrieval.

The LCP fixes, ranked by return per hour

• Compress and resize the hero. A 900KB PNG served at 3x the displayed size is the most common single cause. Modern format, correct dimensions, responsive srcset.
• Stop lazy loading it. Anything in the initial viewport should load eagerly, with fetchpriority high on the LCP image.
• Preload the resource that the browser cannot discover early, typically an image referenced from CSS or injected by script.
• Fix render blocking. Inline the critical CSS, defer the rest, and move non essential scripts out of the head.
• Self host and subset fonts, with font-display swap and preload for the one face used above the fold.
• Cut server latency with caching, a CDN, and edge rendering. This is real work, and worth doing once the cheap wins are gone.

The INP fixes, in the order I try them

INP failures are almost always someone else's JavaScript. The pattern repeats: a tag manager with years of accumulated containers, two analytics tools doing the same job, a chat widget loading on every page including the ones nobody chats from, and a consent banner that blocks the main thread while it decides what to block.

• Inventory every third party script and delete the ones no one can name an owner for.
• Load chat, review, and video embeds on interaction or when scrolled into view, never on load.
• Break up long tasks. Anything over 50ms on the main thread is a candidate for splitting or deferring.
• Reduce hydration cost on interactive templates by shipping less client JavaScript, not by adding more caching.
• Give immediate visual feedback on interactions so the next paint is not waiting on a network round trip.

The CLS fixes that hold up

• Width and height attributes, or an aspect ratio, on every image and iframe.
• Fixed height containers for ads, embeds, and anything loaded asynchronously.
• No content injected above existing content after paint, including cookie bars and promo strips.
• Matched fallback and web font metrics so the swap does not reflow the text.
• Transform based animation instead of animating layout properties.

What Does Not Matter Much

• Chasing a 100 Lighthouse score. Beyond passing thresholds in field data, the remaining points are vanity.
• First Input Delay. Retired. If a tool or report still shows it, that report is out of date.
• Time to First Byte in isolation. Worth watching as a contributor to LCP, not as a target on its own.
• Micro-optimising kilobytes while a 900KB hero image and four analytics tags sit untouched.
• Expecting rankings to jump. Performance work protects position; it does not create relevance. Content and structure do that.

Reading field and lab data together

The two data sets answer different questions and disagreeing is normal. Lab data is a single simulated load on a throttled device, which makes it reproducible and useful for isolating a cause. Field data is thousands of real loads on real devices and networks, which makes it noisy and authoritative. Use lab data to diagnose and to verify a fix on the day, and field data to decide whether anything needs fixing at all.

When field data is worse than lab data, look at what your lab test is not simulating: logged in states, slow regional networks, older Android devices, ad and consent scripts that only fire in production. When field data is better, you are probably throttling harder than your audience experiences, and the lab score is safe to ignore.

Mistakes That Waste the Budget

• Optimising the homepage only. It is usually the best performing template and rarely the one that earns organic entries.
• Installing a performance plugin and declaring victory. Aggressive minification and deferral often break rendering, which costs far more than the milliseconds saved.
• Re-measuring the day after a fix and concluding it failed, when field data has not refreshed yet.
• Treating the score as the target. The thresholds are the target, and only in field data.
• Lazy loading everything by default, including the LCP image, which makes the headline metric worse.
• Adding preload hints everywhere. Preloading many resources removes the priority signal entirely.

A Practical Order of Work

• Pull field data by template and pick the worst-performing template that receives real traffic.
• Fix its LCP element: correct format, correct size, preloaded, not lazy-loaded.
• Cut or defer third-party scripts on that template and re-measure INP.
• Add dimensions and reserve space until CLS is stable.
• Wait for field data to refresh. It uses a rolling window, so nothing changes overnight.
• Move to the next template and repeat.

Performance is the last section of my technical SEO checklist for a reason: it is worth doing well, and worth doing after crawling, indexing, and rendering are already sound.

How this affects AI search visibility

Speed is not a citation signal, but the things that make a page fast overlap heavily with the things that make it retrievable. Server rendered HTML, content that does not depend on script execution, and a lightweight page that a fetcher can read in one request all help. A heavy client rendered page fails twice: slowly for users, and almost entirely for the systems that assemble generated answers.

Frequently Asked Questions