Core Web Vitals Explained — LCP, CLS, INP

The Three Core Web Vitals

Google defines three Core Web Vitals, each measuring a different aspect of user experience:

• LCP (Largest Contentful Paint) — Loading performance. How long until the largest visible content element renders.
• CLS (Cumulative Layout Shift) — Visual stability. How much the page layout shifts unexpectedly during loading.
• INP (Interaction to Next Paint) — Interactivity. How long the page takes to respond to user interactions.

LCP — Largest Contentful Paint

LCP measures loading speed from the user's perspective. It marks the time when the largest image, video, or text block in the viewport finishes rendering. Google considers an LCP of 2.5 seconds or less as "good," and anything over 4 seconds as "poor."

Common causes of poor LCP:

• Slow server response times (high TTFB)
• Render-blocking JavaScript and CSS
• Large unoptimized images
• Client-side rendering that delays content

How to fix LCP:

• Use a CDN and optimize server response times. Target TTFB under 800ms.
• Preload the LCP image with <link rel="preload" as="image">
• Serve images in modern formats (WebP, AVIF) with proper sizing.
• Eliminate render-blocking resources. Inline critical CSS and defer non-critical scripts.
• Use server-side rendering or static generation instead of client-side rendering for above-the-fold content.

CLS — Cumulative Layout Shift

CLS measures visual stability. Every time a visible element shifts position unexpectedly (without user input), it contributes to the CLS score. A CLS of 0.1 or less is "good." Anything above 0.25 is "poor."

Common causes of layout shifts:

• Images and videos without explicit width/height dimensions
• Ads, embeds, or iframes that load late and push content down
• Web fonts that cause text to reflow (FOUT/FOIT)
• Dynamically injected content above the fold

How to fix CLS:

• Always set explicit width and height on images and videos so the browser can reserve space.
• Use font-display: swap and preload key fonts to minimize text reflow.
• Reserve space for ads and embeds with fixed-size containers.
• Avoid inserting content above existing content after the initial render.

INP — Interaction to Next Paint

INP replaced FID (First Input Delay) in March 2024 as the responsiveness metric. While FID only measured the delay of the first interaction, INP measures the latency of all interactions throughout the page lifecycle and reports the worst one (at the 98th percentile). An INP of 200ms or less is "good."

Common causes of poor INP:

• Long-running JavaScript tasks that block the main thread
• Excessive DOM size (over 1,500 elements)
• Heavy event handlers (especially on scroll and input)
• Third-party scripts competing for main thread time

How to fix INP:

• Break long tasks into smaller chunks using requestIdleCallback or scheduler.yield().
• Debounce event handlers and use passive event listeners where possible.
• Reduce DOM complexity and avoid deep nesting.
• Audit and defer third-party scripts. Load analytics and chat widgets after the page is interactive.

How to Measure Core Web Vitals

There are two types of data: lab data (synthetic testing) and field data (real user measurements). Google uses field data from the Chrome User Experience Report (CrUX) for ranking. Lab data is useful for debugging.

• Lab tools: Lighthouse, Chrome DevTools, WebPageTest
• Field tools: PageSpeed Insights, CrUX Dashboard, Search Console
• CheckFast Speed Test — Run a Lighthouse audit and get actionable recommendations instantly.