What replaced First Input Delay (FID) in Core Web Vitals?

Interaction to Next Paint (INP) fully replaced FID as an official Core Web Vital in March 2024. FID only measured the delay before the browser started processing the first interaction; INP measures the full latency of every interaction across the page's lifespan, including the slowest ones, which makes it a much stricter and more representative metric.

Can a page have a good Lighthouse score but still fail Core Web Vitals?

Yes, and it happens constantly. Lighthouse runs a single lab test on a simulated device and network, while Core Web Vitals are field data collected from real users across every device, connection speed, and geography that actually visits your site. A page can score 95+ in Lighthouse on a fast laptop and still fail LCP or INP for the 75th percentile of real mobile visitors on slower hardware.

Does Core Web Vitals directly affect Google search rankings?

Core Web Vitals are one signal among many in Google's page experience ranking factors, not a dominant one. Content relevance still outweighs page speed in most cases. That said, on competitive queries where content quality is roughly equal between pages, Core Web Vitals can be the tiebreaker, and poor vitals correlate strongly with worse conversion and engagement regardless of ranking impact.

Why does my CLS score look fine in Lighthouse but poor in Search Console?

Lighthouse only measures the shifts that happen during its short automated load; Search Console's Core Web Vitals report uses real CrUX field data collected over 28 days, which captures shifts that occur after user interaction, slow third-party scripts, and late-loading ads that a lab test never triggers. Always trust the field data report over the lab score when they disagree.

How often should I re-check Core Web Vitals after shipping a fix?

Give it at least a few days before trusting the field data, since CrUX reports on a rolling 28-day window and needs enough real traffic to stabilize. For faster feedback during development, rely on lab tools like Lighthouse or Chrome DevTools' Performance panel, then confirm the win in Search Console's Core Web Vitals report once enough field data accumulates.

Is INP harder to fix than LCP?

Generally yes, because INP depends on what a specific user does — which button they click, how fast they type — while LCP depends on a fixed, predictable render path. Fixing LCP is usually a handful of static changes: preload the asset, cut server latency, inline critical CSS. Fixing INP means auditing every interactive path for long tasks, which scales with the number of interactive components on the page.

How to Fix Core Web Vitals: LCP, INP & CLS (2026)

Core Web Vitals directly impact search ranking and user experience. After optimizing several production applications, here’s my practical playbook for hitting good scores on all three metrics. Core Web Vitals is Google’s name for three field metrics — LCP, INP, and CLS — that measure loading speed, responsiveness, and visual stability as real users experience a page. For the component layer, pair this with my React performance optimization techniques — and to keep the gains from regressing, a solid frontend testing strategy. See also The $1,100 Framework That Just Made Vercel’s $3 Billion Moat Obsolete.

TL;DR

Treat LCP, INP, and CLS as three different failure modes — the fix for one rarely helps the other two.
LCP: preload the real hero asset, serve responsive images, and cut server response time. Target under 2.5s.
INP: keep the main thread free — break up long tasks, debounce handlers, defer non-urgent state updates. Target under 200ms.
CLS: reserve space before content arrives with explicit dimensions and aspect-ratio. Target under 0.1.
Measure with the web-vitals library on real traffic — lab scores from Lighthouse alone will mislead you.

WEB VITALS IN ONE SCREEN

The fastest way to improve Core Web Vitals is to treat each metric as a different kind of failure mode. They do not respond to the same fixes.

LCP

Fix what delays the largest visible element

Largest Contentful Paint is usually an image, hero block, or large text section arriving too late.

Preload the real hero asset
Reduce server response time
Avoid oversized unresponsive media

INP

Remove long tasks from interaction paths

Interaction to Next Paint is mainly about keeping the main thread free enough to respond when users click or type.

Break synchronous work into chunks
Defer non-urgent updates
Debounce search-heavy interactions

CLS

Reserve space before content arrives

Cumulative Layout Shift punishes surprise movement. The fix is usually explicit dimensions and stable placeholders.

Set media dimensions
Reserve async content slots
Avoid injecting banners above existing content

MEASUREMENT

Use field data before declaring victory

Lab scores are useful for diagnosis, but real-user telemetry is what tells you whether the experience is actually improving.

Collect `web-vitals` data
Track regressions over time
Validate on realistic devices and networks

