Core Web Vitals: What They Are and How to Monitor Them

Core Web Vitals are a set of three metrics that Google uses to measure the real-world user experience of your web pages. They quantify how fast your page loads, how quickly it responds to user interactions, and how visually stable it is during loading. Google uses these metrics as ranking signals, which means they directly affect your search visibility.

This guide explains each metric, what "good" looks like, how to measure your scores, and how to set up ongoing monitoring. For a broader look at performance, see website performance monitoring.

The Three Core Web Vitals

Largest Contentful Paint (LCP)

What it measures: How long it takes for the largest visible content element to render in the viewport. This is typically a hero image, a large text block, or a video poster. LCP represents the point where the user sees the main content of the page.

Thresholds:

• Good: 2.5 seconds or faster
• Needs improvement: 2.5 to 4.0 seconds
• Poor: slower than 4.0 seconds

Common causes of slow LCP:

• Large, unoptimized images (the most common cause)
• Slow server response time (high TTFB)
• Render-blocking CSS and JavaScript
• Client-side rendering that delays content display
• Slow resource loading from third-party origins

How to improve:

• Optimize and compress images (use WebP or AVIF formats)
• Preload the LCP image with <link rel="preload">
• Reduce server response time
• Use a CDN to serve static assets from edge locations
• Minimize render-blocking resources

Interaction to Next Paint (INP)

What it measures: The responsiveness of a page to user interactions. INP observes all click, tap, and keyboard interactions during a page visit and reports the worst interaction latency (with outliers excluded). It replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Thresholds:

• Good: 200 milliseconds or faster
• Needs improvement: 200 to 500 milliseconds
• Poor: slower than 500 milliseconds

Common causes of poor INP:

• Long JavaScript tasks blocking the main thread
• Heavy event handlers that take too long to execute
• Large DOM size that slows rendering updates
• Third-party scripts competing for main thread time
• Excessive layout recalculation after user interaction

How to improve:

• Break up long JavaScript tasks into smaller chunks
• Defer non-critical JavaScript
• Reduce the work done in event handlers
• Use requestAnimationFrame for visual updates
• Minimize DOM size
• Audit and reduce third-party script impact

Cumulative Layout Shift (CLS)

What it measures: Visual stability. CLS quantifies how much the page layout shifts unexpectedly during loading. When elements move around as the page loads (text jumps down when an image loads, a button shifts when an ad appears), CLS captures that instability.

Thresholds:

• Good: 0.1 or less
• Needs improvement: 0.1 to 0.25
• Poor: greater than 0.25

Common causes of high CLS:

• Images without explicit width and height attributes
• Ads, embeds, and iframes without reserved space
• Web fonts that cause text reflow (FOUT/FOIT)
• Dynamically injected content above existing content
• Late-loading third-party content (cookie banners, chat widgets)

How to improve:

• Always specify width and height on images and videos
• Reserve space for ad slots and embeds with CSS
• Use font-display: swap with appropriate fallback fonts
• Avoid inserting content above existing content after page load
• Use CSS aspect-ratio for responsive media elements

How Core Web Vitals Affect Rankings

Google confirmed Core Web Vitals as a ranking signal in 2021. The impact is real but should be kept in perspective:

• Core Web Vitals are one signal among hundreds. Content relevance, backlinks, and user intent are still more important.
• The impact is most noticeable when competing pages are otherwise similar in content quality and relevance. In a tie between two equally relevant pages, the faster one may rank higher.
• The thresholds matter. Passing the "good" threshold is what counts. Going from 2.0s LCP to 1.5s LCP will not boost your ranking further -- you have already passed the threshold.
• Google uses field data (real user measurements), not lab data. Your CrUX (Chrome User Experience Report) scores are what Google uses for ranking, not your Lighthouse scores.

Measuring Core Web Vitals

Field data (real users)

Field data comes from actual users visiting your site. It is the most accurate representation of real-world experience and what Google uses for ranking decisions.

