BLOG
Web Performance
Core Web Vitals have been part of Google's ranking signals since 2021. Five years later, most startups still haven't passed them—not because the standards are unreasonable, but because the problems are subtle and the fixes take more than running Lighthouse once and moving on.
This is a practical guide to what the metrics actually measure in 2026, where most sites fail, and what the fixes look like for developers building on modern frameworks. Not a checklist — a working explanation of why each problem exists and what to do about it.
Three metrics matter: LCP, INP, and CLS. INP replaced FID in March 2024 — understanding why that change happened is the first step to knowing where to focus your optimization effort.
LCP (Largest Contentful Paint) measures when the largest visible element finishes loading — typically a hero image, a heading, or a large text block where its threshold is under 2.5 seconds. Sites that fail almost always have the same problems — unoptimized images, render-blocking resources, or slow server response times.
INP (Interaction to Next Paint) replaced FID because FID only measured the delay before the browser responded to the first interaction. INP measures responsiveness throughout the page's lifecycle. Threshold: under 200ms. A page that responds quickly to the first click but lags on subsequent interactions passes FID and fails INP — which is why the change caught many sites by surprise.
CLS (Cumulative Layout Shift) measures visual stability — how much the page shifts unexpectedly as content loads. Threshold: under 0.1. To improve CLS, you need to identify exactly what's causing the shift, which a standard Lighthouse audit doesn't always show.
According to the 2025 HTTP Archive Web Almanac, 45% of mobile origins still fail at least one Core Web Vital threshold. LCP is the most common failure on mobile. CLS is the one most teams think they've fixed but haven't.
Hero images loaded without priority. In React and Next.js, images are lazy-loaded by default. The hero image — often the LCP element — should not be. In Next.js, add the priority prop to the Image component. In plain React, add fetchpriority="high" to the img tag. This single change moves LCP significantly on most sites that haven't done it.
Render-blocking resources. Third-party scripts — analytics, chat widgets, ad tags — are the most common offenders. Load them async or defer them. Move critical CSS inline and load non-critical stylesheets asynchronously. Every millisecond of render-blocking delay pushes LCP further out.
Slow TTFB. LCP can't be fast if the server responds slowly. For React SPAs, server-side rendering or static generation is the most direct fix for slow TTFB. Edge caching and streaming SSR cut the time before the browser has anything to work with.
Worth noting: Google's own research found that shaving 100ms off LCP correlates with a 1% conversion rate improvement for e-commerce sites. Small gains compound. LCP isn't just an SEO metric — it's a revenue one.
INP is a runtime metric, not a load metric. It doesn't care how fast the page loads — it cares how the page responds to interactions after it loads. That changes where to look when INP is failing.
Break up long tasks. The browser can't respond to input while a JavaScript task is running. Tasks over 50ms block input handling. Use scheduler.yield() to break up long synchronous work and give the browser opportunities to handle input between chunks.
Optimize React rendering. Unnecessary re-renders are one of the most common INP failures in React apps. The React DevTools Profiler identifies components rendering more than they should. The React Compiler in React 19 handles much of this automatically — but only on code that follows the Rules of React.
Defer non-critical work. Analytics events and non-visible DOM updates triggered by interactions don't need to happen synchronously. Moving them into a requestAnimationFrame callback defers them until after the browser responds to the interaction.
INP failures are especially common in data-heavy applications where interactions trigger expensive processing or complex rendering. We ran into this in a data-heavy dashboard where filter interactions triggered full re-renders of large data tables. Virtualization and memoization brought INP from 480ms to under 180ms.
Reserve space for images and embeds. The most common CLS cause is images and iframes without explicit dimensions. Set explicit width and height on all images. Use aspect-ratio CSS for responsive ones. For ad slots, reserve space with a placeholder before content loads.
Control font loading. Web fonts cause layout shift when the fallback font is replaced and character metrics differ. Use font-display: optional to prevent the swap entirely. For branded fonts, size-adjust and ascent-override CSS descriptors let you match fallback metrics so closely the swap becomes invisible.
Watch for dynamically injected content. Chat widgets, cookie banners, and notification bars injected above existing content all cause layout shift. Render them server-side so they're present from the initial paint, or inject them below visible content.
For React applications, React SEO best practices covers the rendering patterns — SSR, SSG, ISR — that affect both CLS and LCP by controlling what the browser receives before JavaScript executes. The pattern choice matters as much as the individual optimizations.
The most common mistake: measuring Core Web Vitals only in Lighthouse. Lighthouse is a lab tool — it runs in a controlled environment with simulated throttling. Core Web Vitals that affect search ranking come from real user sessions via the Chrome User Experience Report.
A site can score 90+ in Lighthouse and still fail in the field. Google Search Console shows field data from CrUX directly, segmented by URL group. PageSpeed Insights shows both lab and field data side by side. The web-vitals.js library lets you instrument real sessions and send data to your own analytics — closing the loop between a code change and a measured improvement in real user experience.
Core Web Vitals are a proxy for user experience, and user experience is a proxy for business outcomes. Passing them isn't just about search ranking — it's about the conversion impact of faster load times, more responsive interactions, and a page that doesn't shift while it loads.
Performance work is part of what growth engineering looks like in practice — not a separate technical exercise, but integrated into how the frontend is built and measured. The sites that consistently pass Core Web Vitals aren't the ones that ran a post-launch optimization sprint.
They're the ones that built performance measurement into development from the start.
Start with field data. Find the actual failures. Fix the highest-impact issues in order of impact. Measure again. That cycle — applied to LCP, INP, and CLS separately — is what gets a site from failing to passing and keeps it there as the codebase grows.
October 26, 2026
