Google uses three metrics to measure real-world user experience on your website: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Together, they are called Core Web Vitals.
If any of these metrics fall into the "poor" range, your technical SEO audit is going to flag problems. Your users will feel them too. Slow pages and janky layouts push people away before they ever read your content.
This guide covers what each metric measures, the specific thresholds Google uses, and the practical fixes that actually move the numbers. No theory without action.
What Are Core Web Vitals?
Core Web Vitals are a set of performance metrics that Google considers essential to a good user experience. They focus on three dimensions: loading speed, interactivity, and visual stability.
Google introduced Core Web Vitals in 2020 and made them a ranking signal in 2021. The web.dev Web Vitals overview provides the official definitions and thresholds. The metrics have evolved since then. In March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric. If you are still optimizing for FID, you are optimizing for a metric that no longer counts.
Here is a quick summary of the three current vitals:
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | Loading speed | ≤ 2.5s | > 4.0s |
| INP | Interactivity | ≤ 200ms | > 500ms |
| CLS | Visual stability | ≤ 0.1 | > 0.25 |
Values between "good" and "poor" are classified as "needs improvement." Your goal is to get all three metrics into the green ("good") range for at least 75% of your page visits. That is the threshold Google uses when evaluating your page experience.
These metrics affect more than rankings. They correlate with conversion rates, bounce rates, and user satisfaction. A comprehensive on-page SEO checklist should include Core Web Vitals alongside content and markup checks.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element on the page to finish rendering. This is usually a hero image, a background image, or a large block of text. It tells users (and Google) how quickly the main content appears.
Good: 2.5 seconds or less. Poor: more than 4.0 seconds.
What causes slow LCP
- Unoptimized images (wrong format, oversized dimensions, no compression)
- Slow server response times (TTFB over 800ms)
- Render-blocking JavaScript and CSS in the
<head> - Client-side rendering that delays content visibility
- Lazy loading applied to the LCP image (this is a common mistake)
How to fix LCP
1. Preload your LCP image. If your largest visible element is an image, add a preload hint in the <head> so the browser starts downloading it immediately:
<link rel="preload" as="image" href="/hero.webp">2. Use modern image formats. WebP and AVIF files are significantly smaller than PNG or JPEG at equivalent quality. A 500KB hero PNG might compress down to 120KB as WebP. This matters for image SEO too, since faster-loading images create a better user experience signal.
3. Never lazy-load the LCP element. Lazy loading is great for below-the-fold images, but applying loading="lazy" to your hero image delays rendering. Set it to loading="eager" or simply omit the attribute.
4. Reduce server response time. Your Time to First Byte (TTFB) is the foundation. If the server takes 2 seconds to respond, you have already burned most of your LCP budget before a single byte is rendered. Use a CDN, enable server-side caching, and consider upgrading from shared hosting.
5. Eliminate render-blocking resources. Move non-critical CSS out of the <head> or inline the critical CSS directly. Add defer or async to non-essential scripts. Every blocking resource in the <head> delays LCP.
6. Set explicit dimensions on images. Always include width and height attributes. This lets the browser reserve space before the image loads, preventing layout recalculations that slow rendering.
Interaction to Next Paint (INP)
INP measures how quickly your page responds to user interactions, specifically clicks, taps, and keyboard inputs. It replaced FID in March 2024 because FID only measured the delay of the first interaction. INP captures responsiveness across the entire page visit and reports the worst interaction (approximately the 98th percentile).
Good: 200 milliseconds or less. Poor: more than 500 milliseconds.
What causes poor INP
- Long-running JavaScript tasks that block the main thread
- Heavy third-party scripts (analytics, ad platforms, chat widgets)
- Excessive DOM size (more than 1,500 nodes starts to hurt)
- Complex event handlers that trigger expensive re-renders
- Synchronous layout operations ("forced reflows") inside event handlers
How to fix INP
1. Defer third-party scripts. Analytics, chat widgets, and ad scripts are common offenders. Load them after the page is interactive:
<script src="analytics.js" defer></script>Better yet, load them only after user interaction or after a delay. If a chat widget is never used by 95% of visitors, loading it on every page load is wasting everyone's time.
2. Break up long tasks. Any JavaScript task that runs for more than 50ms blocks the main thread and prevents the browser from responding to user input. Use requestAnimationFrame or setTimeout to split heavy operations into smaller chunks:
function processItems(items) {
const chunk = items.splice(0, 100);
// process chunk
if (items.length > 0) {
setTimeout(() => processItems(items), 0);
}
}3. Reduce DOM size. A page with 5,000 DOM nodes is going to respond slower than one with 800 nodes. Every interaction triggers style recalculations, and the cost scales with DOM complexity. Remove unnecessary wrapper elements, use virtual scrolling for long lists, and keep your markup lean.
4. Avoid forced reflows in event handlers. Reading layout properties (like offsetHeight or getBoundingClientRect()) immediately after writing style changes forces the browser to recalculate layout synchronously. Batch your reads and writes separately.
5. Use content-visibility: auto for off-screen content. This CSS property tells the browser to skip rendering work for content that is not visible. It can dramatically reduce the rendering cost on long pages.
On mobile devices, INP problems are amplified because phones have less processing power than desktops. Always test on real mid-range devices, not just your high-end development machine.
Cumulative Layout Shift (CLS)
CLS measures how much the visible content shifts around while the page is loading and during interaction. If you have ever tried to tap a button only to have an ad load above it and push the button out of reach, you have experienced a layout shift.
Good: 0.1 or less. Poor: more than 0.25.
What causes CLS
- Images and videos without defined dimensions
- Ads, embeds, and iframes that resize after loading
- Web fonts that cause text to reflow (FOUT/FOIT)
- Dynamically injected content above existing content
- CSS animations that change element sizes or positions
How to fix CLS
1. Always set width and height on images and videos. This is the single most effective CLS fix. When the browser knows the dimensions before the resource loads, it reserves the correct amount of space:
<img src="photo.webp" width="800" height="600" alt="Description">You can combine this with CSS aspect-ratio for responsive layouts. The key point is that the browser needs to know the proportions upfront.
2. Avoid layout shifts from web fonts. When a web font loads and replaces the fallback, the text often resizes and shifts surrounding content. Use font-display: swap with a fallback font that closely matches the web font's metrics. You can also use font-display: optional to skip the swap entirely if the font has not loaded in time. For more on this, preloading your font files helps:
<link rel="preload" as="font" href="/fonts/main.woff2"
type="font/woff2" crossorigin>3. Reserve space for ads and embeds. If you display ads, set a minimum height on the ad container using CSS. This prevents the page from jumping when the ad creative loads. The same applies to embedded maps, videos, and social media widgets.
4. Never inject content above existing content. Banners, cookie notices, and notification bars should overlay existing content (using fixed or sticky positioning) rather than pushing it down. If you absolutely must insert content at the top, do it before the page renders or use CSS transforms instead of changing the element's layout position.
5. Use CSS transform for animations. Animations that change top, left, width, or height cause layout shifts. Animations using transform and opacity do not, because they happen on the compositor thread without affecting layout.
How to Measure Core Web Vitals
You need both lab data (synthetic tests you run yourself) and field data (real user measurements) to get the full picture. Lab data helps you debug. Field data is what Google actually uses for ranking.
Lab tools
- Chrome DevTools Performance panel: Record a page load and look at the LCP marker, layout shift events, and long tasks. This is the best tool for debugging specific issues.
- Lighthouse (in Chrome DevTools): Run an audit to get scores and specific recommendations. Keep in mind that Lighthouse runs on a simulated throttled connection, so the numbers will differ from real-world results.
- PageSpeed Insights: Enter a URL to see both lab results (Lighthouse) and field data (Chrome User Experience Report). The field data section shows how your actual users experience the page.
Field data tools
- Google Search Console: The Core Web Vitals report groups your URLs by status (Good, Needs Improvement, Poor) and lets you track progress over time.
- Chrome User Experience Report (CrUX): The dataset behind PageSpeed Insights field data. You can query it directly through BigQuery or the CrUX API for large-scale analysis.
- OwnVector: Run a Core Web Vitals check from your phone as part of a full AI SEO audit. OwnVector flags which vitals need attention and explains the fixes in plain English.
A critical distinction: lab tools like Lighthouse cannot measure INP because INP requires real user interactions. For INP data, you need field measurements or manual testing in DevTools where you interact with the page while recording a performance trace.
Prioritizing Your Fixes
When all three metrics need improvement, start with the one causing the most damage. Here is a practical order of operations:
1. Fix CLS first. CLS fixes are usually the fastest to implement. Adding width and height attributes to images, reserving space for ads, and preloading fonts can be done in an afternoon. The impact is immediate because CLS is measured on every page load without any variability from server conditions.
2. Fix LCP second. LCP improvements often require more infrastructure work (CDN setup, server optimization, image pipeline changes), but the fixes are well-understood and straightforward. Preloading the LCP image, switching to WebP, and inlining critical CSS will handle most cases.
3. Fix INP last. INP is the hardest to fix because it usually requires JavaScript refactoring. Identifying which interactions are slow, tracing them through your code, and breaking up long tasks takes more effort. But if your LCP and CLS are green, you have already eliminated two sources of user frustration.
Regardless of order, the fixes compound. Reducing render-blocking resources improves both LCP and INP. Optimizing images helps LCP and CLS. A thorough technical audit will surface all of these issues at once, so you can plan your work efficiently.
If you are not sure where your pages stand, run your site through OwnVector or PageSpeed Insights and focus on the metrics flagged as "poor" or "needs improvement" first. Do not chase perfect scores on metrics that are already green.
Frequently Asked Questions
Check Your Core Web Vitals in Seconds
OwnVector scans your site for Core Web Vitals issues, explains what is wrong, and tells you exactly how to fix it. 87 checks, AI explanations, from your phone.
Download OwnVector Free