What Is Core Web Vitals?

Google groups Core Web Vitals into three thresholds — good, needs improvement, and poor — and uses the 75th percentile of real visits to decide which bucket a page lands in. That percentile choice matters: it means one slow device or one bad connection sample doesn’t sink your score, but a genuinely slow experience for a quarter of your traffic will.

Metric	Measures	Good	Needs Work	Poor
LCP (Largest Contentful Paint)	Loading	< 2.5s	2.5-4.0s	> 4.0s
INP (Interaction to Next Paint)	Interactivity	< 200ms	200-500ms	> 500ms
CLS (Cumulative Layout Shift)	Visual stability	< 0.1	0.1-0.25	> 0.25

These are field metrics, meaning Chrome collects them from actual visitors and reports them through the Chrome User Experience Report (CrUX). Lighthouse gives you lab estimates of the same three metrics, which are useful for local debugging, but Google Search ranks pages using field data, not lab scores.

Measuring Before Optimizing

Always measure in the field, not just in lab conditions.

JavaScript

// web-vitals library
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });
  navigator.sendBeacon('/api/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Optimizing LCP

LCP measures when the largest content element becomes visible. It’s usually a hero image, heading, or text block.

What Is a Good LCP Score in 2026?

Anything under 2.5 seconds at the 75th percentile counts as good. In practice, that number is generous — a well-built page on a decent connection should land closer to 1-1.5s. The gap between “passing” and “fast” is where most of the perceived-speed win actually lives, and it’s usually the same handful of fixes: preload the real hero asset, skip a render-blocking CSS/JS chain, and keep the server response under a few hundred milliseconds.

Four sub-parts make up LCP, and each one is a separate lever: time to first byte, resource load delay, resource load time, and render delay. If your server responds fast but LCP is still slow, the bottleneck has moved to render delay — usually JavaScript blocking the main thread before the browser can paint.

1. Preload the LCP Image

HTML

<!-- In <head> — tell the browser about the hero image early -->
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high" />

2. Use Responsive Images

HTML

<img
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 800px"
  alt="Hero image"
  width="800"
  height="400"
  fetchpriority="high"
  decoding="async"
/>

3. Optimize Server Response Time

TypeScript

// SvelteKit example: cache expensive data
export const load: PageServerLoad = async ({ setHeaders }) => {
  setHeaders({
    'Cache-Control': 'public, max-age=3600, s-maxage=86400',
  });

  const data = await fetchExpensiveData();
  return { data };
};

4. Inline Critical CSS

For SvelteKit, CSS is automatically inlined during SSR. For other frameworks, use tools like critters:

JavaScript

// vite.config.ts
import critters from 'critters-webpack-plugin';

// This inlines above-the-fold CSS and defers the rest

Optimizing INP

INP (Interaction to Next Paint) replaced FID in 2024. It measures the responsiveness of all interactions, not just the first one.

How Do You Fix a Poor INP Score?

Start by finding which interactions are slow, not just that INP is slow overall. Chrome DevTools’ Performance panel and the Interactions track in Lighthouse both flag the specific click, tap, or keypress that dragged the metric down — usually one heavy handler, not the whole page. Fixing INP is almost always about reducing the amount of synchronous work a single interaction triggers, not about making the page “faster” in general.

The three biggest INP offenders in real codebases: a click handler that synchronously re-renders a large list, a third-party script (chat widgets, ad tags, analytics SDKs) that hogs the main thread right when a user interacts, and event handlers that do expensive work before the next paint instead of after it. scheduler.yield() and startTransition both exist to solve the same underlying problem — give the browser a chance to paint before you finish the rest of the work.

1. Break Up Long Tasks

JavaScript

// Before: one long synchronous operation
function processLargeDataset(items) {
  items.forEach(item => heavyTransform(item)); // Blocks for 300ms
}

// After: yield to the main thread
async function processLargeDataset(items) {
  const chunks = chunkArray(items, 50);
  for (const chunk of chunks) {
    chunk.forEach(item => heavyTransform(item));
    await scheduler.yield(); // Let the browser handle pending interactions
  }
}

2. Use `startTransition` for Non-Urgent Updates (React)

TSX

import { startTransition } from 'react';

function SearchComponent() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  function handleChange(e) {
    setQuery(e.target.value); // Urgent: update input immediately

    startTransition(() => {
      setResults(filterResults(e.target.value)); // Non-urgent: can be deferred
    });
  }
}

