Quick Answer
- Core Web Vitals are three signals Google measures from real user sessions: LCP (loading), INP (responsiveness), and CLS (visual stability).
- Google uses them as a ranking factor, but they act as a tiebreaker — content and authority still dominate.
- INP replaced FID in March 2024. If your audits still reference FID, they are outdated.
- Google pulls ranking data from CrUX (field data), not Lighthouse or PageSpeed Insights lab scores.
- Poor scores have fixable root causes — hero image size, render-blocking scripts, layout shifts from late-loading ads or fonts.
- Fixing them has a business case beyond rankings: faster, stable pages convert better.
What Are Core Web Vitals?
Core Web Vitals are a set of page experience signals that Google defined to measure how a real user experiences a webpage — not how fast it looks in a developer tool, but how it actually feels to someone loading it on a phone or laptop.
Three metrics make up the current set.
Largest Contentful Paint (LCP) — how long it takes for the largest visible content element (usually a hero image or headline block) to finish rendering. Google's threshold for "good" is under 2.5 seconds. "Needs improvement" is 2.5–4.0 seconds. Above 4.0 seconds is "poor."
Interaction to Next Paint (INP) — how quickly the page visually responds after a user interacts with it (a tap, a click, a keypress). INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. Good is under 200 milliseconds. Poor is above 500 milliseconds. The change matters because FID only measured the delay before the browser started processing an input — INP measures the full response time, giving a much more accurate picture of perceived responsiveness.
Cumulative Layout Shift (CLS) — a score measuring how much page elements move unexpectedly while a user is reading or about to interact. A late-loading ad that pushes a paragraph down, or a font swap that reflowing text — those are layout shifts. Good CLS is a score under 0.1. Above 0.25 is poor.
Core Web Vitals are three page experience signals — LCP, INP, and CLS — that Google measures from real Chrome user data and uses as a ranking factor.
All three thresholds are documented at web.dev/vitals.
Do Core Web Vitals Affect SEO?
Yes — but the effect is more nuanced than most audits imply.
Google treats Core Web Vitals as a tiebreaker: strong scores help when everything else is close, but they do not override content quality or authority.
Google has confirmed Core Web Vitals are a ranking signal as part of the broader Page Experience system. What they have also made clear is that relevance and authority still dominate ranking. A technically perfect page with nothing useful on it does not outrank a thorough, well-linked page with mediocre Core Web Vitals. The Google Search Central documentation puts it plainly: a great page experience does not override having great, relevant content.
Where Core Web Vitals actually move the needle:
- Competitive SERPs where content quality is roughly equal. When two pages are similarly relevant and authoritative, the page experience signal can tip the result.
- Mobile rankings. Performance on mobile is weighted heavily. If your LCP is 5 seconds on a 4G connection, that is visible to Google through CrUX and it matters.
- Conversion rate, independent of rankings. A page that loads in under 2.5 seconds and does not jump around converts better than a slow, unstable one. That is a business argument that stands on its own even before you factor in rankings.
The bottom line: if your pages are already ranking well on strong content, poor Core Web Vitals are unlikely to tank them. But if you are stuck in positions 4–10 and your content is solid, a technical cleanup can be the difference.
How Google Actually Measures This
This is where a lot of audits mislead clients.
The data Google uses for ranking comes from the Chrome User Experience Report, which is field data from real users — not the scores you see in a lab tool like Lighthouse.
Field data vs. lab data. Lab tools — Lighthouse, PageSpeed Insights in lab mode, WebPageTest — simulate a page load under controlled conditions. They are useful for diagnosis and they surface specific issues to fix. But Google does not use lab scores for ranking. It uses CrUX — the Chrome User Experience Report — which aggregates real performance data from Chrome users who have opted in to sharing browsing statistics.
What this means practically:
- Your Lighthouse score can be 95 and your CrUX data can still show "needs improvement" if real users are on slower devices or connections.
- A URL with very low traffic may not have enough CrUX data to generate field data at all. In that case, Google falls back to domain-level data.
- Google Search Console's Page Experience report and Core Web Vitals report show your CrUX field data, segmented by mobile and desktop. That is the number that matters for rankings. Check it there, not in a browser extension.
INP replaced FID as an official Core Web Vital in March 2024, making it the current standard for measuring a page's responsiveness to user interaction.
Common Causes of Poor Scores — and What Actually Fixes Them
LCP Problems
LCP is slow on most sites for one of a few reasons.
Unoptimized hero image. A 2MB PNG as the above-the-fold image will kill LCP on mobile. Fix: convert to WebP or AVIF, size it to the actual rendered dimensions, and use a <link rel="preload"> hint so the browser fetches it early. Serving images in modern formats is documented in Google's image optimization guidance.
Slow server response time (TTFB). If the server takes more than 600 milliseconds to deliver the first byte, LCP cannot be fast regardless of what else you do. A slow host, no CDN, or unoptimized server-side rendering are the usual culprits.
Render-blocking JavaScript and CSS. Resources that block the main thread before the page renders delay everything. Defer non-critical JavaScript, inline critical CSS, and audit what is loading in your <head>.
INP Problems
INP is the newest metric and the one most sites fail today. The root cause is almost always main thread congestion — too much JavaScript running at once, leaving the browser unable to respond to user input quickly.
Common triggers: heavy third-party scripts (chat widgets, tag managers loading dozens of tags synchronously, analytics libraries), large JavaScript bundles that execute on interaction, and unoptimized event handlers. The fix involves auditing long tasks in Chrome DevTools (Performance panel), deferring or removing non-essential third-party scripts, and breaking up long-running JavaScript tasks.
If you are on a JavaScript-heavy framework (React, Next.js, Vue), pay attention to hydration timing — the period between when the page visually appears and when it becomes interactive. That gap is a direct INP risk.
CLS Problems
Cumulative Layout Shift measures visual stability — specifically, how much page elements move unexpectedly while a user is reading or about to click.
The most common causes:
- Images and embeds without declared dimensions. If the browser does not know how tall an image is before it loads, it cannot reserve space — the layout shifts when the image arrives. Fix: always set explicit
widthandheightattributes on images. - Late-loading ads or embeds. An ad slot that loads after the text pushes content down. Reserve space for ad slots with a minimum height.
- Web font swaps. A system font rendering at a different size than the web font causes a reflow. Use
font-display: optionalorfont-display: swapwith fallback metrics tuned to minimize shift.
Platform-Specific Fixes
WordPress
WordPress with heavy page builders (Elementor, Divi) is the most common source of poor INP we see. The fix stack: a performance-focused host (or a CDN layer), a caching plugin that serves static HTML (WP Rocket, W3 Total Cache), image optimization at upload (Imagify, ShortPixel), and a hard audit of active plugins — most sites have 20–40 plugins, many running scripts on every page load.
LiteSpeed Cache is worth considering if you are on a LiteSpeed server. It handles many of these optimizations at the server level.
Shopify
Shopify's core theme files are generally well-optimized, but third-party apps are the performance killer. Every app you install can inject scripts. Audit installed apps, remove unused ones, and check whether the scripts they load are deferred. Shopify's Online Store Speed report surfaces which themes and apps affect your score.
For LCP specifically, your product hero image format and the order in which Shopify loads above-the-fold content matters. Use loading="eager" on the hero image and preload it in the theme's <head>.
Custom / Next.js / React
Use Next.js's built-in Image component — it handles lazy loading, sizing, and modern format serving automatically. For INP, profile long tasks with Chrome DevTools and move heavy computation off the main thread using Web Workers where possible. Server-side rendering (SSR) or static generation (SSG) produces better LCP than pure client-side rendering because the browser gets HTML immediately instead of waiting for JavaScript to build the page.
Measuring Your Scores: Where to Look
Google Search Console → Core Web Vitals report. This is your CrUX field data, segmented by mobile and desktop, grouped by URL cluster. It tells you which pages are failing and which need improvement. This is the source that matters for rankings.
PageSpeed Insights (pagespeed.web.dev). Shows both field data (CrUX, when available) and lab data (Lighthouse) in one view. Use the field data section to understand real-user experience, and the lab section to diagnose specific issues to fix.
Chrome DevTools → Performance panel. For diagnosing INP and main-thread blocking issues, this is the right tool. Record an interaction, identify long tasks, trace them to the specific script.
CrUX Dashboard (via Looker Studio). Google provides a free CrUX dashboard template that visualizes your origin-level field data over time. Useful for tracking improvement after a technical fix ships.
Fixing Core Web Vitals is a technical SEO task with a direct business case: faster, more stable pages convert at higher rates independent of any ranking benefit.
The sequence that works in practice: start with Search Console to identify which pages are failing and on which device type. Use PageSpeed Insights to get a Lighthouse diagnostic on the worst URLs. Fix the highest-impact issues (image format, render-blocking resources, layout shift from unsized images). Re-check Search Console 28 days later — that is how long it takes for CrUX data to refresh.
The Business Case Beyond Rankings
There is a temptation to treat Core Web Vitals as a pure SEO checkbox. That undersells the work.
A faster page with no layout shifts is a better page for every visitor, from every channel. Paid traffic, email, social — everyone who lands on a slow or unstable page has a worse experience and is more likely to leave before converting. The technical fixes that improve LCP and CLS are the same fixes that improve conversion rate.
If you are running Google Ads, page speed also feeds into Quality Score — specifically the landing page experience component. Lower Quality Scores mean higher CPCs (cost per click) for the same ad position. A slow landing page is a paid media tax on top of its SEO cost.
This is why we treat web performance as infrastructure work, not a one-time audit. Build it right, and the compound effect runs across organic rankings, paid media efficiency, and conversion rate simultaneously.
Frequently Asked Questions
What are Core Web Vitals?
Core Web Vitals are three page experience signals that Google measures from real Chrome user sessions: Largest Contentful Paint (LCP), which measures loading speed; Interaction to Next Paint (INP), which measures responsiveness to user input; and Cumulative Layout Shift (CLS), which measures visual stability. Google uses them as a ranking factor as part of its broader Page Experience system.
Do Core Web Vitals affect SEO?
Yes. Google uses Core Web Vitals as a ranking signal, but they function as a tiebreaker rather than a primary ranking driver. Content relevance and backlink authority still dominate rankings. Where Core Web Vitals matter most is in competitive SERPs where the top-ranking pages are similarly relevant and authoritative — there, better page experience scores can tip the result in your favor.
What replaced FID in Core Web Vitals?
INP (Interaction to Next Paint) replaced FID (First Input Delay) as an official Core Web Vital in March 2024. INP measures the full visual response time to any user interaction, not just the first one, making it a more accurate measure of a page's real-world responsiveness.
What is a good LCP score?
Google's threshold for "good" LCP is under 2.5 seconds, measured for real users. Between 2.5 and 4.0 seconds is "needs improvement." Above 4.0 seconds is "poor." These thresholds are documented in Google's Core Web Vitals documentation at web.dev/vitals.
What is a good CLS score?
A CLS score under 0.1 is considered "good." Between 0.1 and 0.25 is "needs improvement." Above 0.25 is "poor." Common causes of high CLS are images without declared dimensions, late-loading ads that shift content, and web font swaps that cause text to reflow.
Does Lighthouse score affect Google rankings?
No. Lighthouse is a lab tool that simulates page load under controlled conditions. Google uses CrUX field data — real performance measurements from actual Chrome users — for ranking signals, not Lighthouse scores. Lighthouse is useful for diagnosing what to fix, but a high Lighthouse score does not directly improve your ranking if your CrUX data still shows poor field performance.
How long does it take for Core Web Vitals improvements to show in Search Console?
The Chrome User Experience Report updates approximately every 28 days, which is how frequently the data in Google Search Console refreshes. After shipping a performance fix, expect to wait roughly 28 days before the Core Web Vitals report in Search Console reflects the improvement.
How do I check my Core Web Vitals field data?
Open Google Search Console and navigate to the Core Web Vitals report under the Experience section. This shows CrUX field data for your URLs, segmented by mobile and desktop, with specific pages grouped by issue type. You can also view field data for any URL using PageSpeed Insights (pagespeed.web.dev), which displays the CrUX data for that URL alongside a Lighthouse diagnostic.
Are Core Web Vitals the same for mobile and desktop?
Google measures Core Web Vitals separately for mobile and desktop users and reports them separately in Search Console. Mobile thresholds are the same as desktop (same LCP, INP, and CLS numbers), but mobile scores are typically harder to hit because of slower device CPUs and variable network connections.
Can poor Core Web Vitals hurt my Google Ads performance?
Yes. Google Ads Quality Score includes a landing page experience component that accounts for page speed and usability. Pages with poor performance tend to receive lower landing page experience ratings, which can reduce Quality Score and result in higher cost per click for the same ad position.
If your Core Web Vitals are flagged in Search Console and you are not sure where the revenue impact actually is — rankings, paid media efficiency, or conversion rate — that is the kind of audit we run before recommending any work. Book a strategy call and we will look at your real field data together.
For a broader look at how technical performance fits into a full SEO system, see our SEO services overview.