Core Web Vitals 2026: a practical guide to passing them

Core Web Vitals are the three metrics Google uses to summarise a site's user experience: load speed, responsiveness and visual stability. Since they became part of the ranking signals, passing these metrics stopped being a technical detail and became a question of visibility. This is our practical guide for 2026, the same one we apply on every project.

Why they matter more than they seem

It's worth putting Core Web Vitals in their place. They're not the most important ranking factor —relevant content and domain authority rule—, but they are a mandatory baseline for competing at the top. They're estimated to carry around 10-15% of the overall algorithm, and their real role is as a tiebreaker: when two results have similar relevance, Google rewards the one offering a better experience.

The biggest effect, however, happens after the click. A site that appears fast, responds instantly and doesn't dance while loading retains its visitors; a slow, jerky or unstable one pushes them towards the competition. That's why Core Web Vitals are both an SEO lever and a conversion lever: they improve both how Google finds you and what the user does once inside.

An important nuance for 2026: fixes are not immediate. Google evaluates field data over a rolling 28-day window, so a fix deployed today takes roughly a month to fully show up in Search Console. This makes preventing regressions before publishing worth more than firefighting afterwards.

The three metrics, explained

Google classifies each metric into three levels —"good", "needs improvement" and "poor"— and to pass you have to land in "good" at the 75th percentile of real users. In other words: it's not enough for it to be fast for you; it has to be fast for 75% of your visitors, including those arriving on a modest phone and a so-so connection.

Metric	What it measures	Good	Needs improvement	Poor	Sites passing
LCP	Perceived load speed	≤ 2.5 s	2.5 – 4 s	> 4 s	~68%
INP	Responsiveness	≤ 200 ms	200 – 500 ms	> 500 ms	~57%
CLS	Visual stability	≤ 0.1	0.1 – 0.25	> 0.25	~78%

That last column tells a story: CLS is the easiest to pass because it's fixed with predictable CSS, while INP is the great challenge of the decade —more than 40% of the web fails it— because it depends on the amount of JavaScript each page loads.

LCP — Largest Contentful Paint

It measures how long the largest element visible without scrolling takes to paint, which in most cases (about 72% of the time) is an image, and the rest a prominent headline or a background. It's the "when do I see something useful" metric.

INP — Interaction to Next Paint

It replaced FID as the interactivity metric in March 2024, and the change was for the better: FID only measured the first interaction and went blind after that. INP, instead, watches every click, tap and keypress throughout the whole visit, and keeps the slowest response. A high INP feels like a site that "gets stuck" when filtering products, opening menus or submitting forms.

CLS — Cumulative Layout Shift

It measures layout jumps during loading: that banner that suddenly appears and makes you click where you didn't mean to. It's calculated by accumulating how much visible content shifts while the page finishes assembling.

The optimisations with the most impact

To improve LCP

LCP rarely fails for a single reason: it's a chain of small delays that add up. You tackle it in layers, from the network to the browser:

Reduce TTFB (time to first byte). It's the foundation: if your server takes 800 ms to respond, LCP is already born with almost a second of delay before downloading anything. The solution is to serve from a distributed CDN, with server-side rendering (SSR) or, better still, static generation (SSG).
Optimise the hero image. WebP or AVIF format (they weigh between 30% and 50% less than a JPEG), dimensions tailored to each screen with srcset and the <picture> element, and priority preloading in the <head>:
```
<link rel="preload" as="image" href="/images/hero.webp"
      type="image/webp" fetchpriority="high" />
```
That preload alone usually saves between 200 and 800 ms.
Never apply loading="lazy" to the LCP image. Deferring the load of the most important element on screen is a classic mistake: you're asking the browser to delay exactly what the user expects to see first.
If the LCP is text, mind your fonts. Preload the critical font, host it on your own domain (avoid Google Fonts latency) and use font-display: swap so the text appears instantly with a system typeface while the final one loads.

To improve INP

INP breaks down into three phases, and each is optimised differently:

Input delay: the time the main thread is busy and can't attend to your click. It's caused by long tasks —a third-party chat initialising, analytics scripts, the hydration of heavy frameworks.
Processing time: how long it takes to run the code that responds to the interaction.
Presentation delay: how long the browser takes to paint the result on screen.

All three are reduced with the same underlying recipe: less JavaScript and chunked work.

Load less JavaScript. Every kilobyte is downloaded, parsed and executed. Audit your libraries and remove what you don't use.
Chunk long tasks. Any operation that blocks the main thread for more than 50 ms is felt on every keypress. In 2026 the key tool for this is the scheduler.yield() API, which pauses a heavy computation to attend to the user and then resumes where it left off:
```
async function processInChunks() {
  runBlock();                // first part of the heavy work
  await scheduler.yield();   // yields the thread: handles pending clicks
  runBlock();                // resumes the rest with priority
}
```
Watch third-party scripts. Chats, maps and tracking pixels are the usual suspects. Load them deferred or on demand.

To improve CLS

Reserve space for images and videos with width and height (or the CSS aspect-ratio property). Without dimensions, the browser assumes zero and then pushes everything down when it loads.
Reserve room for ads, embeds and cookie banners with min-height and contain: layout, or take them out of the flow with fixed positioning. They're the most underrated cause of jumps.
Avoid "font shift". Using font-display: swap protects LCP, but switching from the system font to the final one can cause text to reflow. It's fixed by tuning the size-adjust, ascent-override and descent-override descriptors in the @font-face so the fallback font takes up almost the same space as the final one.

