Core Web Vitals are a confirmed Google ranking signal that measure three dimensions of page experience: loading speed (LCP), interactivity (INP), and visual stability (CLS). They act as a tiebreaker between pages that are otherwise equal in relevance and authority — not a multiplier that overrides content quality.
That nuance matters. Most sites spend too much time chasing perfect Lighthouse scores when their actual GSC field data is already in the “Good” range. And many sites with real CWV problems dismiss them as irrelevant without understanding what the field data is telling them.
Here is what the data actually shows — and what is worth fixing.
What Core Web Vitals Are (and Are Not)
Google introduced Core Web Vitals as an official ranking signal in May 2021 as part of the Page Experience update. The signal is real. The weighting is lighter than most coverage suggests.
Google has been explicit about this: CWV do not override relevance or content quality. A slow page with excellent content and strong backlinks will almost always outrank a fast page with thin content. But when two pages compete on equal footing — similar content, similar authority — the one passing CWV thresholds has a measurable advantage.
The Ahrefs study published in 2023 found that pages in the top 10 results are more likely to pass Core Web Vitals than pages ranked 11–20, but the correlation is stronger for highly competitive keywords where multiple pages are close in quality. For low-competition long-tail keywords, CWV rarely determines the outcome.
The practical implication: fix CWV failures because they hurt user experience and have a real (if modest) SEO effect. Do not treat them as the primary lever for ranking improvement — that is still content and links.
The Three Metrics and Their Thresholds
Google defines three tiers for each metric based on field data:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | < 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | < 200ms | 200ms – 500ms | > 500ms |
| CLS | < 0.1 | 0.1 – 0.25 | > 0.25 |
A URL is classified as “Good” only if all three metrics pass at the 75th percentile of real user sessions. That last part is critical — you are not measured on your average user, but on the 75th percentile. A page that is fast for 80% of users but slow for the slowest 25% still fails.
LCP — Largest Contentful Paint
LCP measures how long until the largest visible element in the viewport is rendered. In practice, this is almost always your hero image or main heading block.
The Good threshold is under 2.5 seconds on real user connections. Most sites that fail LCP do so on mobile on slower connections — not on the fibre connection you test from.
The most common LCP failures
Hero image not preloaded. The browser discovers your LCP image too late because it is buried in CSS or loaded after render-blocking resources. Fix: add <link rel="preload" as="image" href="/hero.jpg"> in your <head>, and fetchpriority="high" on the <img> tag itself.
Oversized image for the viewport. Serving a 2400px wide image to a 390px mobile screen wastes bandwidth and delays LCP. Serve responsive images with srcset and sizes. Use WebP or AVIF format. A properly sized, next-gen format image typically cuts LCP by 40–60% on mobile. See the full image SEO optimization guide for the format and compression workflow.
Slow server TTFB. If your Time to First Byte (TTFB) is above 600ms, your LCP will suffer regardless of image optimisation. Check TTFB in PageSpeed Insights. Solutions: move to a faster host, add a CDN, or implement edge caching.
Render-blocking CSS or fonts. CSS in <link> tags in <head> blocks rendering until downloaded. Inline critical CSS. Load non-critical CSS asynchronously. Use font-display: swap for web fonts so text renders immediately even before the custom font loads.
In my experience auditing sites, LCP is almost always an image loading problem combined with a slow TTFB. Fix the image preload and reduce TTFB first — these two changes move the needle more than anything else.
INP — Interaction to Next Paint
INP replaced FID (First Input Delay) in March 2024. FID only measured the delay before the browser could respond to the first user interaction. INP measures the delay for every interaction throughout the session — clicks, taps, keypresses — and reports the worst one at the 75th percentile.
This is a meaningfully harder metric to pass. A site that scored well on FID can fail INP because heavy JavaScript processing during interactions (not just on page load) causes visible delays.
What causes high INP
Long tasks on the main thread. Any JavaScript task that takes more than 50ms is a “long task” that blocks the browser from responding to user input. Use the Performance panel in Chrome DevTools to identify and break up long tasks. Tasks above 200ms are the immediate priority.
Heavy event handlers. A click handler that synchronously processes data, updates the DOM, and triggers layout recalculations can easily take 300–500ms. Move expensive processing off the main thread using Web Workers, or defer non-critical updates using requestAnimationFrame.
Third-party scripts. Chat widgets, ad scripts, tag managers, and analytics libraries are frequent INP offenders. They execute on the main thread and cannot be optimised directly. Audit third-party impact in PageSpeed Insights under “Third-party code”. Load non-critical third parties after user interaction or via loading="lazy".
Framework hydration. React, Vue, and Angular apps often have high INP during hydration — the phase where the JavaScript framework takes over from server-rendered HTML. This can make every interaction slow for the first few seconds after load. Consider partial hydration or streaming SSR patterns. For a full field-data debugging process, see the dedicated INP optimization guide.
CLS — Cumulative Layout Shift
CLS measures the total amount of unexpected layout movement that occurs during a page’s lifetime. A score of 0.1 means 10% of the viewport shifted unexpectedly. Above 0.25 is Poor.
CLS is the metric most correlated with direct user frustration. A jumping layout causes mis-clicks, broken reading flow, and an experience that feels broken. According to Google’s own research, pages with high CLS see higher bounce rates independent of any ranking effect.
The most common CLS causes
Images without explicit dimensions. When the browser encounters an <img> tag without width and height attributes, it cannot reserve space before the image loads. The image then pushes content down when it arrives. Fix: always include width and height on <img> tags. CSS can still override these values — the browser only needs them to calculate the aspect ratio.
Ads and embeds without reserved space. Display ads, social embeds, and iframes injected into content areas shift layout when they load. Reserve space with a container of known dimensions before the dynamic content loads.
Web fonts causing FOUT. Flash of Unstyled Text occurs when the browser renders text in a fallback font, then re-renders it in the web font with different metrics (character width, line height). This causes layout shift. Use font-display: optional for non-critical fonts, or ensure fallback font metrics match the web font using the size-adjust descriptor.
Cookie banners and notification prompts. Any element that inserts above existing content causes CLS. Position consent banners as overlays that do not push content, or reserve space for them before page render.
How to Measure CWV Correctly
The key distinction is lab data vs field data.
Lab data (Lighthouse, PageSpeed Insights simulations) tests your page in a controlled environment with throttled connection and CPU settings. Useful for diagnosing specific issues. Not what Google uses for ranking.
Field data (CrUX — Chrome User Experience Report) measures real Chrome users visiting your actual pages. This is what Google Search Console shows and what affects your Page Experience signals.
A page can score 95 on Lighthouse and still fail field data if real users on slow mobile connections are having a different experience than the simulated test. Always check GSC first.
The correct measurement workflow
- Google Search Console → Experience → Core Web Vitals: See which URLs are classified as Poor or Needs Improvement based on real users. This is your priority list.
- PageSpeed Insights on specific URLs: Shows both field data (top of the report) and lab data (Lighthouse). Diagnose the specific metrics failing.
- Chrome DevTools Performance panel: For debugging INP and long tasks on specific interactions.
- Web Vitals Chrome Extension: Real-time CWV measurements as you browse your own site.
Fix Poor URLs before touching Needs Improvement. Each URL group in GSC affects the pages within it — a cluster of Poor pages can pull down the overall Page Experience signal for your domain.
The Priority Order
Not all CWV failures are equal. Here is how to prioritise:
First: Fix LCP failures on your top traffic pages. LCP is the most commonly failed metric and the most directly tied to perceived speed. Your homepage, main category pages, and top blog posts first.
Second: Audit and reduce third-party scripts. A single poorly-loaded chat widget or ad script can cause both INP and LCP failures across your entire site. The impact-to-effort ratio is high.
Third: Fix image dimensions and ad container sizing for CLS. These are usually quick fixes with immediate field data improvements, visible in GSC within 28 days.
Fourth: Address INP in JavaScript-heavy interfaces. This requires more development effort and is often lower priority unless you run a web app with complex interactivity.
For most content and service sites, fixing LCP and eliminating CLS from images and ads is enough to move from Poor to Good in GSC. The technical SEO audit typically uncovers all three in the first pass — along with the specific pages and elements causing the failures.
The Honest Summary
Pass the field data thresholds in Google Search Console. Fix critical failures on your highest-traffic pages first. Stop obsessing over Lighthouse lab scores.
Core Web Vitals are a real signal with a real effect on rankings — particularly in competitive verticals where content quality among top results is similar. They are also a proxy for user experience quality that affects bounce rate, engagement, and conversions independently of any ranking effect.
The SEO audit includes a full CWV field data review with prioritised fixes. If you already know you have CWV failures and need implementation support, the technical SEO service covers the full fix list. For a map of how Core Web Vitals connects to the full technical SEO landscape, see the Technical SEO Hub.
Frequently Asked Questions
Do Core Web Vitals directly affect Google rankings?
Yes, but as a lightweight tiebreaker signal, not a primary ranking factor. Google confirmed Core Web Vitals as a ranking signal in May 2021. They do not override content relevance or authority — but when two pages compete on equal footing, the one passing CWV thresholds has a measurable advantage.
Which Core Web Vital has the biggest impact on rankings?
LCP tends to have the most direct impact because it reflects perceived load speed. A poor LCP (above 4 seconds) is the most common failure in GSC field data and signals a clearly bad user experience. Fix LCP first, then INP, then CLS.
What is the difference between lab data and field data for Core Web Vitals?
Lab data comes from controlled tests (Lighthouse, PageSpeed Insights simulations) — useful for debugging but not what Google uses for ranking. Field data comes from real Chrome users via CrUX and is what appears in Google Search Console. Always optimise for field data thresholds, not lab scores.
How do I check my Core Web Vitals in Google Search Console?
Go to Google Search Console → Experience → Core Web Vitals. You will see URLs split into Good, Needs Improvement, and Poor categories based on real user data. Click any group to see which metric is failing and which pages are affected. Fix the Poor URLs first.
Does page speed affect rankings on mobile and desktop separately?
Yes. Google evaluates Core Web Vitals separately for mobile and desktop. Mobile tends to perform worse because pages are tested on slower connections and less powerful devices. In most industries, mobile traffic dominates — prioritise mobile CWV performance. Check both reports in GSC.
