Core Web Vitals measure real-world user experience on the web. These metrics influence Google Search rankings and can affect whether visitors stay, engage, or convert.
What Are Core Web Vitals?
Core Web Vitals are a subset of Google’s Web Vitals initiative, launched in 2020 to give teams a shared way to measure user experience. They focus on loading performance, interactivity, and visual stability.
Google assigns each URL one of three statuses:
- ✅ Good – meets all thresholds
- ⚠️ Needs Improvement – partially meets thresholds
- ❌ Poor – fails one or more thresholds
For a URL group, the overall status follows its weakest metric. A poor CLS can leave the group rated “Poor” even when LCP and INP are strong.
The Three Core Web Vitals
The current Core Web Vitals set has three metrics:
FID (First Input Delay) was retired in March 2024 and replaced by INP, which gives a broader measure of responsiveness.
LCP – Largest Contentful Paint
LCP measures how long the largest visible content element takes to render in the viewport. It is often a hero image, large heading, or video thumbnail, and helps answer a simple question: has the page loaded?
What counts as an LCP element?
<img>elements<image>elements inside SVG<video>elements (poster image)- Block-level elements containing text
- Elements with a background image loaded via CSS
url()
Common causes of poor LCP
- Slow server response time (TTFB) – if your server takes too long to respond, everything else is delayed
- Render-blocking resources – CSS and JavaScript that prevent the browser from painting the page
- Unoptimized images – large, uncompressed files in JPEG or PNG format
- No CDN – serving assets from a single distant server
How to fix LCP
- Convert images to WebP (≈30% lighter) or AVIF (≈50% lighter)
- Add
<link rel="preload" as="image">for your hero image in the<head> - Eliminate render-blocking CSS and JS — inline critical CSS and defer the rest
- Deploy a CDN to reduce the physical distance between the server and the user
- Improve Time to First Byte (TTFB) — aim for under 600 ms through server-side caching, faster hosting, or edge computing
INP – Interaction to Next Paint
INP replaced FID as a Core Web Vital in March 2024. FID measured the delay before the browser began handling the first interaction; INP measures the time from an interaction to the next visual update. It covers clicks, taps, and keyboard input throughout a page visit.
When INP is poor, buttons, menus, and form fields can feel slow to respond—even if the page appeared to load quickly.
Common causes of poor INP
- Long Tasks on the main thread – JavaScript tasks exceeding 50 ms block the browser from responding
- Heavy third-party scripts – analytics, chat widgets, and ad networks often run expensive code
- Unoptimized event handlers – listeners that trigger complex DOM updates on every keystroke or scroll
- Large component re-renders – in frameworks like React or Svelte, unnecessary re-renders add up quickly
How to fix INP
- Break up Long Tasks using
scheduler.yield()orsetTimeoutchunking to yield back to the browser - Move expensive calculations off the main thread with Web Workers
- Apply
debounceandthrottleto scroll, resize, and input event listeners - Use code splitting — only load JavaScript that is actually needed for the current page
- Audit and reduce third-party scripts — each one competes for main thread time
CLS – Cumulative Layout Shift
CLS measures visual stability: how much content shifts unexpectedly during loading or interaction. Its calculation considers both the share of the viewport that moved and the distance the elements traveled.
With a high CLS, a banner can appear above a link just as someone clicks it, causing an accidental tap. The article notes that Google treats this as a ranking factor.
What causes layout shifts?
- Images without size attributes – the browser doesn’t know how much space to reserve before the image loads
- Ads, embeds, and iframes – dynamically injected content that pushes other elements down
- Web fonts (FOIT/FOUT) – fonts that load late and cause text to reflow as they swap in
- Dynamically injected content – popups, banners, or notifications added after the initial page render
How to fix CLS
- Always define explicit
widthandheightattributes on every<img>and<video>element - Reserve space for ads and dynamic content using a fixed-height wrapper (
min-height) - Use
font-display: optionalfor web fonts, or preload critical fonts with<link rel="preload"> - Avoid inserting new content above existing content unless it is triggered directly by user interaction
- Use the CSS
aspect-ratioproperty to maintain correct dimensions for responsive media
Why Core Web Vitals Matter for SEO
Google added Core Web Vitals to search ranking signals in the Page Experience update in 2021, and their weight has grown since then. They sit alongside signals such as mobile-friendliness, HTTPS, and the absence of intrusive interstitials.
Google’s scores use real-user data from the Chrome User Experience Report (CrUX), not lab simulations. A PageSpeed Insights lab score can therefore differ from the field data used for ranking. Device and connection conditions vary, so the site needs to work well for real visitors.
The article also describes business outcomes associated with better Core Web Vitals:
- Sites passing Core Web Vitals see lower bounce rates and higher conversion rates
- When two pages compete for the same keyword, the faster, more stable page gains the ranking edge
- Poor INP in particular causes users to abandon interactive tasks (checkout, search, forms) — directly hurting revenue
Core Web Vitals Lifecycle
Google publishes a lifecycle for its metrics so developers can prepare for changes:
- Experimental – new metrics under active testing; may change based on feedback
- Pending – metrics that have passed testing and have a defined timeline to become stable
- Stable – the current official set (LCP, INP, CLS) that Google actively uses in rankings
The set may change over time as Google introduces or retires metrics. Following the Web Vitals roadmap is part of ongoing technical SEO work.
How to Measure Core Web Vitals
Use both field data from real visitors and lab data from simulated tests:
Field Data Tools (Real Users)
- Google Search Console – Core Web Vitals report grouped by mobile/desktop and URL type
- PageSpeed Insights – shows both lab and field (CrUX) data for any URL
- Chrome User Experience Report (CrUX) – raw dataset queryable via BigQuery for large-scale analysis
Lab Data Tools (Simulated)
- Lighthouse (built into Chrome DevTools) – detailed audits with actionable suggestions
- WebPageTest – advanced tests from multiple locations, devices, and connection speeds
- GTmetrix – waterfall charts and historical trend tracking
Lab tests help diagnose problems. Field data shows how visitors experience the site and, according to this article, is what Google uses for ranking.
Core Web Vitals Optimization Checklist
Check the following before and after a major deployment:
LCP
- Hero image uses WebP or AVIF format
- Hero image is preloaded in
<head> - TTFB is under 600 ms
- CDN is configured for static assets
- Critical CSS is inlined; non-critical CSS is deferred
INP
- No Long Tasks exceeding 50 ms in Chrome DevTools
- Third-party scripts are audited and minimized
- Event listeners use
debounce/throttle - JavaScript is code-split and lazy-loaded
- Heavy computations use Web Workers
CLS
- All
<img>and<video>havewidthandheightset - Ad slots have a reserved
min-height - Web fonts use
font-display: swapor are preloaded - No content is injected above the fold after page load
The Bottom Line
LCP, INP, and CLS measure loading, responsiveness, and layout stability. Meeting all three thresholds can improve search competitiveness, reduce user frustration, and increase conversions. Keep monitoring them as part of technical SEO rather than treating the work as a one-time fix.
Set up Core Web Vitals monitoring through the CrUX API or Google Search Console email alerts. Check for regressions after deployments so you can investigate them before they affect search visibility.