Core Web Vitals became a Google ranking signal in 2021 with the Page Experience update. Since then, the metrics have evolved: FID (First Input Delay) was retired in 2024 and replaced by INP (Interaction to Next Paint) — a change that caught many site owners off guard and pushed previously "passing" sites into failure thresholds.
In 2025, the three Core Web Vitals — LCP, CLS, and INP — are firmly embedded in Google's ranking algorithm and are increasingly important signals for AI-powered search, which evaluates page experience as part of content quality assessment. Understanding each metric deeply, and knowing how to improve it, is a fundamental competency for anyone serious about search performance.
Core Web Vitals in 2025: the full picture
The three current Core Web Vitals measure three distinct aspects of user experience:
- LCP (Largest Contentful Paint) — loading performance. How quickly does the main content of a page become visible?
- CLS (Cumulative Layout Shift) — visual stability. Does content jump around as the page loads?
- INP (Interaction to Next Paint) — responsiveness. How quickly does the page respond when a user interacts with it?
Google categorises each metric into three bands: "Good", "Needs Improvement", and "Poor". To achieve a passing Page Experience signal, the majority of your site's page views (based on field data from the Chrome User Experience Report) should fall into the "Good" band for all three metrics.
Largest Contentful Paint (LCP)
LCP measures the time from the page navigation start until the largest content element in the viewport is rendered. This is typically a hero image, an above-the-fold heading, or a large block of text. A good LCP score (<2.5 seconds) is achievable for most sites with the right optimisations.
The most common LCP culprits and their fixes:
- Slow server response (TTFB): If your Time to First Byte exceeds 800ms, everything downstream suffers. Solutions: CDN implementation, server-side caching, upgrade hosting. This is often the single most impactful LCP fix.
- Render-blocking resources: CSS and JavaScript that must load before the page can render. Solutions: defer non-critical JS, inline critical CSS, use resource hints (preload, prefetch, preconnect) for key resources.
- Unoptimised LCP image: The hero image is often the LCP element. Solutions: compress with WebP or AVIF, implement responsive images with srcset, add fetchpriority="high" to the LCP image element, ensure it's not lazy-loaded.
- No preloading of LCP resource: If your LCP element is a background image loaded via CSS, the browser discovers it late. Add an explicit preload link in <head> for the LCP image.
Cumulative Layout Shift (CLS)
CLS measures unexpected visual movement — content that appears to "jump" as other elements load around it. High CLS is frustrating for users and signals poor-quality page construction to Google and AI systems.
The most common CLS causes:
- Images and media without explicit dimensions: Any <img> tag without explicit width and height attributes causes the browser to reserve no space until the image loads, then expand the layout around it. Add dimensions to every image element — this is the single most common CLS cause and among the easiest to fix.
- Dynamically injected content: Ads, cookie banners, chat widgets, and any content injected after initial render can push existing content down. Reserve space for these elements or position them to avoid pushing other content.
- Web fonts causing FOUT/FOIT: Web fonts that load and replace fallback fonts after render can shift text layout. Use font-display: optional for non-critical fonts to prevent the swap entirely, or font-display: swap with appropriately matched fallback fonts.
- Animations using non-compositor properties: Animating top, left, width, height, or margin triggers layout recalculation. Use transform and opacity for animations instead — these run on the GPU compositor without affecting layout.
Interaction to Next Paint (INP)
INP replaced FID in March 2024 and is currently the Core Web Vital that most sites struggle with. While FID measured only the delay on the first interaction, INP measures the responsiveness of all interactions throughout the page lifecycle — clicks, taps, and keyboard inputs. A page with good INP (<200ms) feels snappy and responsive; poor INP (>500ms) makes the page feel sluggish even if it loaded quickly.
The key INP improvement strategies:
- Reduce JavaScript execution time: Long tasks (JS execution blocks exceeding 50ms) are the primary driver of high INP. Audit your JS with Chrome DevTools Performance panel and break long tasks into smaller chunks using setTimeout or scheduler.yield().
- Defer non-critical third-party scripts: Analytics, tag managers, chat widgets, and social sharing scripts often generate significant main thread blocking. Load these after interaction or with requestIdleCallback where possible.
- Optimise event handler code: Event listeners that do heavy work synchronously on click or keypress create input delay. Move expensive operations to Web Workers or structure them to yield back to the main thread quickly.
- Implement code splitting: Large JavaScript bundles that must be parsed on load increase the probability of long tasks blocking interactions. Code-split with dynamic imports to load JS only when needed.
INP vs FID in practice: Many sites that achieved "Good" FID scores are failing INP. FID only measured the delay on the first interaction and ignored processing time. INP measures the full input delay + processing time + presentation delay for every interaction. If you previously passed Page Experience with FID, re-audit with INP as the measure — you may find your real-world interactivity is worse than you thought.
Measuring and monitoring
Core Web Vitals should be monitored with both lab data (controlled testing tools) and field data (real user measurements):
- Google Search Console: The Core Web Vitals report shows field data from real users, categorised by URL group. This is the authoritative source for ranking signal assessment.
- PageSpeed Insights: Combines lab data (Lighthouse) and field data (CrUX) for individual URLs. Use this for diagnosing specific pages.
- Chrome DevTools: Performance panel for detailed lab-based profiling of LCP, CLS, and INP. Essential for diagnosing root causes.
- Web Vitals JavaScript library: For real user monitoring at scale, the web-vitals npm package provides accurate field measurements that you can send to your analytics platform.
Why Core Web Vitals matter for AI search
Beyond the traditional SEO ranking impact, Core Web Vitals are increasingly relevant to AI search visibility. AI systems that retrieve and evaluate web pages as citation candidates use page experience signals as quality filters — pages that fail Core Web Vitals thresholds are less likely to be selected as AI citation sources, even if their content is otherwise excellent.
The logic is straightforward: AI systems want to recommend sources that will give users a good experience. A page that shifts layout as it loads or responds sluggishly to interaction is a poor user experience, regardless of content quality. Achieving "Good" status across all three Core Web Vitals is therefore both a direct ranking signal and an indirect AI citability signal.
The good news is that Core Web Vitals optimisation is a solvable engineering problem. Unlike content quality or entity authority — which require sustained, long-term investment — most Core Web Vitals issues can be resolved in a focused sprint of technical work. The impact on both rankings and user experience is measurable and often immediate.
Is your brand invisible to AI search?
Get a free AI Visibility Audit — we’ll check your SEO, AEO & GEO scores and deliver a prioritised action plan within 3–5 days.
Get AI Audit →