Core Web Vitals are Google's metrics for measuring real-world user experience on your website. They measure how fast content loads, how quickly the page responds to interaction, and how visually stable the page is while loading. Since 2021, these metrics have been a confirmed ranking factor, meaning poor scores directly hurt your search visibility.
This guide explains each Core Web Vital in plain language, shows you how to test your site, and provides specific improvement strategies. For deeper performance techniques beyond Core Web Vitals, see our page speed optimization guide. Image optimization directly impacts LCP — read our image SEO guide for practical steps. each metric. Start by testing your URLs with our pagespeed checker and the bulk Core Web Vitals checker.
The three Core Web Vitals
Google currently measures three metrics:
- LCP (Largest Contentful Paint): How long it takes for the largest visible element to render. Measures loading speed.
- INP (Interaction to Next Paint): How long it takes for the page to respond to a user interaction (click, tap, keypress). Measures interactivity. INP replaced FID (First Input Delay) in March 2024.
- CLS (Cumulative Layout Shift): How much the page layout shifts unexpectedly during loading. Measures visual stability.
LCP: Largest Contentful Paint
LCP measures the time it takes for the largest content element in the viewport to fully render. This is usually a hero image, a video thumbnail, or a large heading block. LCP tells users the main content has loaded.
LCP thresholds
- Good: 2.5 seconds or less
- Needs improvement: 2.5 to 4.0 seconds
- Poor: Over 4.0 seconds
What affects LCP
- Server response time (TTFB): If the server is slow to deliver the initial HTML, everything downstream is delayed.
- Render-blocking resources: CSS, JavaScript, and fonts that block the browser from rendering the page.
- Image loading: Large, unoptimized images take longer to decode and render.
- Client-side rendering: JavaScript-heavy pages may delay content rendering until scripts execute.
How to improve LCP
Optimize server response time
Aim for TTFB (Time to First Byte) under 200ms. Steps to improve:
- Use a CDN to serve content from locations closer to users
- Enable server-side caching (object caching, page caching)
- Optimize database queries and add indexes
- Upgrade hosting if shared hosting is the bottleneck
- Use HTTP/2 or HTTP/3 for multiplexed connections
Eliminate render-blocking resources
- Defer non-critical JavaScript with defer or async attributes
- Inline critical CSS and defer non-critical stylesheets
- Preload key resources with link rel="preload"
- Remove unused CSS and JavaScript
Optimize images
- Use modern formats (WebP, AVIF) instead of PNG and JPEG
- Specify explicit width and height attributes
- Use img loading="lazy" for below-the-fold images (but not for the LCP image)
- Preload the LCP image
- Compress images without visible quality loss
Test your current image optimization with the pagespeed checker, which identifies oversized images and suggests optimal formats.
INP: Interaction to Next Paint
INP measures the latency of all interactions on a page throughout the entire session. When a user clicks a button, taps a link, or presses a key, INP measures how long it takes for the visual response to appear. It captures the worst-case interaction latency (the 98th percentile).
INP thresholds
- Good: 200 milliseconds or less
- Needs improvement: 200 to 500 milliseconds
- Poor: Over 500 milliseconds
What affects INP
- Long tasks: JavaScript tasks that run for more than 50ms block the main thread and delay interaction response.
- Heavy event handlers: Click or keypress handlers that perform too much work.
- Layout thrashing: Repeatedly reading layout properties and forcing reflows within the same frame.
- Third-party scripts: Analytics, ads, and chat widgets that execute on the main thread.
How to improve INP
- Break up long tasks: Use requestIdleCallback or setTimeout to break large tasks into smaller chunks that yield to the main thread.
- Use web workers: Offload heavy computation to web workers so the main thread stays responsive.
- Minimize third-party script impact: Load non-essential scripts after the page is interactive. Defer analytics and chat widgets.
- Optimize event handlers: Keep event handlers fast. Avoid DOM manipulation inside event handlers.
- Reduce DOM size: A large DOM (thousands of elements) increases the cost of layout calculations. Aim for under 1,500 DOM nodes.
- Use content-visibility: auto: This CSS property tells the browser to skip rendering off-screen content until the user scrolls near it.
The pagespeed checker identifies long tasks and third-party scripts that impact interactivity.
CLS: Cumulative Layout Shift
CLS measures how much the page layout shifts after it starts loading. Layout shifts happen when elements move unexpectedly: an image loads and pushes text down, an ad inserts itself above content, or a web font swaps and changes text size.
CLS thresholds
- Good: 0.1 or less
- Needs improvement: 0.1 to 0.25
- Poor: Over 0.25
What affects CLS
- Images without dimensions: Images without width and height attributes cause the browser to reflow when they load.
- Ads and embeds: Ad slots that load with different dimensions than the placeholder push content.
- Web fonts: Font swaps that change text size or spacing cause shifts.
- Dynamically injected content: Banners, cookie notices, and chat widgets that appear after page load.
- Late-loading CSS: Styles that arrive after initial render change element dimensions.
How to improve CLS
- Set explicit dimensions: Always specify width and height on images and videos. Use CSS aspect-ratio for responsive elements.
- Reserve space for ads: Set a fixed height for ad containers before the ad loads.
- Preload web fonts: Use link rel="preload" for critical fonts and use font-display: optional to prevent FOIT and FOUT.
- Avoid late-loading content above the fold: If you must add a banner or notification, reserve space for it in the initial HTML layout.
- Use CSS containment: Apply contain: layout to elements to isolate their layout impact.
- Transform animations only: Use transform for animations instead of properties that affect layout (width, height, top, left).
Run the pagespeed checker to identify specific elements causing layout shifts on your pages.
Testing Core Web Vitals
Lab testing
Lab tests simulate a page load in a controlled environment. They are useful for debugging but do not represent real-world user data.
- Use the pagespeed checker for a quick lab test of any URL
- Use Chrome DevTools Lighthouse for detailed performance audits
- Use WebPageTest for advanced testing with different connection speeds and devices
Field testing (real-user data)
Google ranks pages based on field data (real-user measurements), not lab data. The sources of field data:
- Chrome User Experience Report (CrUX): Google's public dataset of real-user Chrome measurements
- Google Search Console: The Core Web Vitals report shows field data for your pages
- PageSpeed Insights: Combines lab and field data
For bulk testing, use the bulk Core Web Vitals checker to evaluate multiple URLs at once.
Prioritizing fixes
Not every performance issue is equally impactful. Prioritize based on:
- Metrics failing thresholds: Fix pages where one or more Core Web Vitals are in the "Poor" range first.
- High-traffic pages: Improving CWV on your most-visited pages has the largest aggregate impact.
- Quick wins: Some fixes take minutes (adding image dimensions, preloading fonts) while others take days (migrating to a faster host). Start with quick wins.
Core Web Vitals and SEO
Core Web Vitals are part of Google's page experience signals. While they are a lightweight ranking factor compared to content relevance and backlinks, poor CWV scores can hold back an otherwise strong page. If two pages have similar content and authority, the one with better user experience will rank higher.
More importantly, CWV directly affects user satisfaction. A slow, janky page drives users away regardless of ranking. Improving CWV is good for users and good for business.
Monitoring CWV over time
Core Web Vitals change as you add content, install plugins, and modify templates. Build a monitoring routine:
- Test key pages with the pagespeed checker monthly
- Monitor the Search Console CWV report for regressions
- Test after every major site change (new plugin, template update, content addition)
- Use the bulk Core Web Vitals checker for quarterly site-wide audits
Core Web Vitals are not a one-time optimization. They are an ongoing practice that keeps your site fast, responsive, and stable for every visitor.