Core Web Vitals in 2026: LCP, INP, CLS

Core Web Vitals are Google’s way of saying “this is how we measure whether your site feels nice to use.” Three metrics, three thresholds. Pass them and you’re not just chasing a Lighthouse number, you’re meeting a published bar that affects rankings and, more importantly, real users.

INP replaced FID as a Core Web Vital back in March 2024. Two years on, most teams we work with still have stale advice in their performance docs from before that change. So let’s start from where things actually are.

The three metrics

Metric	What it measures	Good	Needs improvement	Poor
LCP	Largest paint (main content)	≤ 2.5s	≤ 4.0s	> 4.0s
INP	Interaction responsiveness	≤ 200ms	≤ 500ms	> 500ms
CLS	Visual stability	≤ 0.1	≤ 0.25	> 0.25

Pass all three at the 75th percentile of real user data and Google considers your URL “good.” Field data, not lab. This distinction trips people up: you can score 100 in Lighthouse and still fail CWV in Search Console.

LCP: when the main content actually shows up

Largest Contentful Paint is when the largest visible element finishes rendering. Usually a hero image, sometimes a big headline, occasionally a video poster.

In our experience, slow LCP usually comes from one of four things:

1. Slow server (high TTFB)
2. Render-blocking resources (CSS, fonts, sync scripts)
3. The LCP element being lazy-loaded by mistake
4. The image itself is enormous, served unoptimized

The first one is on the server. The other three are usually one-line fixes.

A common trap: developers add loading="lazy" to every image as a “best practice.” If your hero image is lazy-loaded, your LCP is going to suffer because the browser waits to even discover it. Eager-load the LCP candidate with fetchpriority="high", lazy-load the rest.

To find what your LCP element actually is, open Chrome DevTools → Performance → record a load → look for the “LCP” marker. Or use the Web Vitals extension, which highlights it directly on the page.

INP: the metric that made FID look easy

Interaction to Next Paint replaced First Input Delay. FID only measured the first input. INP measures every interaction across the entire page lifecycle, then reports the worst.

This caught a lot of sites off guard. A “fast” homepage could still have an 800ms INP if clicking the menu toggle did too much work on the main thread. We’ve seen marketing sites with great lab scores fail INP in production because every nav click triggered a giant re-render somewhere.

The usual causes of bad INP:

• Long tasks blocking the main thread (anything over 50ms)
• Event handlers doing too much synchronous work
• Heavy third-party scripts (analytics, chat widgets, tag managers)
• React or Vue re-rendering too aggressively on click, scroll, or input

Things that actually help:

• Break long tasks. Use scheduler.yield() or setTimeout(0) to let the browser breathe.
• Move heavy work off the main thread (Web Workers, or just defer it past the next paint).
• Audit your third-party scripts. The marketing team’s “tiny pixel” is rarely tiny.
• For React, look for unnecessary re-renders. useMemo, useCallback, and React 18’s transitions exist for a reason.

INP is the hardest of the three to fix because the cause is often invisible to lab tools. You need real user monitoring (RUM) to see it.

CLS: stop the page from jumping

Cumulative Layout Shift measures how much things move around after they first render. A score of 0.1 means roughly 10% of the viewport shifted. That’s the ceiling for “good.”

The fixes are well-known by now, but still get missed:

• Always set width and height on <img> and <video>. The browser uses them to reserve space.
• For responsive images, use the attributes and let CSS scale them with height: auto.
• Reserve space for ads, embeds, and dynamic content with a fixed-size container.
• Avoid inserting content above existing content (cookie banners that push the page down are a classic offender).
• Preload custom fonts and pick a font-display value deliberately. FOUT shifts text; FOIT delays it.

CLS is the easiest of the three to fix once you find it. The annoying part is finding all the shift sources. Chrome DevTools highlights them in the Performance panel, so start there.

Lab vs field data

This is the part most teams miss. Your Lighthouse score is lab data: one run, ideal conditions, throttled CPU. Search Console shows field data: actual users, real devices, real networks. They almost never agree.

The Chrome User Experience Report (CrUX) is the field data Google uses. You can check it yourself at pagespeed.web.dev. If your CrUX shows fail and your Lighthouse shows pass, trust CrUX. That’s the data Google ranks on.

For ongoing monitoring, you’ll want RUM. Free options: Google Search Console for CWV rollups, Cloudflare Web Analytics, Vercel Speed Insights. Paid: SpeedCurve, Calibre, DebugBear. Pick one. Synthetic alone isn’t enough once you care about the 75th percentile.

A pragmatic priority order

If you’re starting from scratch and want to pass all three CWV, do it in this order:

1. Fix TTFB if it’s over 500ms (server, caching, CDN)
2. Identify your LCP element and make sure it’s not lazy-loaded
3. Audit third-party scripts and remove what you can
4. Reserve space for media and dynamic content (CLS)
5. Break up long tasks and audit click/input handlers (INP)
6. Add RUM and watch the 75th percentile, not the average

The average lies. The 75th percentile is what Google measures, and it’s what your slower users actually experience.

Tools we reach for

• pagespeed.web.dev — official, free, shows lab and field side by side
• Chrome DevTools Performance panel — for finding LCP and CLS sources
• The Web Vitals extension — for a quick check on any page you’re browsing
• Our Core Web Vitals Checker — for a CWV snapshot of any URL
• Our Performance Checker — for the server-side factors (HTTP/2, compression, caching, TTFB)

For deeper rendering issues we usually drop into the DevTools timeline. There’s no replacement for actually watching the trace.

When to stop optimizing

Hitting “good” on all three CWV is usually enough. Chasing 100s in Lighthouse beyond that is mostly engineering time that would be better spent on features users actually notice.

A site that loads in 1.8s feels the same as one that loads in 1.4s. The user can’t tell. Your money is better spent elsewhere once you’re under the thresholds.

If you’d like a second pair of eyes on your performance numbers, get in touch.