Core Web Vitals Explained

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page — usually a hero image, a big block of text, or a banner — to fully render. It's Google's proxy for "how fast does this page feel like it loaded."

Google's published thresholds: good is under 2.5 seconds, needs improvement is between 2.5 and 4 seconds, and poor is over 4 seconds, measured at the 75th percentile of real user visits.

• —Slow server response time (TTFB) delays everything downstream, including LCP
• —Large, unoptimized hero images are the single most common LCP culprit
• —Render-blocking CSS or JavaScript that has to load before the main content can paint
• —Client-side rendering that requires JavaScript to execute before the main content even appears in the DOM

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. Where FID only measured the delay before a browser started responding to the very first interaction, INP measures responsiveness across the entire page visit — every click, tap, and key press — and reports the worst (or near-worst) one.

Google's published thresholds: good is under 200 milliseconds, needs improvement is between 200 and 500 milliseconds, and poor is over 500 milliseconds, again at the 75th percentile of real visits.

INP is often the hardest metric to fix because the cause is usually JavaScript execution — heavy scripts blocking the main thread when a user tries to interact with the page, even after it visually appears loaded.

• —Long-running JavaScript tasks that block the main thread during user interaction
• —Heavy third-party scripts (chat widgets, analytics, ad tech) competing for the same thread
• —Large DOM size, which makes every re-render and event handler more expensive
• —Poorly optimized event handlers doing expensive work synchronously

Cumulative Layout Shift (CLS)

CLS measures visual stability — how much visible content unexpectedly shifts position while the page is loading or in use. It's the metric behind the frustrating experience of trying to tap a button just as an ad loads above it and pushes everything down.

Google's published thresholds: good is under 0.1, needs improvement is between 0.1 and 0.25, and poor is above 0.25. It's a unitless score based on how much of the viewport shifts and how far.

• —Images and embeds (ads, videos, iframes) with no reserved width/height, so the browser doesn't know how much space to leave
• —Web fonts that load late and cause text to reflow (flash of unstyled text / FOUT)
• —Content — banners, cookie notices — injected above existing content after the initial page load
• —Actions that trigger unexpected layout changes without user interaction

How to measure your own site

PageSpeed Insights and Google Search Console's Core Web Vitals report are the two most useful free tools. PageSpeed Insights shows both lab data (a simulated test run) and, where enough traffic exists, field data from the Chrome User Experience Report (CrUX) — real visitor data, which is what actually affects rankings.

Lab and field data can disagree, and when they do, field data is the one that matters for SEO. A page can score perfectly in a lab test and still fail Core Web Vitals in the real world if real visitors are on slower connections, older devices, or connecting from farther away from your server.