Core Web Vitals in 2026: What Makers Actually Need to Know

Google's Core Web Vitals are real ranking signals. If your product has a public landing page, blog, or any content that benefits from search traffic, these numbers matter.

The good news: you do not need a performance team to improve them. Most gains come from a small number of high-leverage changes.

The Three Metrics

All three are measured from real user data via the Chrome User Experience Report. Lab data from Lighthouse is useful for debugging, but field data is what Google uses for ranking.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element — usually a hero image or headline — to appear on screen.

What causes poor LCP

• Slow server response (TTFB above 600ms)
• Render-blocking CSS or JavaScript
• Unoptimised images (wrong format, missing width/height, lazy-loaded hero image)
• No CDN for static assets

Quick wins

1. Preload your hero image.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

2. Use fetchpriority="high" on the LCP image element itself.

<img src="/hero.webp" fetchpriority="high" decoding="async" />

3. Serve images in WebP or AVIF. AVIF typically saves 40–50% over JPEG at the same visual quality.

4. Use a CDN. A global CDN can cut TTFB by 300–500ms for users far from your origin.

If your LCP element is text, not an image, the fix is usually CSS — specifically ensuring your web font does not block rendering. Use font-display: swap and preload critical fonts.

INP: Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. It measures the delay between a user interaction — click, tap, keyboard input — and the next visible update to the page.

Common causes of poor INP

• Long-running JavaScript tasks blocking the main thread
• Heavy event handlers that synchronously update the DOM
• Third-party scripts (analytics, chat widgets, A/B testing tools)
• Large React or Vue component trees re-rendering on every interaction

How to diagnose

Open Chrome DevTools → Performance → record while interacting with your page. Look for Long Tasks (tasks over 50ms shown in red). Each long task is a candidate for INP regression.

Fixes

• Break long tasks into smaller chunks using scheduler.yield() or setTimeout(0)
• Defer non-critical third-party scripts using the defer or async attribute
• Virtualise long lists so only visible rows are in the DOM
• Move heavy computation off the main thread using Web Workers

CLS: Cumulative Layout Shift

CLS measures unexpected layout movement. If an image loads and pushes your text down, or an ad slot appears and shifts your content, that is CLS.

The most common causes

The one rule that fixes most CLS

Always specify width and height on every <img> tag. Browsers use these to reserve space before the image loads, preventing the shift entirely.

<!-- Bad: browser does not know the size until the image loads -->
<img src="/photo.jpg" />

<!-- Good: browser reserves the correct space immediately -->
<img src="/photo.jpg" width="800" height="450" />

Tools for Measuring

• PageSpeed Insights — field data + lab data in one place, free
• Chrome DevTools → Lighthouse — local lab testing
• web-vitals JS library — measure real user CWV and send to your analytics
• CrUX Dashboard — historical field data per origin

Priority Order for Most Products

If you are starting from scratch, fix in this order:

1. Optimise your LCP image — WebP format, correct dimensions, fetchpriority="high"
2. Add explicit width/height to all images — eliminates most CLS instantly
3. Audit third-party scripts — each one is a potential INP regression
4. Move to a CDN if TTFB is above 600ms
5. Measure in the field using real user data, not just Lighthouse

Most indie products can move from failing to passing all three Core Web Vitals in a single afternoon of focused work. The changes are small, the tools are free, and the ranking benefit is real.