Core Web Vitals 2026: Fix LCP, INP & CLS

Core Web Vitals are Google's three metrics for how a page feels to use: how fast the main content appears, how quickly the page reacts when you tap or click, and whether the layout jumps around while you read. They have been part of Google's page-experience signals since 2021, and they still matter in 2026. The short version: get LCP under 2.5s, INP under 200ms and CLS under 0.1 for the 75th percentile of your real visitors, and this part of your SEO is handled. This guide explains each metric in plain language, how to measure it correctly, and the fixes that actually move the needle.

The three metrics, plainly explained

• LCP — Largest Contentful Paint (good: ≤ 2.5s). When the biggest visible element — usually the hero image or headline block — finishes rendering. If LCP is slow, the page feels slow, whatever the stopwatch says about total load time. Typical culprits: unoptimised hero images, slow servers, render-blocking CSS.
• INP — Interaction to Next Paint (good: ≤ 200ms). How quickly the page visually responds when a visitor clicks, taps or types — measured across the whole visit, worst interactions counted. Typical culprits: heavy JavaScript bundles, long main-thread tasks, third-party scripts firing on every interaction.
• CLS — Cumulative Layout Shift (good: ≤ 0.1). How much the layout jumps while loading — the classic "I went to tap a link and an ad pushed it down" frustration. Typical culprits: images without dimensions, web fonts swapping late, ads or embeds injected without reserved space.

Measure field data, diagnose with lab data

This distinction trips up most people. Field data is what real users experienced, collected by Chrome and published via CrUX — it is what Google evaluates, aggregated at the 75th percentile over 28 days. Lab data is a simulated test (Lighthouse, PageSpeed Insights) on a fixed device and connection — reproducible, but not what counts. Use lab data to diagnose and verify fixes; use field data (Search Console's Core Web Vitals report, or the CrUX API) to know your real standing. Our PageSpeed score guide goes deeper on reading both correctly.

Fix LCP: make the hero appear fast

• Optimise the LCP image specifically. Serve it in a modern format (AVIF or WebP), sized for the display width with responsive srcset, and compressed aggressively — hero images are routinely 70–80% smaller after proper optimisation.
• Preload it. Add <link rel="preload" as="image"> and fetchpriority="high" to the LCP image so the browser discovers it immediately instead of waiting for CSS and JavaScript.
• Fix the server first if TTFB is slow. If time-to-first-byte is over ~800ms, no front-end trick will save LCP — look at hosting, caching, database queries and CDN.
• Inline critical CSS for above-the-fold content and defer the rest, so rendering is not blocked waiting for a stylesheet.
• Lazy-load everything below the fold — but never the LCP image itself. Lazy-loading the hero is one of the most common self-inflicted LCP wounds.

Fix INP: keep the main thread free to respond

• Break up long JavaScript tasks. Any task over ~50ms blocks interaction. Split heavy work with setTimeout yields or move it to a Web Worker.
• Defer third-party scripts. Chat widgets, analytics, ad tags and social embeds are the usual INP killers — load them after interaction or on idle, and question whether each one earns its place.
• Ship less JavaScript. Code-split by route, tree-shake unused code, and audit what each framework actually costs on a mid-range phone rather than your development laptop.
• Debounce input handlers. Search-as-you-type and scroll handlers should not run expensive work on every keystroke — debounce or throttle them.
• Avoid layout thrash. Alternating reads and writes to layout properties in a loop forces the browser to recalculate styles repeatedly; batch reads, then batch writes.

Fix CLS: stop the layout from jumping

• Always size your media. Set width and height attributes (or CSS aspect-ratio) on every image and video so the browser reserves space before the file arrives.
• Tame font swapping. Use font-display: swap with a closely-matched fallback font (tune with size-adjust) so text renders immediately without reflowing when the webfont arrives. Preload the primary font file.
• Reserve space for ads and embeds. Every ad slot, iframe and injected widget needs a fixed-size container — an ad that pushes content down is a CLS failure and a UX failure.
• Never insert content above existing content late. Banners, cookie notices and "related posts" boxes that pop in after load and shove the article down are classic CLS sources; reserve their space or animate them over the layout instead.

Mistakes that keep sites in the red

A few patterns show up in almost every failing audit we see:

• Optimising the lab instead of the field. Teams celebrate a 95 Lighthouse score while field CLS fails because real users trigger cookie banners, chat widgets and personalisation the lab never sees. Always confirm in field data.
• One giant JavaScript bundle. Framework starter templates that ship 400KB of JavaScript for a marketing page are the single most common INP failure. Audit with coverage tooling in DevTools and delete what never executes.
• Images sized by CSS, not by file. A 2400px-wide hero displayed at 400px still downloads the full file. Responsive srcset is not optional in 2026.
• Fixing metrics one page at a time. CWV issues live in templates — the theme, the header, the ad stack. Fix the template and hundreds of pages move together; fix pages individually and you will be auditing forever.
• Ignoring the 28-day window. Shipping fixes on Monday and declaring failure on Friday misunderstands field data. Lab-verify immediately, then give CrUX a full month before judging.

The order to fix them in

Start with measurement: run PageSpeed Insights on your three highest-traffic templates and note which metric fails worst in field data. Fix in this order: server/TTFB first (it helps LCP and everything else), then LCP (usually image + preload work, often a day's effort), then CLS (usually a few attribute and CSS fixes), then INP (the deepest work — JavaScript architecture). Re-test in the lab after each round, then wait two to four weeks for the 28-day field window to reflect the change.

Realistic targets

"Good" on all three metrics at the 75th percentile is the goal, and it is achievable for content sites, blogs and most business sites. Heavy web apps and ad-funded publishers sometimes land in "needs improvement" on INP — that is acceptable if the trend is improving and the business trade-offs are deliberate. Do not chase a perfect 100 lab score at the expense of features users actually want; the field thresholds are the finish line, and diminishing returns set in hard past them. Compare your numbers with the 2026 SEO benchmarks to see what is normal for your niche.

Find your failing pages in a minute: run the free website SEO audit to check Core Web Vitals, crawlability, indexation and on-page issues for any URL — then use the fixes above on the pages it flags. For the broader picture, our SEO audit checklist puts vitals in context with everything else worth checking.

Frequently asked questions

Are Core Web Vitals still a ranking factor in 2026?

Yes. Page experience — including Core Web Vitals — remains part of how Google evaluates pages. It is one signal among many: great vitals will not save thin content, but poor vitals can hold back an otherwise strong page.

What is the difference between LCP and page load time?

Page load time measures when everything on the page finishes; LCP measures when the largest visible element renders. A page can "finish loading" slowly while feeling fast, or vice versa — LCP tracks what the user actually perceives.

How long until my fixes show up in Search Console?

The Search Console Core Web Vitals report uses a 28-day rolling window of field data, so improvements typically take two to four weeks to appear. Verify immediately with lab tests, then wait for the field data to catch up.

Did INP replace FID?

Yes. Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the first interaction's delay; INP measures responsiveness across the whole visit, which is harder to game and more meaningful.

Can a WordPress site pass Core Web Vitals?

Absolutely — most CWV failures come from theme and plugin choices, not the CMS itself. A lean theme, image optimisation, caching and careful plugin selection get most WordPress sites into the green. Page builders with heavy JavaScript are the usual culprit when they fail.