What Are Core Web Vitals?
Core Web Vitals (CWV) are a set of three user-experience metrics that Google uses as ranking signals. They measure how fast a page loads its main content, how quickly it responds to user interactions, and how stable the layout is during loading.
In 2024, Google replaced the FID (First Input Delay) metric with INP (Interaction to Next Paint), making the current three metrics: LCP, INP, and CLS.
Quick benchmark: For all three metrics, "Good" = green, "Needs Improvement" = amber, "Poor" = red. Aim for green across all three on both mobile and desktop.
The Thresholds at a Glance
Google rates each metric as good, needs improvement or poor. A page passes Core Web Vitals when all three are in the "good" range for most real visits.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | 2.5 seconds or less | 2.5 to 4 seconds | Over 4 seconds |
| INP (responsiveness) | 200 ms or less | 200 to 500 ms | Over 500 ms |
| CLS (visual stability) | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Field Data vs Lab Data: Which One Counts?
This is the most common source of confusion. Field data comes from real visitors using real devices and connections, collected through the Chrome User Experience Report (CrUX). It is judged at the 75th percentile over a rolling 28-day window, and it is what Search Console and the top of PageSpeed Insights report. Lab data comes from a single simulated test, such as Lighthouse, which is ideal for debugging but doesn't decide your official status.
- A page can score 100 in a lab test and still fail in the field if real visitors use slower phones or networks
- Low-traffic pages may have no field data of their own, so PageSpeed Insights may show only a site-wide figure or nothing
- Because field data covers 28 days, improvements show up gradually, not overnight
How Much Do Core Web Vitals Affect Rankings?
They are part of Google's page experience signals, so they matter, but they are one signal among many. Google has said that relevance and content quality can still win even when page experience is imperfect. In practice, Core Web Vitals work best as a tie-breaker between pages of similar quality, and as a way to stop slow or jumpy pages from losing visitors who have already arrived.
That is a good reason to fix severe problems first, and to judge the work by user outcomes such as bounce rate, conversions and completed forms as well as by green scores.
Third-Party Scripts: The Hidden Cost
Ads, analytics, chat widgets, social embeds and tag managers often cause more damage to Core Web Vitals than your own code. They can delay the main content, block the main thread and push the layout around as they load.
- Measure the cost. Test a page with and without each third-party script and compare the results.
- Load them late. Use
asyncordefer, and delay non-essential widgets until the visitor interacts or scrolls. - Reserve space. Give ad and embed containers a fixed height or aspect ratio so they can't shift the layout when they load.
- Remove what you don't use. Old pixels and abandoned widgets still cost time on every page view.
- Fewer ad units help. If your pages carry ads, each extra unit adds scripts, iframes and layout risk, so keep them to the few that earn their place.
LCP — Largest Contentful Paint
LCP measures how long it takes for the largest visible element (usually a hero image or heading) to load. Target: under 2.5 seconds.
Common LCP culprits and fixes
| Problem | Fix | Impact |
|---|---|---|
| Unoptimised hero image | Convert to WebP, compress, add width/height attributes | High |
| Render-blocking resources | Defer non-critical JS and CSS | High |
| Slow server response (TTFB >600ms) | Upgrade hosting, add CDN, enable server caching | High |
| No preload for LCP image | Add <link rel="preload"> for the LCP element | Medium |
| Late-loaded fonts | Use font-display:swap and preconnect to Google Fonts | Medium |
Single biggest LCP win: Add fetchpriority="high" to your hero image tag. This tells the browser to prioritise loading it above everything else. Takes 30 seconds to implement.
INP — Interaction to Next Paint
INP replaced FID in March 2024. It measures the time from when a user interacts (click, tap, keypress) to when the browser paints the next frame. Target: under 200ms.
What causes high INP
- Long JavaScript tasks blocking the main thread
- Heavy third-party scripts (analytics, chat widgets, ad scripts)
- Inefficient event handlers
- Large DOM size (over 1,500 nodes)
How to fix INP
Audit Third-Party Scripts
Load your page with DevTools Network tab open. Identify which third-party scripts (Google Analytics, Facebook Pixel, chat widgets) are longest-running. Defer or async load all non-critical ones.
Break Up Long Tasks
Any JavaScript task over 50ms blocks the main thread and increases INP. Use Chrome DevTools Performance tab to identify long tasks and split them using setTimeout or scheduler.yield().
Reduce DOM Size
Pages with thousands of DOM nodes are slower to update. Aim for under 1,500 total DOM nodes. Virtualise long lists and remove unused HTML elements.
CLS — Cumulative Layout Shift
CLS measures unexpected layout shifts during page load — when elements move around as the page finishes loading. Target: under 0.1.
Common CLS causes and fixes
- Images without dimensions — Always add width and height attributes to every <img> tag
- Ads and embeds without reserved space — Pre-allocate space with min-height or aspect-ratio CSS
- Web fonts causing FOUT — Use font-display:optional or font-display:swap
- Dynamically injected content — Avoid injecting content above existing content on load
- Animations that affect layout — Use transform and opacity for animations, never top/left/width/height
Tools to Measure Core Web Vitals
| Tool | Data Type | Best For |
|---|---|---|
| Google Search Console | Real user data (CrUX) | Site-wide CWV overview, page groups |
| PageSpeed Insights | Both lab + field data | Per-page diagnosis with recommendations |
| Chrome DevTools | Lab data | Deep diagnosis, identifying specific issues |
| WebPageTest | Lab data | Waterfall analysis, filmstrip view |
| Lighthouse | Lab data | Quick audit with actionable suggestions |
Fix Priority Order
Always fix LCP first — it has the highest SEO impact and the clearest wins. Then CLS (often quick fixes). Then INP (usually requires developer involvement). Start with mobile — Google indexes mobile-first.
A Practical Fix Workflow
- Start with Search Console. Open the Core Web Vitals report and note which groups of URLs fail, on mobile and desktop.
- Pick one representative URL from the worst group and test it in PageSpeed Insights, looking at field data first.
- Find the cause. Use the diagnostics and the DevTools Performance panel to see what the largest element is, which scripts run long and what moves.
- Fix the template, not the page. Most problems come from shared templates, so one change usually improves a whole group of URLs.
- Deploy and re-test in the lab to confirm the fix works.
- Validate in Search Console. Use the "Validate fix" option and allow time for the 28-day field data to catch up.
Re-check after every major design, plugin or ad change, because new scripts and images are the most common cause of regressions.
Conclusion
Core Web Vitals are a permanent part of Google's ranking algorithm. Sites that consistently score green across LCP, INP, and CLS have a measurable competitive advantage — especially in niches where competitors are slow.
The good news: most CWV issues have straightforward fixes. Run a PageSpeed Insights audit on your three most important pages and tackle the top recommendations first. You'll see measurable improvement within days.
Frequently Asked Questions
Three Google ranking metrics: LCP (loading), INP (interactivity), and CLS (visual stability).
Under 2.5 seconds is Good. 2.5-4s is Needs Improvement. Over 4s is Poor.
INP (Interaction to Next Paint) replaced FID in March 2024.
Add width/height to images, pre-allocate space for ads, use font-display:swap, animate only transform/opacity.
Field data in Search Console and PageSpeed Insights is based on a rolling 28-day window of real visits, so improvements appear gradually. Lab tools such as Lighthouse show the effect immediately, but the field data decides the official status.
They matter for visitors on any site, because slow or jumpy pages lose people. For rankings they are one signal among many, so fix severe problems first and don't expect speed alone to outrank better content.
PageSpeed Insights combines lab data from one simulated test with field data from real users, while Search Console reports field data for groups of URLs. Lab results change with each run, and field data covers a longer period.
Need Help with SEO, AEO or GEO?
Let's build a visibility strategy that works across Google, AI answers and generative search.
Start a Free Consultation
