Skip to content
Blog

Core Web Vitals: Diagnosing Performance in 2026

LCP, INP, and CLS in 2026: the thresholds that matter, how to read field data from CrUX and Search Console, and the diagnostic workflow that finds the real bottleneck.

Published on • August 10, 2026

AI Assistant

You shipped a green Lighthouse score and still got a red warning in Search Console. This is the most common performance story of 2026: the lab says “fast”, but real users on mid-range phones have a different experience. Core Web Vitals are field metrics — Google grades you on what real Chrome users experience at the 75th percentile over a rolling 28-day window, not on what your MacBook can do.

In this post, you will learn the three metrics, their 2026 thresholds, how to read field data vs. lab data, and a diagnostic workflow that pinpoints the actual bottleneck instead of guessing.

The three metrics and their thresholds

Since March 2024, INP has fully replaced FID. As of 2026 the three Core Web Vitals are:

MetricMeasuresGoodNeeds improvementPoor
LCP (Largest Contentful Paint)Loading speed of main content≤ 2.5s2.5–4.0s> 4.0s
INP (Interaction to Next Paint)Responsiveness to interaction≤ 200ms200–500ms> 500ms
CLS (Cumulative Layout Shift)Visual stability≤ 0.10.1–0.25> 0.25

To pass, each metric must hit the “good” threshold for at least 75% of real page views. A page that nails the median user but fails the 75th percentile fails the metric. This is why percentile-level monitoring matters more than averages.

Lab vs. field: know what each tool tells you

The single most common mistake is treating Lighthouse as the source of truth. It isn’t — it’s a debug tool.

  • Lab data (Lighthouse, PageSpeed Insights lab section, WebPageTest): synthetic, runs a single cold page load on a throttled device. Great for reproducing a problem and verifying a fix.
  • Field data (CrUX, Search Console, your own RUM): aggregated from real users. This is what Google actually uses.

The practical rule: use lab tools to debug, use field tools for the truth. If Lighthouse is green but Search Console is red, the field report is describing your real users — trust it first.

Setting up Real User Monitoring

The fastest way to start collecting field data is the web-vitals JavaScript library. It reports the same metrics Google uses, with attribution data that tells you exactly which element caused a poor score.

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

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  navigator.sendBeacon('/analytics-vitals', body);
}

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

Send these to your analytics backend and watch trends over weeks, not hours. A sudden INP spike after a deploy, or gradual LCP creep as images grow, becomes visible before it hits your 28-day CrUX window.

Diagnosing LCP

LCP measures the largest visible element — usually a hero image, video poster, or large text block. The four highest-leverage fixes:

  1. Preload the LCP image so it starts downloading before the parser reaches it.
  2. Inline critical CSS to eliminate render-blocking stylesheet round-trips.
  3. Preload fonts with display: swap (or optional) so text paints with fallback fonts immediately.
  4. Serve the image in a modern format — AVIF/WebP — and make sure the CDN is doing the last-mile delivery.
<link rel="preload" as="image" href="/hero.avif" />

For text-based LCP, the usual culprit is render-blocking CSS or slow font delivery. Chrome DevTools’ Performance panel shows the LCP breakdown: TTFB, resource load delay, resource load time, and element render delay — fix the largest bucket first.

Diagnosing INP

INP is the metric most sites fail in 2026 — roughly 43% of origins miss the 200ms threshold. It measures the longest interaction delay in a session, and failures are almost always caused by long JavaScript tasks blocking the main thread.

The mental model: every interaction has to wait for the main thread to become free. Break up long tasks, defer non-critical work, and yield to the main thread during interactions.

// Instead of one giant synchronous loop:
const items = await fetchAllItems();
items.forEach(renderItem);  // blocks the main thread

// Chunk the work and yield between chunks:
for (let i = 0; i < items.length; i++) {
  renderItem(items[i]);
  if (i % 50 === 0) {
    await new Promise(r => setTimeout(r, 0));  // yield to the main thread
  }
}

Stick to transform and opacity for animation (they run on the compositor, not the main thread). Chrome DevTools’ Performance Insights calls out the long task that contributed most to your worst INP — start there.

Diagnosing CLS

CLS is usually the easiest metric to fix because the causes are well-known:

  1. Always include width and height on images (or use aspect-ratio) so the browser reserves space before the image loads.
  2. Reserve space for ads and embeds with min-height on their containers.
  3. Don’t insert content above existing content. Cookie banners that push the page down on load are textbook CLS killers — use position: fixed overlays instead of flow inserts.
  4. Use font-display: swap or optional so fallback text metrics don’t shift when the webfont arrives.

The DevTools “Layout Shift Regions” overlay (in the Rendering tab) highlights shifts in real time, and the Performance panel marks them with pink bars.

Putting performance gates in CI

Fix the current state, then make sure it stays fixed. Lighthouse CI runs an audit on every pull request and fails the build if scores drop below your thresholds:

// lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "interaction-to-next-paint": ["error", { "maxNumericValue": 200 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
      }
    }
  }
}

This catches performance regressions before they reach production and degrade your CrUX scores.

Putting It All Together

A complete workflow: install web-vitals, wire it to your analytics, and set up a 28-day trend view. Set alerts at 80% of Google’s thresholds (INP > 160ms, LCP > 2.0s, CLS > 0.08) so you catch problems before they break your ranking window. Add Lighthouse CI to your pipeline with the budget above. Now when Search Console flags a URL group, you have both the field data and the tooling to find the culprit.

Conclusion & Next Steps

You now understand that Core Web Vitals are field metrics measured at the 75th percentile, what LCP/INP/CLS thresholds mean in 2026, and how to run a diagnostic workflow that separates debugging from truth. Next steps: add web-vitals to a production page, set up the CI gate, and dig into whichever metric your CrUX data says is worst — for most teams in 2026, that’s INP.

References / Sources

core-web-vitals web-performance inp lcp cls frontend