Core Web Vitals in 2025: What Still Matters (And What Does Not)

What changed in Core Web Vitals for 2025?

The biggest change in the last two years was the March 2024 swap of FID (First Input Delay) for INP (Interaction to Next Paint). FID measured only the delay before the first user interaction; INP measures the full interaction latency throughout the entire page lifecycle. INP is a stricter, more representative metric that catches slow interactions FID completely missed.

Beyond that, the thresholds have been stable. LCP (Largest Contentful Paint) targets 2.5 seconds or less. CLS (Cumulative Layout Shift) targets 0.1 or less. INP targets 200 milliseconds or less. Hit all three and you are in the green; miss one and your site is labeled "needs improvement" in Google's Page Experience report.

The 2025 landscape is mostly about enforcement, not new metrics. Google has tightened how Core Web Vitals factor into rankings — the March 2024 core update increased the weight of page experience signals for mobile. Chrome UX Report data from February 2025 shows that only 38% of origins pass all three Core Web Vitals on mobile, compared to 62% on desktop. The mobile gap is where most sites lose rankings.

AI crawlers have also started using page-render signals to decide which pages to index deeply. A page that fails to render within the crawler's timeout gets partial or no content extracted — which means no AI citations. The connection between Core Web Vitals and AEO is indirect but real.

What is INP and why did it replace FID?

INP (Interaction to Next Paint) measures the time from a user interaction (click, tap, keypress) to the next painted frame that reflects the interaction. It is a worst-case metric — your INP score is the slowest interaction during the page lifecycle, with a few statistical adjustments for outliers.

FID, the metric it replaced, measured only the input delay — the time between the user's action and the browser starting to process the event handler. FID ignored how long the event handler itself took to run and how long the browser took to paint the result. A page with a 10ms input delay but a 500ms event handler scored perfectly on FID but felt terrible to users. INP fixes this by measuring the entire interaction duration.

The 200ms threshold is strict. Chrome UX Report data from February 2025 shows that 54% of mobile origins fail the INP threshold, compared to only 28% on desktop. The failure rate is high because INP catches real-world interactivity problems that FID missed entirely.

The fix is almost always the same: break up long JavaScript tasks, defer non-critical JavaScript, and use requestIdleCallback for background work. The most common INP killers are third-party scripts (analytics, chat widgets, ad scripts), large React re-renders, and synchronous event handlers that block the main thread for more than 50ms.

Audit your site with Chrome DevTools' Performance panel and look for tasks longer than 50ms — those are your INP problems. Each long task is a candidate for optimization via scheduler.yield(), web workers, or deferred execution.

How do you fix INP on mobile?

Mobile INP failures are the most common Core Web Vitals problem in 2025. The mobile main thread is slower, network conditions are worse, and third-party scripts have disproportionate impact. Here is a systematic fix approach.

Step 1: Identify long tasks. Open Chrome DevTools → Performance tab. Record a mobile throttled trace. Look for any task longer than 50ms. These are your INP violations. The Performance panel shows the exact call stack, so you can trace each long task to its source.

Step 2: Audit third-party scripts. Third-party scripts are responsible for 60%+ of INP failures on mobile. Common culprits: Google Tag Manager with too many tags, analytics scripts that run on every interaction, chat widgets that attach event listeners to every element, and ad scripts that perform synchronous layout reads. For each third-party script, ask: does it need to run on every interaction? If not, defer it with requestIdleCallback or load it asynchronously.

Step 3: Break up long tasks. Any JavaScript task longer than 50ms should be broken into smaller chunks. Use scheduler.yield() (available in Chrome 110+) to yield to the browser between chunks. For older browsers, setTimeout(fn, 0) is a fallback. The goal: no single task on the main thread exceeds 50ms.

Step 4: Move heavy work to web workers. Computations that take more than 50ms (data processing, template rendering, search indexing) should run in a web worker instead of the main thread. Workers run in a separate thread and do not block interactions.

Step 5: Re-measure. After each fix, re-run the Performance trace. INP improvements are often dramatic — a single deferred third-party script can cut INP from 400ms to 120ms.

What is LCP and why is it still the hardest vital to fix?

LCP (Largest Contentful Paint) measures when the largest visible element in the viewport renders. For most pages, that element is a hero image. For text-heavy pages, it is a large heading or paragraph block. For video pages, it can be the video poster image.

The 2.5-second threshold is achievable on desktop but hard on mobile, especially on slow networks. Chrome UX Report data shows that 35% of mobile origins fail the LCP threshold, compared to only 18% on desktop. The mobile gap is driven by network latency — a 2MB hero image loads in 0.5s on fiber but 8s on a throttled 4G connection.

