Core Web Vitals in 2026: what changed and what matters

2024 was when Google killed FID. Dead and gone. INP is the new king of interaction metrics.

Got a client in 2025 still measuring FID. I said: man, that metric is obsolete. He thought I was crazy.

2026 came around, Google dropped his site in rankings because INP was bad. Then he got it.

What is INP (Interaction to Next Paint)

FID was too simple. It only measured initial response delay. One click, wait for the page to respond.

INP measures every single interaction a user makes. Clicks a button, drags a slider, types in an input. All of it counts. Picks the worst case during the entire user session.

Like this: you’re on a page. Click filter button, page freezes for 300ms. Then click product tabs, freezes for 150ms. Click add to cart, freezes for 50ms. INP picks that worst case of 300ms.

That’s why it’s more honest to what users actually feel. Not just the first interaction. The whole experience.

What’s the 2026 target?

INP: under 200ms. Above 200ms, Google warns that it’s bad. Above 500ms, it’s critical.

LCP: under 2.5 seconds. That didn’t change. Still the most important metric. If your LCP is bad, no one clicks.

CLS: under 0.1. That unitless number is a visual stability score. Lower is better. 0.1 is good, 0.25 is bad.

In practice, most pages I see have CLS fine. The real problem is INP.

Field data vs lab data

This is critical to understand.

Field data is real. Real users, real phones, real networks. Google gets this from CrUX (Chrome User Experience Report). Every page load, every click, every measurement becomes data.

Lab data is your machine. You run a test on your laptop, Lighthouse says everything is fine. But then a real user loads it on 4G and it’s a different story.

Google uses field data to rank. Lighthouse uses lab data to diagnose.

So you have to measure both. Your site might have perfect INP in Lighthouse and terrible INP in CrUX. That means the problem isn’t code, it’s the real user’s network or device.

How to measure properly

Go to Search Console, “Core Web Vitals” tab. Google shows exactly how your site performs based on CrUX data.

If it’s green, congratulations. If it’s red, you need to work.

Then you use Lighthouse to diagnose. Run an audit, see where the problem is. Usually it’s:

For LCP: hero image too large. Solution? Lazy load, responsive images, WebP format.

For INP: heavy JavaScript running on the main thread. Event listeners firing on every render. Solution? Defer scripts, web workers, throttle events.

For CLS: layout shifts from font loading, ads allocating space. Solution? Font display: swap, aspect ratio reserved, skeleton states.

Real example

Built a project with Astro for a dental clinic. First measurement, INP was 450ms. LCP was 3.2s.

Checked the CrUX in Search Console. Saw the problem was real in field data. Not me diagnosing wrong.

Steps I took:

1. Removed unnecessary JavaScript. Had a chat plugin running on the homepage. Moved it to a drawer when opened.

2. Implemented route prefetching with Astro Islands. When users hovered a link, data was already loading.

3. Optimized images. Hero was 400kb. Converted to WebP, responsive, ended up 80kb.

Result: INP dropped to 120ms, LCP to 1.8s. Ranking improved.

Real user monitoring

The most professional approach is implementing the Web Vitals API and sending real data.

import { getCLS, getFID, getFCP, getLCP, getTTFB } from 'web-vitals';

function handleMetric(metric) {
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify(metric),
  });
}

getCLS(handleMetric);
getLCP(handleMetric);
getTTFB(handleMetric);

Collect real data from users and send it to your server. Then analyze trends.

Saw many people using Vercel Analytics. Around USD 6/month and it’s all ready. No need to implement manually.

Performance is business

It’s not just vanity. Faster site: better ranking, more clicks, more conversions.

I now put this in client proposals: “I’ll deliver a site with INP under 150ms and LCP under 2s.” Clients understand that’s a differentiator.

With technical SEO for developers, I talked about this importance. Core Web Vitals is the foundation.

2026 is the year performance became non-negotiable. Google is serious. Slow sites don’t rank.

• Check Core Web Vitals in Search Console
• Run full Lighthouse audit
• Identify where INP is above 200ms
• Remove unnecessary JavaScript
• Optimize hero images to WebP
• Implement Real User Monitoring
• Track CrUX monthly

Good Web Vitals is fuel for growth.

Comparison 2024 vs 2026

In 2024 Google was lukewarm about CLS. By 2026 it’s crystal clear: INP is what matters.

Change happened because modern users are used to apps. Expectation is: I click, something happens in 200ms or less. If a site takes 500ms to respond, users feel it’s slow.

Desktop vs mobile, which suffers more? Mobile. Same site can have good INP on desktop but terrible on 4G. Google prioritizes field data from phones. If your site doesn’t rank on mobile, the problem is likely Core Web Vitals on slow networks.

INP on complex sites

Saw many devs thinking simple sites don’t have INP problems. Wrong. A clinic site with an interactive scheduler? INP can be terrible.

Problem isn’t always heavy code. Could be:

1. Too many event listeners firing on render
2. Long tasks (>50ms work on main thread)
3. Layout recalc from animations
4. Synchronous work on large arrays

Solution? Browser profiler. DevTools > Performance tab. Run with mobile throttling and see the bottleneck.

Example: site with 50 links that had hover effects with animations. Each hover, browser recalculated for 200ms. INP was 220ms. Removed animation, INP dropped to 80ms. Simple.

LCP: hero image

If LCP is above 3s, it’s almost always the hero image.

Before: 2MB JPEG loading at top.

After: same image, converted to WebP (80KB), lazy loading on first view, small inline version while large loads.

LCP: 3.2s → 1.5s.

Tools I use? ImageOptim on desktop, Squoosh online. Converts to WebP, resizes for responsive. Then put directly in Astro with <Image /> component.

Invisible CLS

CLS is invisible when it’s good. Means the page isn’t moving.

Classic problem: font loading and changing size. Solution: font-display: swap and aspect-ratio reserved on container.

Another: ads allocating space. Solution: reserved space before ad loads.

Third: content loading. Skeleton screens work. You put a “fake” of the content while real loads. Zero shift.

Continuous monitoring

One-time audit doesn’t work. You fix it, let 3 months pass, problem comes back because someone added a bad script.

Recommendation: run Search Console Core Web Vitals monthly. If you see a drop, fix the site. With Vercel Analytics you can export data and analyze trends.

Saw a dev automate it: cron job running Lighthouse daily, saving results, always monitoring.

Ranking signal vs ranking reason

Important to differentiate: Core Web Vitals is a ranking signal, not the ranking reason.

Means: Google uses it as a factor. But bad content with perfect Web Vitals won’t rank. Good content with bad Web Vitals ranks less.

Think of it like: Web Vitals is entry to the game. You need to meet the minimum to compete, but that alone won’t win.

Debug tool: PageSpeed Insights

Forget raw Lighthouse. PageSpeed Insights is prettier and shows real field data from your site.

Go to pagespeed.web.dev, paste URL, see everything. Shows what Google actually sees, not what your laptop sees.

Tip: test staging URLs before deploy. If Web Vitals are red, don’t deploy.

2026 roadmap: what’s coming

Google mentioned considering adding input latency metric. Like: how long until response after click. INP already covers this, but could be more specific.

Recommendation: if your site has good INP now, you’ll be prepared.

• Run PageSpeed Insights on 10 main URLs
• Identify which metric is below target
• Use Profiler to find exact bottleneck
• Implement fix (image, script, animation)
• Verify improvement in PageSpeed
• Set up monthly monitoring
• Test on slow network (throttle in DevTools)

Performance in 2026 became non-negotiable. Clients pay for it now.