Your website could have great content and still tank in Google rankings. Why? Because Google is watching how your pages feel to real users, not just what they say.
That’s what Core Web Vitals measure. And if you’re failing them, you’re leaving rankings, traffic, and conversions on the table.
Here’s everything you need to know, and exactly how to fix it.
What are Core Web Vitals?
Core Web Vitals are 3 specific performance metrics Google uses to measure real user experience on your website. They’re part of Google’s Page Experience signals and directly influence your search rankings.
The 3 metrics are:
- LCP (Largest Contentful Paint) — how fast your main content loads
- CLS (Cumulative Layout Shift) — how stable your page layout is
- INP (Interaction to Next Paint) — how quickly your page responds to user input
You’ll notice FID (First Input Delay) is in this article’s title. That’s intentional. FID was the original responsiveness metric, but Google officially replaced it with INP in March 2024. If you’re still optimizing for FID, you’re working off outdated information.
Why Core Web Vitals matter for SEO in 2026
Google uses Core Web Vitals as a ranking signal. Not the only one, but a meaningful one, especially when two pages have similar content quality. The better your scores, the better your chances in competitive niches.
Beyond rankings, there’s a more direct impact. Slow pages lose users. Pages that jump around frustrate them. Pages that feel laggy when you click something feel broken.
Google’s own data shows that sites passing Core Web Vitals see lower bounce rates and higher conversions. So this isn’t just an SEO box to tick. It’s a business metric.
If you’re working on broader SEO fundamentals alongside technical fixes, both need to happen together.
The Core Web Vitals thresholds explained
Here’s the scoring breakdown for all 3 metrics:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | Under 2.5s | 2.5s – 4.0s | Over 4.0s |
| CLS | Under 0.1 | 0.1 – 0.25 | Over 0.25 |
| INP | Under 200ms | 200ms – 500ms | Over 500ms |
Google uses the 75th percentile rule: at least 75% of your real users need to hit “Good” on each metric for your page to pass. That data comes from the Chrome User Experience Report (CrUX), which collects field data from actual Chrome users.
This is why your Lighthouse score can look great but your Search Console still shows failures. Lighthouse is lab data, one simulated visit. CrUX is field data, thousands of real visits on real devices and real network conditions.
How to check your Core Web Vitals score
Before fixing anything, measure it. Use these tools:
- Google Search Console — go to Experience > Core Web Vitals. This shows your real field data, URL by URL.
- PageSpeed Insights — shows both lab (Lighthouse) and field (CrUX) data for any URL.
- GTmetrix — good for waterfall analysis and identifying what’s slowing down LCP.
- WebPageTest — more technical, great for advanced diagnostics.
- Web Vitals Chrome Extension — measures CWV on any page you visit in real time.
Start with Search Console. It tells you exactly which URLs are failing and why.
Fix 1: How to fix LCP (Largest Contentful Paint)
LCP measures how long it takes for the largest visible element on your page, usually a hero image, a large heading, or a video thumbnail, to fully load.
What causes poor LCP?
- Slow server response time (TTFB over 800ms)
- Render-blocking CSS and JavaScript
- Hero images that are too large or uncompressed
- Lazy loading applied to the LCP element (this is a very common mistake)
- No CDN, so assets load from a distant server
How to fix LCP:
1. Preload your LCP image. Add this to your HTML <head>:
<link rel="preload" as="image" href="hero-image.webp">
This tells the browser to fetch that image immediately, before it even starts parsing the rest of the page.
2. Convert images to WebP or AVIF. These next-gen formats are 30–50% smaller than JPEG with no visible quality loss. Tools like Squoosh, Cloudinary, or your hosting stack can handle this automatically.
3. Always set explicit width and height on images. This prevents layout reflow and also helps the browser allocate space before the image loads.
4. Never lazy load your LCP element. Lazy loading is great for below-the-fold images. Applied to the hero, it delays the most important load on your page. Remove loading="lazy" from your LCP image.
5. Improve TTFB. If your server responds slowly, everything downstream suffers. Use a quality host, enable server-side caching, and use a CDN like Cloudflare to serve content from a location close to your user.
6. Remove render-blocking resources. Defer non-critical JavaScript, inline critical CSS, and load stylesheets asynchronously where possible.
For WordPress sites specifically: Plugins like WP Rocket, NitroPack, or LiteSpeed Cache handle most of this through a UI. Enable preloading, lazy load exclusions for hero images, and CDN integration.
Fix 2: How to fix CLS (Cumulative Layout Shift)
CLS measures visual stability. Every time content jumps around as your page loads, that adds to your CLS score. A score of 0.1 or lower is the target.
What causes high CLS?
- Images loaded without width and height attributes
- Ads, banners, or cookie notices that inject into the page and push content down
- Web fonts that swap from fallback to custom, causing text reflow
- Dynamically injected content above existing content
How to fix CLS:
1. Always specify image dimensions. This one fix alone solves a massive chunk of CLS issues:
<img src="photo.webp" width="800" height="450" alt="...">
The browser pre-allocates that space before the image loads. Nothing shifts.
2. Reserve space for ads and banners. If you know an ad unit is 90px tall, give it a container with min-height: 90px before the ad loads. Same for cookie banners.
3. Fix font-related CLS. Use font-display: optional or font-display: swap with a closely matched fallback font. Better still, self-host your fonts so they load faster and you control the behavior. The size-adjust CSS descriptor (now widely supported) lets you match fallback and custom font metrics almost perfectly.
4. Don’t inject content above existing content. If you must add something dynamically (newsletter banners, notification bars), add it below the fold or reserve space for it upfront.
Globally, 81% of mobile pages now hit a good CLS score according to the 2025 Web Almanac. It’s the easiest Core Web Vital to fix once you know what to look for.
Fix 3: How to fix INP (Interaction to Next Paint)
INP replaced FID in March 2024, and it’s the hardest Core Web Vital to fix. FID only measured the delay before your browser started processing the first click. INP measures how long every interaction takes, start to finish, across the entire page session.
A page that clicks fast but has a form that takes 800ms to submit will now fail INP. That was invisible with FID.
What causes poor INP?
- Long JavaScript tasks (anything over 50ms blocks the main thread)
- Heavy third-party scripts (ad platforms, analytics, heatmaps, chat widgets)
- Complex event handlers running synchronously
- Too much JavaScript executing on interaction
How to fix INP:
1. Break up long tasks. Use setTimeout, scheduler.yield(), or the Scheduler API to split large JS tasks into smaller chunks. This gives the browser room to respond to user input between tasks.
2. Audit your third-party scripts. On average, third-party scripts account for 57% of JavaScript execution time on commercial sites. Run a performance audit in Chrome DevTools. Cut anything that isn’t earning its keep.
3. Use code splitting. Load only the JavaScript a page actually needs. Frameworks like Next.js and Nuxt.js handle this well. For WordPress, WP Rocket’s delay JavaScript feature defers scripts until user interaction.
4. Debounce and throttle event handlers. If you have search fields, filters, or scroll listeners firing constantly, debounce them so they don’t hammer the main thread.
5. Move work off the main thread. Web Workers let you run JavaScript in the background without blocking user interactions. For complex calculations or data processing, this is the right call.
For sites with heavy JavaScript, like ecommerce filter pages on WooCommerce or Shopify, INP is usually the hardest metric to crack. Start with third-party script audits. That alone often moves the needle significantly.
INP vs FID: what actually changed?
FID measured the delay before a browser started processing your first interaction. It only looked at that single first click, and only the input delay portion.
INP measures the full response time of every interaction on the page. Click a button, submit a form, open a dropdown. All of it counts. The worst interaction in your session determines your INP score.
A site that passes FID can fail INP. If your site has complex JavaScript-heavy interactions anywhere on the page, you need to audit INP specifically.
Platform-specific fixes
WordPress: Use WP Rocket or LiteSpeed Cache for preloading, JS deferral, and image optimization. Cloudflare handles CDN and caching at the network level. NitroPack automates most CWV fixes but adds a layer of complexity.
Shopify: Shopify’s hosting is generally solid for LCP. The main issues are usually theme JavaScript and third-party app scripts. Audit your installed apps. Every app that adds a script tag adds to your INP risk.
WooCommerce: Product filter scripts and AJAX-heavy cart interactions are common INP killers. Code splitting and lazy loading non-critical scripts makes a real difference.
Wix and other website builders: You have less control over the code, so focus on what you can control: image formats, lazy loading exclusions for hero images, and reducing installed widgets.
Core Web Vitals and local SEO
If you’re running a local business and wondering whether this applies to you, yes, it does.
A plumber in Islamabad, a marketing agency in Lahore, an e-commerce store in Rawalpindi — if your page loads slowly on a mid-range phone on a 4G connection, you’re losing customers before they even read your offer.
Google’s mobile-first indexing means your mobile Core Web Vitals scores are what actually count. Test your pages on a real mid-range Android device, not just a desktop Chrome simulation.
For practical guidance on how site speed ties into your full SEO strategy, the on-page SEO checklist at Flow Stack Hub covers this well alongside all the other technical and content factors.
If you’re also trying to understand why your website isn’t ranking despite publishing content, Core Web Vitals failures are one of the most common technical reasons that go unnoticed.
How long does it take to fix Core Web Vitals?
Honest answer: it depends on how broken things are.
Quick wins like setting image dimensions, preloading the LCP element, and removing lazy loading from the hero image can be done in an afternoon. You might see score improvements in Search Console within 28 days (that’s roughly how long Google takes to recollect field data).
Deeper fixes like INP optimization on JavaScript-heavy sites, TTFB improvements requiring server changes, or full image pipeline overhauls can take weeks. And the improvements show up in field data gradually, not overnight.
The key is to fix the highest-impact issues first. Use Search Console to identify which URLs are actually failing, then prioritize by traffic volume.
FAQ: Core Web Vitals questions answered
What are Core Web Vitals? Core Web Vitals are 3 metrics Google uses to measure real user experience: LCP (loading speed), CLS (visual stability), and INP (interaction responsiveness). They’re part of Google’s page experience ranking signals.
What replaced FID in Core Web Vitals? INP (Interaction to Next Paint) replaced First Input Delay in March 2024. INP measures all interactions on a page, making it a much stricter test of responsiveness than FID.
What is a good LCP score? Under 2.5 seconds is good. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.
What is a good CLS score? Under 0.1 is good. Between 0.1 and 0.25 needs improvement. Over 0.25 is poor.
What is a good INP score? Under 200ms is good. Between 200ms and 500ms needs improvement. Over 500ms is poor.
Why is my Core Web Vitals failing even though my Lighthouse score is good? Lighthouse runs in a controlled lab environment. Google uses real field data from Chrome users via the CrUX dataset. Your actual visitors use slower devices and connections than Lighthouse simulates. Field data and lab data can be very different.
How do I check Core Web Vitals for free? Google Search Console, PageSpeed Insights, and the Web Vitals Chrome Extension are all free. Search Console gives you URL-level field data. PageSpeed Insights shows both lab and field data for any URL.
Does Core Web Vitals affect Google ranking in 2026? Yes. Google uses Core Web Vitals as a page experience ranking signal. When content quality is similar between competing pages, CWV scores can tip the balance, especially on mobile.
How to pass Core Web Vitals for mobile? Focus on LCP first (preload hero images, compress to WebP), then eliminate layout shifts (set image dimensions, reserve ad space), then tackle INP (reduce JS execution, audit third-party scripts). Test on real mobile devices, not just desktop simulations.
Need help fixing your Core Web Vitals?
Technical SEO and web performance optimization take time to get right. If you’re spending hours in DevTools when you should be running your business, that’s a real cost.
Flow Stack Hub’s advanced digital services include full Core Web Vitals audits, technical SEO fixes, and ongoing performance monitoring. The team works across WordPress, WooCommerce, Shopify, and custom builds.
You can also explore how a proper digital marketing strategy fits Core Web Vitals into the bigger picture of organic growth.
For anyone serious about technical SEO, Google’s official PageSpeed Insights tool and web.dev Core Web Vitals documentation are the authoritative references. Read them. They’re regularly updated and reflect what Google actually measures.
Book a seat with Flow Stack Hub’s advanced digital services team and get your Core Web Vitals diagnosed and fixed properly.