The fixes, in order of impact:

1. Preload your hero image. Add <link rel="preload" as="image" href="hero.webp"> to your <head>. This tells the browser to start fetching the image before it parses the HTML, saving 200-500ms. 2. Serve modern image formats. WebP is 25-35% smaller than JPEG at equivalent quality. AVIF is 50-65% smaller. Use <picture> with format fallbacks. 3. Use a CDN. Serve images from a CDN edge node close to the user. This cuts TTFB for the image by 100-300ms depending on geography. 4. Remove render-blocking CSS. Inline critical CSS and defer the rest. Render-blocking stylesheets delay the browser from painting *any* content, including the LCP element. 5. Set explicit image dimensions. Without width and height attributes, the browser cannot reserve space and may delay the LCP paint while it calculates layout.

Common mistake: Optimizing LCP on a fast connection and ignoring the long tail. Google measures the 75th percentile of page loads. If your site loads in 1.5s on fiber but 5s on 4G, your official LCP score is 5s. Always test on throttled connections using Lighthouse or PageSpeed Insights.

How do you optimize LCP for mobile networks?

Mobile LCP optimization requires a different mindset from desktop. On mobile, network latency dominates — the round-trip time to the server and back is often 200-600ms on 4G, and the available bandwidth is 1-10 Mbps. Every byte matters.

Image optimization is the highest-ROI LCP fix. Start by measuring your hero image size. If it exceeds 50KB (compressed), you have an LCP problem on mobile. Resize the image to the maximum display dimensions (do not serve a 2000px image for a 400px mobile display), convert to WebP or AVIF, and compress aggressively (quality 70-80 is usually visually indistinguishable from 90+ on mobile screens).

Responsive images with `srcset` let you serve different image sizes for different screen widths. A mobile user gets a 400px image; a desktop user gets a 1600px image. This alone can cut mobile LCP by 1-2 seconds.

Preload the LCP image with <link rel="preload">. Without preloading, the browser discovers the image only after parsing the HTML and CSS — which can take 500ms+ on mobile. With preloading, the browser starts fetching the image immediately.

Avoid client-side rendering for above-the-fold content. Single-page apps that render the hero section with JavaScript add 200-500ms of JS parse + execute time before the LCP element appears. Server-side render the above-the-fold content and hydrate below the fold.

Use `fetchpriority="high"` on the LCP image element. This signals to the browser that this specific fetch should be prioritized over other concurrent network requests, which helps on bandwidth-constrained mobile connections.

What is CLS and why is it the easiest vital to fix?

CLS (Cumulative Layout Shift) measures unexpected layout changes — elements moving on the page after it initially renders. A CLS of 0.1 or less is the "good" threshold. Unlike LCP and INP, CLS is almost entirely fixable with discipline rather than deep engineering.

Chrome UX Report data shows that only 22% of mobile origins fail the CLS threshold, making it the most-often-passed vital. But for the sites that fail it, CLS creates a terrible user experience — buttons move during taps, text shifts during reading, and the page feels broken.

The four common CLS causes and their fixes:

1. Images without explicit dimensions. Always include width and height attributes (or aspect-ratio in CSS). Without them, the browser cannot reserve space, and the layout shifts when the image loads. Fix: <img width="800" height="450" src="hero.webp">. 2. Ads and embeds without reserved space. Third-party ad slots and embedded videos cause layout shifts when they load. Fix: reserve space with min-height in CSS or a placeholder element. 3. Web fonts causing FOIT/FOUT. Flash of Invisible Text (FOIT) and Flash of Unstyled Text (FOUT) cause layout shifts when the custom font loads and differs in metrics from the fallback. Fix: use font-display: optional (best for CLS) or font-display: swap (acceptable). 4. Dynamically injected content above the fold. Cookie banners, notification bars, and chat widgets that inject content above existing content push everything down. Fix: reserve space for these elements or inject them below the fold.

Fix all four and your CLS will be near zero. This is the easiest vital to fix and should be done first — it takes hours, not weeks.

Do AI crawlers care about Core Web Vitals?

AI crawlers (GPTBot, ClaudeBot, PerplexityBot) care about Core Web Vitals less directly than Googlebot does, but they are not indifferent. What they care about is whether the page renders cleanly within their crawl budget.

A page with a 6-second LCP may not finish rendering before the crawler's timeout (typically 5-10 seconds). When the crawler times out, the LLM gets a partial page — it sees the HTML structure but not the JavaScript-rendered content. For single-page apps, this means the LLM may see a blank page with a <div id="root"></div> and nothing else.