Field data vs. lab data

This distinction causes the most confusion, and understanding it saves you from optimising what doesn't score:

Lab data (Lighthouse, the "diagnostics" tab in PageSpeed): generated in a simulated environment, with a fixed network and device. They don't affect rankings. They're useful for fast debugging and for putting up gates on each build that prevent shipping a regression.
Field data (CrUX, the Chrome User Experience Report): real visits from the last 28 days, with their actual phones and connections. These are the ones Google uses to rank.

Hence a common trap: a page can pass in PageSpeed but fail in Search Console. PageSpeed looks at a specific URL, while Search Console groups pages with the same template; if the rest of your shop's product pages are slow, that average drags down the page you were looking at. That's why the serious approach is to measure real users (what's called RUM, Real User Monitoring) with the official web-vitals library, which also tells you exactly which element broke the metric in each session.

What's new in 2026

The ground moves fast. Three advances we already use or watch closely:

Speculation Rules API. It lets you pre-render in the background the page the user will probably visit next. When they click, the transition is practically instant: in real data, it brings the LCP of prepared links well below the threshold. It replaces the old prefetch and prerender.
Long Animation Frames (LoAF). Available since Chrome 123, this API flags frames that take longer than 50 ms and, unlike the old long tasks API, tells you why: which specific script blocked the thread. It's the tool that was missing to diagnose INP in production.
Revamped Chrome DevTools. The performance panel now shows the metrics live as you browse, and an insights panel translates the technical diagrams into readable recommendations ("a third-party script is delaying LCP").

The case of WordPress and other CMSs

A good chunk of the web runs on WordPress, and failures there are frequent: plugins that load JavaScript on every page, bloated templates and heavy database queries. The good news is there's almost always plenty of room without rebuilding the site:

Page and object caching with a tool like WP Rocket, which minifies, defers scripts and resolves much of the common pathology without touching code.
Batch image optimisation with a plugin like Imagify, which rescales and converts to WebP/AVIF automatically.
Self-hosting fonts to remove Google Fonts latency and CLS jumps.
A CDN like Cloudflare in front of everything, distributing static files close to the user and crushing TTFB.
Database cleanup (orphaned tables and transient records) to speed up queries.

If after all this the site still fails, it's a sign the problem is structural and it's time to consider a different architecture. We expand on this in our comparison Next.js vs WordPress.

How we measure it at yuGraphik

We work with three levels of measurement: PageSpeed Insights for the initial diagnosis, Lighthouse on each build to catch regressions before publishing, and the Search Console Core Web Vitals report to watch real user data month by month. On demanding projects we add our own RUM monitoring to know, metric by metric, which specific element to touch.

Our default architecture —static sites generated with Next.js and served from a CDN with aggressive caching— passes all three metrics out of the box in the vast majority of cases: there's no server that's slow to respond, no database that saturates, no JavaScript that isn't needed. You can see the approach in action in our projects, and if you'd like us to audit yours, it's part of our web development service.

Conclusion

Core Web Vitals aren't a Google fad: they're the translation into numbers of something your visitors feel on every visit. Diagnose your site (it's free and takes a minute), prioritise the optimisations in this guide —starting with images and JavaScript, which is where most failures are— and remember that improvements take a few weeks to consolidate in the field data. If your current platform can't go any further, consider an architecture designed for performance from the very first line of code.

Frequently asked questions

Do Core Web Vitals really affect rankings?

Yes, they're a confirmed ranking signal from Google, although content still carries more weight: Core Web Vitals are estimated to influence around 10-15% of the overall factors. In practice they work as a tiebreaker: between two results of similar relevance, the one offering a better experience wins. And their indirect effect is greater: a slow site loses visitors before the ranking even matters.

How do I measure my site's Core Web Vitals for free?

PageSpeed Insights (pagespeed.web.dev) is the starting point: paste your URL and you get lab data and, if your site has enough traffic, real Chrome user data. Search Console also includes a Core Web Vitals report that groups pages using the same template, and Chrome DevTools shows the metrics live as you browse.

What score do I need to 'pass'?

Google considers a good experience: LCP below 2.5 seconds, INP below 200 milliseconds and CLS below 0.1. What counts is the 75th percentile of real users over a rolling 28-day window, not the lab score from a single test.

Which of the three metrics is the hardest to pass?

INP, by far. Globally around 43% of sites fail the 200 ms threshold, versus 32% for LCP and only 22% for CLS. The reason is too much JavaScript: heavy frameworks saturate the browser's main thread and delay the response to every click.

I've fixed the errors. Why does Search Console still report a failure?

Because Google evaluates field data over a rolling 28-day window. Even if you deploy the fix today, the report takes about four weeks to fully reflect the improvement, since it's still carrying the earlier slow sessions. Be patient: if the fix is real, the metric recovers.

My site is on WordPress and it fails. Do I have to rebuild it?

Not necessarily. Before rebuilding, there's huge room to optimise: a good caching plugin (like WP Rocket), converting images to WebP or AVIF, removing plugins that load JavaScript on every page, a CDN like Cloudflare and decent hosting. If it still fails after that, we consider migrating to a static architecture.