Core Web Vitals: The Complete 2026 Guide for Global Sites

Core Web Vitals are the three signals Google uses to measure real-world page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They’re not the only ranking factor, but they’re one of the few Google will tell you the exact pass/fail thresholds for — which makes them one of the most actionable parts of technical SEO. Here’s how each one works and what actually moves the needle.

LCP — Largest Contentful Paint (target: under 2.5s)

LCP measures how long it takes for the largest visible element — usually a hero image, a heading, or a background image — to fully render. Three things drive it, and all three need attention; fixing only one rarely gets you to green.

Optimise the LCP element itself. Give the hero image fetchpriority="high" and never lazy-load it — lazy-loading the one image that defines your LCP is one of the most common self-inflicted performance mistakes we see. Serve it in WebP or AVIF format, and keep it under roughly 150KB wherever the design allows.

Fix server response time (TTFB). LCP can never be fast if Time to First Byte is slow, because nothing can render before the HTML document itself arrives. CDN edge caching is the highest-leverage fix here — target under 200ms TTFB at the edge rather than the origin server.

Eliminate render-blocking resources. Defer non-critical JavaScript, inline critical CSS (ideally under 14KB so it fits in the first TCP round trip), and use rel="preload" for the LCP image and any key web fonts so the browser discovers them immediately instead of after parsing the full CSS cascade.

INP — Interaction to Next Paint (target: under 200ms)

INP replaced First Input Delay as a Core Web Vital, and it measures something users actually feel: the delay between an interaction (a click, a tap, a keypress) and the next visual update. Any JavaScript task that runs longer than 50ms blocks the main thread and directly hurts this number.

The fix is almost always about breaking up long tasks rather than eliminating them entirely. Yielding back to the browser with setTimeout(fn, 0) or the newer scheduler.postTask() API lets the browser paint in between chunks of work instead of freezing the page for one long stretch. Beyond that, tree-shaking unused code and code-splitting by route keeps the total JS bundle lean — a good target is under 150KB compressed, since every extra kilobyte is parse-and-execute time competing with user interactions.

CLS — Cumulative Layout Shift (target: under 0.1)

CLS measures visual stability — how much content unexpectedly jumps around as the page loads. It’s usually the cheapest of the three to fix, and the fixes rarely require a redesign.

Every image needs explicit width and height attributes (or a CSS aspect-ratio), so the browser can reserve the correct space before the image has actually downloaded. Dynamic embeds — ads, iframes, widgets — need the same treatment. Animations should move elements with CSS transform only; animating top, left, or height forces the browser to recalculate layout on every frame, which is both a CLS and a performance problem. Fonts are a quieter source of CLS: if a custom web font swaps in after a fallback font has already rendered, text reflows. Sticking to system fonts avoids this category of shift entirely; if you do need a custom font, font-display: optional prevents the swap from happening after initial paint.

Measuring it correctly

Field data (from the Chrome User Experience Report, what Search Console’s Core Web Vitals report actually uses for ranking purposes) and lab data (Lighthouse, PageSpeed Insights) can disagree, sometimes significantly — field data reflects real visitors on real networks and real devices, lab data reflects one simulated run under controlled conditions. Treat lab tools as a debugging aid for finding and reproducing issues, and field data as the source of truth for what Google is actually seeing and scoring.