A page with a high CLS may have shifted content by the time the LLM parses it. If the LLM extracts text before a layout shift, it may extract the wrong text — content that was in one position before the shift and moved after. This is rare but happens with dynamically injected content.

A page with poor INP may have JavaScript event handlers that are still running when the crawler tries to interact with the page (some crawlers execute JavaScript to simulate user interactions). Long event handlers can delay content loading, reducing the amount of content the crawler captures.

The practical advice: Hit the green thresholds for Google, and you will be fine for AI crawlers. The green thresholds (LCP < 2.5s, CLS < 0.1, INP < 200ms) guarantee that your page renders completely within any reasonable crawler timeout. Do not over-optimize beyond the thresholds; the marginal SEO benefit is small and the AI-crawler benefit is negligible. Focus your energy on content structure and schema markup instead.

What Core Web Vitals advice can you safely ignore in 2025?

A lot of Core Web Vitals advice from 2020-2022 is now outdated or counterproductive. The web platform has evolved, browser capabilities have improved, and some optimizations that were critical three years ago now have minimal impact. Here is what you can safely stop worrying about.

• FID is dead. INP replaced it in March 2024. Any blog post, library, or tool that still references FID, Time to Interactive (TTI), or First Meaningful Paint (FMP) is stale. These metrics are no longer part of the Core Web Vitals rubric.
• Preconnect and dns-prefetch hints have minimal impact on modern browsers. Chrome now automatically preconnects to origins it discovers in the HTML. The manual hints save at most 20-50ms and only for the very first connection. Use them but do not obsess.
• Critical CSS inlining has diminishing returns once you ship a modern CSS framework (Tailwind, UnoCSS). The framework's CSS is typically under 10KB gzipped — inlining it provides at most 50ms of benefit while adding complexity to your build pipeline. Only inline CSS if your render-blocking stylesheet exceeds 15KB.
• Service workers for LCP are overkill. A service worker caching the hero image can improve repeat-visit LCP, but preloading + a CDN achieves the same result with far less complexity. Reserve service workers for offline-first PWAs, not LCP optimization.
• Above-the-fold JavaScript hydration is less necessary with modern SSR frameworks. Next.js, Nuxt, and Astro all support server-side rendering with selective hydration. If your framework handles this, you do not need to manually code split above-the-fold components.

How do Core Web Vitals affect Google rankings in 2025?

Core Web Vitals are part of Google's Page Experience ranking factor, which also includes mobile-friendliness, safe browsing, HTTPS, and intrusive interstitial penalties. In 2025, the weight of Page Experience in rankings has increased for mobile and remained stable for desktop.

Google has never disclosed the exact weight of Core Web Vitals in the ranking algorithm, but SEO correlation studies consistently find a small but statistically significant relationship. A 2024 study by Semrush analyzing 10M keywords found that pages passing all three Core Web Vitals rank 1.5 positions higher on average than pages that fail them, after controlling for other factors.

The tiebreaker effect: Core Web Vitals rarely move a page from position 20 to position 1. But they can break a tie between two equally relevant pages. If you and a competitor have similar content, backlinks, and relevance, and you pass all three CWV while they fail INP, you rank above them. In competitive niches, this tiebreaker matters.

The mobile penalty: Google's mobile-first indexing means that your mobile Core Web Vitals scores are what count, not desktop. If your mobile experience is poor (slow LCP on 4G, high INP from heavy JS), you lose rankings even if your desktop scores are perfect. This is the most common mistake: optimizing for desktop and ignoring mobile.

AI Overviews interaction: Google AI Overviews appear at the top of search results and are generated from pages that rank well. Pages with poor Core Web Vitals are less likely to be included in the retrieval set for AI Overviews because Google's quality filters penalize them. This creates an indirect link between CWV and GEO performance.

What is the connection between Core Web Vitals and AEO?

The connection between Core Web Vitals and Answer Engine Optimization is indirect but important. Answer engines need to crawl, render, and extract your content. Core Web Vitals determine whether that process succeeds or fails.

LCP → render completion. If your LCP exceeds the crawler's timeout, the LLM gets an incomplete page. For JavaScript-rendered sites (React, Vue, Angular), this is the most common AEO failure mode. The crawler sees a blank page because the JavaScript has not finished executing. The LLM extracts nothing and cites someone else.

CLS → extraction accuracy. Layout shifts can cause the LLM to extract text from the wrong element. If a hero section shifts down after a cookie banner loads, the LLM may extract the cookie banner text instead of your opening paragraph. This is a subtle but real extraction error.

