Google doesn’t just rank pages based on what they say anymore — it also cares deeply about how they feel to use. That’s exactly where Core Web Vitals come in. If your pages are slow to load, jumpy, or sluggish to respond to clicks, Google notices. And so do your visitors.
This guide walks you through every Core Web Vital in 2026 — what each metric measures, what the thresholds are, which tools to use for diagnosis, and concrete steps to fix the issues dragging your scores down.
TL;DR — Core Web Vitals at a glance
Google’s three Core Web Vitals measure real user experience: LCP (loading speed, “good” = under 2.5 seconds), INP (interactivity, “good” = under 200 milliseconds), and CLS (visual stability, “good” = under 0.1). All three must hit “good” at the 75th percentile of real user data for your page to pass.
What Are Core Web Vitals and Why Does Google Care?
Core Web Vitals are a set of three performance metrics Google uses to measure the real-world experience of visiting a web page. Not theoretical benchmarks from a controlled lab environment — actual experiences your visitors have on their devices, on their networks, right now.
Google introduced Core Web Vitals as part of its broader Page Experience signals, and they became an official ranking factor in 2021. The logic is straightforward: a fast, stable, responsive page keeps users happy. Happy users click, convert, and come back. Google wants to send people to pages that deliver.
In 2026, the stakes are even higher. With the rollout of AI Overviews and Generative Engine Optimization, Core Web Vitals have become the baseline requirement for appearing in AI-driven search results. In other words, if your page experience is poor, you’re not just at risk of ranking lower — you may not appear in AI-generated answers at all.
The three metrics cover three distinct dimensions of user experience:
- Loading — How fast does the main content appear?
- Interactivity — How quickly does the page respond when you click or tap?
- Visual stability — Does the page hold still while it loads, or do elements jump around?
Google evaluates these metrics at the 75th percentile of real visitor data collected through the Chrome User Experience Report (CrUX). That means 75% of your users need to have a “good” experience — not just the median visitor.
LCP (Largest Contentful Paint): What It Measures and How to Improve It
LCP measures how long it takes for the largest visible content element on your page to fully render. That’s usually your hero image, a featured photo, or the main headline block. The moment it appears is the moment your visitor thinks, “okay, the page is ready.”
LCP thresholds
| Rating | LCP Value |
|---|---|
| ✅ Good | Under 2.5 seconds |
| ⚠️ Needs Improvement | 2.5s – 4.0s |
| ❌ Poor | Over 4.0 seconds |
A slow LCP tells Google (and your users) that your page is loading sluggishly. Studies show that a 1-second delay in page load reduces conversions by 7%. If you’re running an e-commerce store or any page with a meaningful conversion goal, that adds up fast.
What causes a slow LCP?
The three most common culprits are:
- Slow server response time (TTFB) — If it takes your server 800ms+ just to start sending data, your LCP never had a chance.
- Render-blocking resources — Large CSS or JavaScript files that pause rendering before the browser can paint anything.
- Unoptimized images — A hero image that’s 3MB and not lazy-loaded will tank your LCP score.
How to fix your LCP
- Cut your Time to First Byte (TTFB) to under 200ms. Use a CDN or edge computing (Cloudflare Workers, Vercel Edge) to serve responses from servers geographically close to your users. This alone can reduce latency by 40–70%.
- Add
fetchpriority="high"to your LCP image tag. This tells the browser to prioritize loading that image above other resources. - Switch to modern image formats. WebP and AVIF files are significantly smaller than JPEG or PNG at equivalent quality. Smaller files = faster load.
- Preload your LCP resource. Use
<link rel="preload">in your<head>so the browser discovers and downloads the image earlier. - Eliminate render-blocking CSS/JS. Defer non-critical JavaScript and inline only the CSS needed to render above-the-fold content.
For a full technical breakdown, check our on-page SEO optimizer — it flags LCP issues alongside other on-page factors automatically.
CLS (Cumulative Layout Shift): Why Your Pages Are Jumping and How to Stop It
Picture this: you’re reading an article on your phone. You go to tap a link, and at the last second an ad loads above it and pushes everything down. You tap the ad instead. That’s a CLS problem.
CLS measures the total visual instability of a page — how much content moves around unexpectedly during loading or while you’re interacting with it. Google aggregates these shifts into a score from 0 to 1. Lower is better.
CLS thresholds
| Rating | CLS Score |
|---|---|
| ✅ Good | Under 0.1 |
| ⚠️ Needs Improvement | 0.1 – 0.25 |
| ❌ Poor | Over 0.25 |
What causes CLS?
- Images without explicit dimensions — The browser doesn’t know how much space to reserve, so it allocates space only after the image loads, pushing content down.
- Ads and embeds that appear without reserved space — Especially common with late-loading ad slots.
- Web fonts that cause a “flash of unstyled text” — Text reflows when the custom font loads, shifting surrounding elements.
- Dynamically injected content — Banners, cookie notices, or notifications inserted above existing content at page load.
How to fix CLS
- Always set
widthandheightattributes on images and video embeds. This reserves the correct space before the media loads, eliminating layout shifts. - Reserve space for ads and embeds. If your ad unit is 250×250px, give it a fixed container of that size, even before the ad loads.
- Use CSS
font-display: optionalorfont-display: swapto manage font loading gracefully. - Avoid inserting content above the fold after the page loads. If you must show a banner or toast notification, anchor it to the bottom of the viewport instead.
- Use CSS
transformfor animations. Transforms don’t trigger layout recalculations, unlike changes totop,left,margin, orpadding.
Since Google evaluates CWV through a mobile-first lens, prioritize fixing CLS on mobile viewports first — that’s where the most layout shift issues tend to appear.
INP (Interaction to Next Paint): The Newest Core Web Vital Explained
INP is the youngest of the three Core Web Vitals, having officially replaced First Input Delay (FID) in March 2024. It’s also the one most sites are currently failing.
INP measures how quickly your page responds to every click, tap, or keystroke during a user’s entire session — not just the first one. FID only measured the delay for the first interaction. INP captures the worst interaction at the 98th percentile, which makes it a much stricter test of your page’s responsiveness.
Here’s the stat that puts it in perspective: 43% of sites fail the 200ms INP threshold, making it the most commonly failed Core Web Vital in 2026.
INP thresholds
| Rating | INP Value |
|---|---|
| ✅ Good | Under 200 milliseconds |
| ⚠️ Needs Improvement | 200ms – 500ms |
| ❌ Poor | Over 500ms |
What causes poor INP?
Unlike LCP and CLS, which often have quick wins, INP issues run deep. The culprit is almost always JavaScript blocking the main thread. When the browser’s main thread is busy processing a script, it can’t respond to user interactions — so taps and clicks feel sluggish or delayed.
Common causes include:
- Long JavaScript tasks (tasks that take over 50ms to execute)
- Third-party scripts (analytics, chat widgets, tag managers)
- Heavy React or framework rendering on interaction
How to fix INP
- Break up long JavaScript tasks. Use
setTimeoutor the Scheduler API to split tasks so the browser can handle interactions between chunks. - Defer third-party scripts that aren’t needed for the initial interaction. Load them with
asyncordefer, or after user interaction. - Reduce JavaScript bundle size. Tree-shaking and code-splitting ensure users only download the JS they actually need.
- Offload heavy computation to Web Workers. Web Workers run in a separate thread, leaving the main thread free to handle user input.
- Audit your tag manager. Tag Manager containers can accumulate dozens of scripts over time. A quarterly cleanup often yields significant INP gains.
INP is the hardest CWV to fix because it requires changes to your JavaScript architecture, not just images or HTML structure. But it’s where the biggest untapped gains are hiding.
How to Measure Your Core Web Vitals (Tools and Methods)
Before you can fix anything, you need to know where you stand. Here’s the toolkit:
Field data tools (real user data — what Google actually uses)
- Google Search Console — Start here. The Core Web Vitals report groups your URLs by status (Good / Needs Improvement / Poor) and tells you which metric is failing. Google uses this same CrUX field data for ranking purposes. Check your indexing status and performance in your technical SEO audit.
- PageSpeed Insights — Combines real field data (from CrUX) with a Lighthouse lab test. Use it to diagnose specific URLs. Available at pagespeed.web.dev.
Lab data tools (simulated — useful for debugging)
- Google Lighthouse — Built into Chrome DevTools. Runs a simulated page load and scores your performance. Helpful for catching issues before they affect real users, but lab scores don’t always match field scores.
- WebPageTest — Detailed waterfall analysis of how page resources load. Excellent for tracing slow TTFB or render-blocking assets.
- GTmetrix — Combines Lighthouse with its own metrics. Good for monitoring and comparing page performance over time.
- DebugBear — Specializes in CWV monitoring with real user monitoring (RUM) capabilities. Particularly useful for INP debugging.
The right approach
Don’t obsess over your Lighthouse lab score. What Google uses is your field data — specifically the 75th percentile of real users from CrUX. Start in Search Console to find which pages and which metrics are failing, then use PageSpeed Insights or Lighthouse to understand why.
Also: if a URL doesn’t have enough traffic to generate CrUX data, Google may fall back to URL group data or origin-level data for that page.
How to Fix Core Web Vitals Issues: Step-by-Step Guide
Whether you’re starting from scratch or dealing with a handful of failing URLs, this is the sequence that works:
Step 1 — Audit your current status in Search Console.
Open the Core Web Vitals report. Look for pages marked “Poor” first — these carry the highest ranking risk. Note which metric is failing (LCP, INP, or CLS).
Step 2 — Prioritize by template, not by individual URL.
Most sites have repeating templates (product pages, blog posts, category pages). A fix to the template fixes all URLs at once. Identify which templates are behind the most failing URLs.
Step 3 — Diagnose with PageSpeed Insights.
Run a few representative URLs through PageSpeed Insights. It will call out specific issues with recommendations — slow server response, oversized images, render-blocking resources, and more.
Step 4 — Fix LCP first (usually the biggest ranking impact).
Start with server response time (TTFB), then image optimization, then render-blocking resources. These are usually the fastest wins.
Step 5 — Fix CLS (often quick wins with big impact).
Add width and height to images. Reserve space for ads. Audit late-loading content injections.
Step 6 — Tackle INP last (most complex).
Run a JavaScript audit. Identify long tasks in DevTools > Performance panel. Break them up or defer where possible.
Step 7 — Validate fixes in Search Console.
After deploying fixes, mark the issues as fixed in Search Console. Google’s validation period is typically 28–90 days, so be patient. Don’t rely solely on Lighthouse scores — wait for the field data to update.
Step 8 — Monitor continuously.
CWV scores can regress with new deployments, third-party script updates, or content changes. Set up ongoing monitoring with a tool like DebugBear or GTmetrix to catch regressions before Google does.
For a comprehensive audit covering CWV alongside all other technical factors, the technical SEO audit tool gives you a full picture in minutes.
Core Web Vitals Thresholds Reference Table
| Metric | What It Measures | ✅ Good | ⚠️ Needs Improvement | ❌ Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed of main content | < 2.5s | 2.5s – 4.0s | > 4.0s |
| CLS (Cumulative Layout Shift) | Visual stability | < 0.1 | 0.1 – 0.25 | > 0.25 |
| INP (Interaction to Next Paint) | Responsiveness to user input | < 200ms | 200ms – 500ms | > 500ms |
Google evaluates each metric at the 75th percentile of real user data via CrUX. All three must reach “Good” for a page to pass the overall Core Web Vitals assessment.
Do Core Web Vitals Actually Affect Your Google Rankings?
Yes — but with an important nuance: Google has confirmed that page experience signals, including Core Web Vitals, are a ranking factor, not a ranking guarantee. They work primarily as a tie-breaker between pages with similar content quality.
Put it this way: if your page and a competitor’s page both thoroughly cover the same topic, and your page has better Core Web Vitals scores, you’re more likely to rank higher. But great CWV won’t rescue a page with thin content or weak backlinks.
The data does tell a compelling story, though:
- Pages in position 1 show a 10% higher CWV pass rate than pages in position 9 (DebugBear)
- E-commerce sites achieving “good” scores across all three metrics see conversion improvements of 15–30%
- Sites passing all three CWV thresholds show on average 24% lower bounce rates and measurably higher engagement
The business case for fixing Core Web Vitals goes beyond rankings. A faster, more stable page converts better, retains visitors longer, and reduces drop-off — regardless of where it ranks.
One more reason to act in 2026: with Google’s AI Overviews now factoring in page experience as a baseline requirement, poor CWV scores can exclude you from AI-generated results entirely. That’s a new and significant exposure that didn’t exist two years ago.
For a deeper dive into all the technical factors that affect your search visibility, read our technical SEO checklist and explore the best AI SEO tools that can help you monitor and fix these issues at scale.
Frequently Asked Questions About Core Web Vitals
What are the three Core Web Vitals?
The three Core Web Vitals are LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). They measure loading speed, interactivity, and visual stability respectively.
What are the “good” thresholds for Core Web Vitals in 2026?
LCP should be under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. All three must reach “good” at the 75th percentile of real user data for your page to pass the overall CWV assessment.
Did INP replace FID?
Yes. Interaction to Next Paint (INP) officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP is stricter — it measures the worst interaction across a user’s entire session, not just the first one.
Are Core Web Vitals a direct Google ranking factor?
Google has confirmed they are a ranking signal, but they function as a tie-breaker rather than a dominant factor. Strong content and relevant backlinks still matter more. That said, poor CWV can hurt you in competitive queries and may exclude you from AI Overviews.
How long does it take for Core Web Vitals fixes to show in rankings?
After deploying fixes, CrUX data (which Google uses) typically updates over a 28-day rolling window. Search Console’s validation period is usually 28–90 days. Don’t expect overnight changes — monitor your field data and be patient.
Which tool should I use to check Core Web Vitals?
Start with Google Search Console for a site-wide view of failing pages. Then use PageSpeed Insights to diagnose specific URLs. For ongoing monitoring and real user data, tools like DebugBear or GTmetrix are excellent choices.
What is the hardest Core Web Vital to fix?
INP. Fixing INP requires deep changes to how your JavaScript handles user events — it’s not something you can solve with image compression or a caching plugin. Expect it to involve developer time and JavaScript architecture review.
Fix Your Core Web Vitals with Allable
Diagnosing and fixing Core Web Vitals manually across a large site is time-consuming. Allable’s technical SEO audit surfaces LCP, CLS, and INP issues alongside every other on-page signal — so you get a complete picture of what’s holding your rankings back, without the guesswork.
Run a full technical SEO audit with Allable — fix Core Web Vitals and more →
Whether you’re optimizing a single landing page or managing a multi-thousand-URL site, Allable gives you the data and recommendations to act fast and rank better.