Google Search Console: The Core Web Vitals report shows field data for all your pages, grouped by status (good, needs improvement, poor). This is the most actionable view for monitoring.

PageSpeed Insights: Shows field data (from CrUX) at the top of the report and lab data below. The field data section shows real user LCP, INP, and CLS scores.

Chrome User Experience Report (CrUX): The underlying dataset that powers both Search Console and PageSpeed Insights. You can query it directly through the CrUX API or BigQuery for custom analysis.

web-vitals JavaScript library: Add Google's web-vitals library to your site to collect field data directly and send it to your own analytics:

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

Lab data (synthetic tests)

Lab data comes from controlled testing environments. It is useful for debugging and development but does not reflect real user conditions.

Lighthouse: Built into Chrome DevTools and available as a CLI tool. Runs a series of tests against a page and reports performance scores including all Core Web Vitals.

WebPageTest: An open-source tool that tests page performance from various locations and connection speeds. Provides detailed waterfall charts and filmstrips.

PageSpeed Insights (lab section): The bottom section of a PSI report shows Lighthouse lab data alongside the field data.

The gap between field and lab data

Lab data and field data often differ significantly. Lab tests run on controlled connections and devices. Real users visit on everything from fast fiber connections on powerful desktops to slow 3G connections on budget phones.

It is common to have "good" lab scores but "poor" field scores (your test conditions are better than your average user's) or "poor" lab scores but "good" field scores (your users happen to have fast devices and connections).

For monitoring purposes, field data is what matters. Lab data is useful for diagnosing and fixing issues.

Setting Up Core Web Vitals Monitoring

Passive monitoring (field data review)

At minimum, check Google Search Console's Core Web Vitals report weekly:

1. Log in to Search Console
2. Navigate to Experience > Core Web Vitals
3. Review the report for both mobile and desktop
4. Investigate any pages in the "Poor" or "Needs improvement" categories
5. Click into specific issues to see affected URL groups

Search Console groups pages by similar patterns. If one page has poor LCP, all pages using the same template likely do too. Fixing the template fixes the entire group.

Active monitoring (synthetic tests)

Set up automated Lighthouse tests on your key pages:

• Homepage
• Top landing pages
• Conversion pages (checkout, signup)
• Content-heavy pages (blog posts with images)

Run tests daily or weekly. Track scores over time to detect regressions. Many CI/CD tools support Lighthouse integration so you can catch performance regressions before they reach production.

Real user monitoring (RUM)

For the most complete picture, implement real user monitoring using the web-vitals library or a RUM service. This gives you:

• Continuous field data (not just the CrUX 28-day rolling window)
• Segmentation by page, device type, connection speed, and geography
• Alerts when metrics degrade

Common Monitoring Mistakes

Only checking lab scores

Lab scores from Lighthouse are useful for debugging but do not represent real user experience. A page that scores 100 in Lighthouse may still have poor field data if real users are on slow connections.

Checking once and forgetting

Core Web Vitals change over time as you update your site, add new features, and introduce new third-party scripts. Set up a regular monitoring schedule.

Ignoring mobile

Google uses mobile Core Web Vitals for ranking (mobile-first indexing). If your desktop scores are great but your mobile scores are poor, your search rankings are affected. Always check both.

Optimizing the wrong pages

Focus on pages that actually get search traffic. Optimizing an internal admin page that nobody finds through search is wasted effort. Use Search Console data to identify which pages have poor scores and significant search impressions.

Treating all metrics equally

Prioritize by impact. LCP is often the highest-leverage improvement because it directly affects perceived load speed. CLS fixes are usually simpler (add width/height to images). INP improvements often require JavaScript refactoring, which is more complex.

Summary

Core Web Vitals measure loading speed (LCP), interaction responsiveness (INP), and visual stability (CLS). Google uses field data from real users as a ranking signal. Monitor your scores through Search Console's Core Web Vitals report, supplement with PageSpeed Insights and Lighthouse for debugging, and consider real user monitoring for continuous visibility. Focus on passing the "good" thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1.