INP → JavaScript execution. Poor INP usually indicates heavy main-thread JavaScript. Heavy JavaScript delays content rendering for crawlers that execute JS (some AI crawlers do, some do not). If the crawler executes JS and the main thread is blocked, content rendering is delayed.

The AEO implication: Passing all three Core Web Vitals is a prerequisite for AI extraction from JavaScript-rendered pages. For static HTML pages (Next.js SSR, Astro, Hugo), CWV matter less for AEO because the content is already in the HTML. But for SPA architectures, CWV directly determine whether AI crawlers can extract your content at all.

As our AEO guide explains, crawlability is the first step in the citation pipeline. If the page does not render, nothing else matters.

How to measure Core Web Vitals correctly

Measuring Core Web Vitals correctly requires field data (real user metrics) supplemented by lab data (synthetic tests). Relying on only one gives a misleading picture.

Field data sources:

- Chrome UX Report (CrUX) — Google's public dataset of real Chrome user metrics. This is what PageSpeed Insights and Search Console use. It represents the 75th percentile of real user experiences over 28 days. - web-vitals JavaScript library — Google's official library for measuring CWV in your own users. Deploy it to collect per-page, per-device, per-connection data. This is more granular than CrUX and lets you identify specific problem pages. - RUM providers (Datadog, New Relic, SpeedCurve) — Commercial RUM solutions that collect CWV with full context (URL, device, browser, geography). Essential for enterprise debugging.

Lab data sources:

- Lighthouse — Chrome's built-in audit tool. Runs a single throttled simulation. Good for development but does not represent real-user variance. Run it with --preset=desktop and --preset=mobile separately. - PageSpeed Insights — Google's web tool that shows both lab (Lighthouse) and field (CrUX) data side by side. Use this for quick audits. - WebPageTest — The most detailed lab testing tool. Supports multi-step flows, custom throttling, and filmstrip views. Use this for deep debugging.

The correct measurement workflow: Use CrUX/PageSpeed Insights for a baseline. Use web-vitals RUM for ongoing monitoring. Use Lighthouse during development. Use WebPageTest for deep debugging. Never rely on Lighthouse alone — it tests under ideal conditions that do not represent real mobile users.

What are the most common Core Web Vitals mistakes?

After auditing hundreds of sites for Core Web Vitals compliance, the same mistakes appear repeatedly. Here are the seven most common and how to fix each one.

• Optimizing for desktop only. Google uses mobile-first indexing. Your mobile CWV scores are what count. Fix: always test on throttled mobile (4G, mid-tier CPU).
• Measuring only Lighthouse scores. Lighthouse runs under ideal conditions. Real users on slow connections may see 2-3x worse metrics. Fix: deploy the web-vitals library for field data.
• Ignoring third-party scripts. Third-party scripts (analytics, ads, chat) are responsible for 60%+ of INP failures. Fix: audit every third-party script and defer non-critical ones.
• Serving unoptimized hero images. A 2MB JPEG hero image destroys mobile LCP. Fix: resize to display dimensions, convert to WebP/AVIF, preload with <link rel="preload">.
• Forgetting image dimensions. Images without width and height cause CLS when they load. Fix: always include explicit dimensions or aspect-ratio CSS.
• Client-side rendering above the fold. SPAs that render everything with JavaScript have poor LCP and may not render at all for AI crawlers. Fix: SSR above-the-fold content.
• Over-optimizing beyond the thresholds. Going from 2.4s to 1.8s LCP has minimal ranking benefit but can require significant engineering effort. Fix: hit the green thresholds and move on to higher-impact work like AEO.

Core Web Vitals for JavaScript-heavy sites

JavaScript-heavy sites — single-page apps, heavy React/Vue applications, interactive dashboards — face unique Core Web Vitals challenges. The fundamental issue is that JavaScript must download, parse, and execute before any content renders. This adds 500ms-3s to every vital.

LCP for SPAs: The LCP element is usually rendered by JavaScript, which means the browser has to download the JS bundle, parse it, execute it, fetch data (if client-side), and then render. This pipeline can take 3-5s on mobile. The fix: Server-side render the LCP element. Next.js getServerSideProps, Nuxt asyncData, or Astro partial hydration all render the above-the-fold content on the server and ship it as static HTML. The JavaScript hydrates later for interactivity.

INP for SPAs: React and Vue re-renders can be expensive. A single state update that triggers a re-render of 500 components can block the main thread for 200ms+. The fix: Use React.memo, useMemo, and virtualized lists to limit re-render scope. Consider useTransition for non-urgent updates. Move heavy computations to web workers.