3. Debounce Event Handlers

TypeScript

function debounce<T extends (...args: any[]) => void>(fn: T, ms: number): T {
  let timer: ReturnType<typeof setTimeout>;
  return ((...args: Parameters<T>) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  }) as T;
}

// Usage
input.addEventListener('input', debounce(handleSearch, 200));

Optimizing CLS

CLS measures unexpected layout shifts. It’s the most frustrating metric for users.

Why Does CLS Still Break After You “Fixed” It?

Because most teams only fix the layout shifts they can see. CLS accumulates from every unexpected shift during a page’s lifespan, including ones that happen well after load — a lazy-loaded ad slot that resolves late, a web font swap that changes line length, or a client-side redirect that swaps content after hydration. Fixing the hero image’s dimensions kills the biggest, most visible shift, but a font-swap shift or a late-arriving cookie banner can still push the score into “needs improvement.”

font-display: optional or size-adjust in a @font-face block avoids the font-swap shift entirely at the cost of occasionally keeping the fallback font. If that tradeoff isn’t acceptable, matching the fallback font’s metrics to the real font (via unicode-range and ascent-override/descent-override) removes the shift without changing what text ends up on screen.

1. Always Set Image Dimensions

HTML

<!-- Bad: causes layout shift when image loads -->
<img src="/photo.webp" alt="Photo" />

<!-- Good: browser reserves space -->
<img src="/photo.webp" alt="Photo" width="800" height="600" />

2. Use CSS `aspect-ratio` for Dynamic Content

CSS

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

3. Reserve Space for Async Content

CSS

/* Reserve space for an ad slot or dynamic banner */
.ad-slot {
  min-height: 250px;
  contain: layout;
}

4. Avoid Inserting Content Above Existing Content

This is the most common CLS offender. Cookie banners, notification bars, and lazy-loaded headers all push content down.

CSS

/* Pin dynamic banners to the top of the viewport */
.notification-bar {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  z-index: 50;
}

Real Results

On this portfolio site, after applying these optimizations:

Metric	Before	After
LCP	3.2s	1.4s
INP	180ms	45ms
CLS	0.12	0.01
Lighthouse Score	78	98

The biggest wins came from image optimization (LCP), removing synchronous third-party scripts (INP), and setting explicit dimensions on all media (CLS).

START WITH THE BIGGEST LEVERS

Most Web Vitals work is not a giant rewrite. It is a sequence of targeted fixes that remove very specific bottlenecks.

HIGH-LEVERAGE FIXES

These changes usually move the metrics fastest

Preload and right-size your true LCP asset
Remove or defer blocking third-party scripts
Break up long interaction handlers and heavy transforms
Set explicit dimensions or aspect ratios on all media and embeds

COMMON WASTE

These patterns slow teams down without solving much

Chasing Lighthouse points without field measurement
Optimizing tiny components while the hero image is still oversized
Ignoring CLS until banners and ads start shifting the page
Testing only on fast laptops and office Wi-Fi

Key Takeaways

Measure in the field using the web-vitals library, not just Lighthouse
LCP: preload hero images and optimize server response time
INP: break long tasks, debounce handlers, use startTransition
CLS: always set image dimensions and reserve space for dynamic content
Small, targeted fixes often deliver the biggest improvements
Test on real devices — your development machine isn’t representative

FAQ

Questions readers usually have

Fix what delays the largest visible element

Remove long tasks from interaction paths

Reserve space before content arrives

Use field data before declaring victory

These changes usually move the metrics fastest

These patterns slow teams down without solving much

What replaced First Input Delay (FID) in Core Web Vitals?

Can a page have a good Lighthouse score but still fail Core Web Vitals?

Does Core Web Vitals directly affect Google search rankings?

Why does my CLS score look fine in Lighthouse but poor in Search Console?

How often should I re-check Core Web Vitals after shipping a fix?

Is INP harder to fix than LCP?

Related Articles

React Performance Optimization: 10 Proven Techniques

Fix EEVDF latency regressions with sched_ext: Meta's 28% p99 win

How to Make Your Site Agent-Readable: 4 Layers, One Worker

Get new posts on AI, Claude Code & LLMs

Explore Topics