Core Web Vitals in 2026: LCP, INP and CLS Explained Simply

Google reduced the entire experience of your website to three numbers. If you learn what they mean — and the thresholds behind them — every performance conversation gets simpler.

The three metrics and their targets

LCP — Largest Contentful Paint. How long until the biggest element (usually your hero image or headline) is visible. Target: 2.5 seconds or less. Over 4.0 s is rated Poor.

INP — Interaction to Next Paint. How quickly the page responds when a user taps, clicks or types. Target: 200 ms or less; over 500 ms is Poor. INP replaced the old FID metric in March 2024 and is much harder to pass, because it measures every interaction, not just the first one.

CLS — Cumulative Layout Shift. How much the layout jumps around while loading. Target: 0.1 or less; over 0.25 is Poor.

One crucial detail: Google evaluates these at the 75th percentile of real users — data collected from actual Chrome visitors (the CrUX dataset), not from your lab test on office Wi-Fi. Your site can look fine in a Lighthouse run on desktop and still fail for real users on mid-range phones.

Lab data vs field data

• Field data (CrUX) is what Google ranks with. It updates as a rolling 28-day window.
• Lab data (Lighthouse/PageSpeed Insights) is a simulation — perfect for diagnosing, wrong for bragging.

Our Site Analyzer shows both side by side: real-user LCP/INP/CLS with pass/fail verdicts, plus the lab metrics that explain why.

Fixing LCP

Most WordPress LCP problems come down to the hero area:

1. Slow server response. LCP can’t be 2.5 s if TTFB is already 1.2 s — see our TTFB guide.
2. The hero image is heavy or late. Serve it as WebP/AVIF, size it correctly, and add fetchpriority="high". Never lazy-load the LCP image.
3. Render-blocking CSS. Dozens of stylesheets delay the first paint. Inline the critical CSS; defer the rest.

A realistic sequence: get TTFB under 400 ms, get the hero image under 100 KB, remove render-blocking assets — and LCP typically lands between 1.5 and 2.2 s.

Fixing INP — the metric that kills builder sites

INP is where page builders and plugin stacks hurt most, because it is dominated by JavaScript on the main thread:

• Reduce total JS. Every plugin script parses and executes on a phone CPU. Cutting unused JavaScript is the single biggest INP win.
• Break up long tasks. Any task over 50 ms blocks input. Heavy sliders, mega-menus and animation libraries are the usual suspects.
• Watch third parties. Chat widgets and tag managers frequently add 100–300 ms of input delay by themselves.

Sites rebuilt with clean, minimal JavaScript rarely worry about INP at all — there’s simply nothing blocking the main thread.

Fixing CLS

CLS is the most mechanical of the three:

• Give every image and video explicit width and height (or aspect-ratio in CSS).
• Reserve space for ads, embeds and dynamically injected banners.
• Preload your web fonts and use font-display: swap so text doesn’t reflow.
• Never insert content above existing content after load (looking at you, cookie bars).

What “passing” actually gets you

Google has confirmed page experience is a ranking signal — a tie-breaker rather than a dominant factor (more on that in does page speed affect rankings?). But the business case is bigger than SEO: passing CWV correlates with measurably lower bounce rates and higher conversions, because the site simply feels instant.

The 2026 reality check

Most WordPress sites still fail on mobile, and the pattern is consistent: they fail INP because of JavaScript bloat, and LCP because of slow servers plus heavy heroes. Both are architecture problems. You can nurse a bloated site to the threshold with caching and tricks — or rebuild the front end clean and pass with room to spare.

Run your site through the free analyzer and check your real-user numbers. If LCP or INP is red, you now know exactly where to look.