CLS for SPAs: Client-side data loading often causes layout shifts — skeleton loaders are replaced by real content, causing the page to jump. The fix: Reserve space for dynamic content using CSS min-height or aspect-ratio. Use Suspense boundaries in React to prevent cascading layout shifts.

AI crawler consideration: AI crawlers that execute JavaScript will see your rendered content, but with a timeout. If your JS takes more than 5-10s to fully render, the crawler gets a partial page. SSR ensures the crawler gets complete content on the first request.

Core Web Vitals checklist for 2025

Here is a prioritized checklist for Core Web Vitals compliance in 2025. Order matters — fix the highest-impact items first.

• ✅ LCP: Preload the hero image with <link rel="preload" as="image">. Impact: 200-500ms improvement. Effort: 5 minutes.
• ✅ LCP: Serve WebP/AVIF with <picture> fallbacks. Impact: 25-65% image size reduction. Effort: 1-2 hours.
• ✅ LCP: Set explicit image dimensions (width and height). Impact: prevents CLS too. Effort: 5 minutes per image.
• ✅ CLS: Add `font-display: optional` to all custom font declarations. Impact: eliminates font-related CLS. Effort: 5 minutes.
• ✅ CLS: Reserve space for ads/embeds with min-height. Impact: eliminates ad CLS. Effort: 30 minutes per slot.
• ✅ INP: Audit third-party scripts and defer non-critical ones. Impact: 100-300ms INP reduction. Effort: 2-4 hours.
• ✅ INP: Break up long tasks with scheduler.yield(). Impact: 50-200ms INP reduction per task. Effort: varies.
• ✅ Verify mobile scores using PageSpeed Insights on throttled 4G. Impact: catches desktop-only optimization errors. Effort: 30 minutes.
• ✅ Deploy `web-vitals` RUM for field data monitoring. Impact: ongoing visibility. Effort: 1-2 hours.

What comes after Core Web Vitals?

Google has hinted at future additions to the Page Experience framework. Two metrics are in experimental stages and may become official Core Web Vitals in 2025-2026.

Navigation Timing: Google is experimenting with soft navigation handling in SPAs. When a user navigates between routes in a single-page app, the browser does not fire a traditional page load. Google is working on defining how LCP, CLS, and INP apply to soft navigations, which would make SPA page transitions measurable as first-class CWV events.

Long Animation Frames: The Long Animation Frames API (available in Chrome 123+) provides more detail than the Long Tasks API about why frames are slow. It captures the entire frame — style, layout, paint, and composite — not just the JavaScript task. This gives developers much better debugging information for INP issues. Google may use this API to refine INP measurement.

Responsiveness beyond INP: INP measures click and keypress interactions but does not measure scroll performance. Google researchers have proposed a Scroll Responsiveness metric that would measure janky scrolling. This is still experimental and may not become a Core Web Vital, but it highlights the direction: Google wants to measure all aspects of user-perceived performance.

For now, focus on the three current vitals. Future metrics will build on the same optimization principles — less main-thread JavaScript, efficient rendering, and reserved layout space. Getting the fundamentals right today prepares you for any future additions.

How to prioritize Core Web Vitals against other SEO work

Core Web Vitals are important, but they are not the most important SEO factor. Content quality, relevance, and backlink authority all carry more ranking weight. Here is how to prioritize CWV work against other optimization efforts.

Priority 1: Fix CWV failures that block AI extraction. If your site is a JavaScript SPA and AI crawlers cannot extract your content, fixing LCP (via SSR) is more important than any content optimization because it unlocks all AEO work. This is the one case where CWV is the top priority.

Priority 2: Fix content and structure for AEO. Writing citation-worthy content, adding FAQ schema, and publishing llms.txt have higher ROI than going from "good" to "great" CWV scores. A page with 3s LCP and excellent content will get cited; a page with 1.5s LCP and poor content will not.

Priority 3: Fix mobile CWV to hit green thresholds. Once your content is citation-worthy, fix your mobile CWV to pass all three thresholds. This removes the ranking penalty and ensures AI crawlers can extract your content. Going from "failing" to "passing" matters; going from "passing" to "excellent" does not.

Priority 4: Over-optimize CWV beyond thresholds. This is lowest priority. Going from 2.4s to 1.8s LCP has minimal ranking benefit but can require significant engineering effort. Only pursue this if your engineering team has spare capacity after all higher-priority work is done.

The 80/20: Spend 80% of your optimization budget on content + AEO and 20% on CWV. The content improvements compound; the CWV improvements mostly do not.