Web Vitals Monitor

Understanding Core Web Vitals

Core Web Vitals are three metrics — LCP, INP, and CLS — that Google uses to measure real user experience as a Page Experience ranking signal. They were first introduced in 2020 and became a ranking factor in May 2021. INP replaced FID as the interactivity metric in March 2024, making the measurement more comprehensive. Google collects field data (from real Chrome users) via the Chrome User Experience Report (CrUX) and surfaces it in Search Console, PageSpeed Insights, and Lighthouse.

The key distinction between lab and field data matters for Core Web Vitals. Lab data (from Lighthouse or WebPageTest) runs a simulated test under controlled conditions. Field data reflects actual user experiences across your full traffic distribution, including slow devices, congested networks, and unusual usage patterns. Google's ranking signal uses field data — specifically the 75th percentile of all page loads — so a page that scores well in Lighthouse may still have poor Core Web Vitals in Search Console if real-world conditions differ significantly.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible content element to render in the viewport. In practice, this is almost always the hero image, a large banner, or the first large block of text. Google's Good threshold is 2.5 seconds or less at the 75th percentile of page loads.

The most impactful LCP optimizations are: preloading the LCP image with <link rel="preload" as="image" fetchpriority="high">, converting hero images to WebP or AVIF (typically 30–50% smaller than JPEG), ensuring the LCP image is not lazy-loaded (never put loading="lazy" on the first visible image), improving server response time (TTFB contributes directly to LCP), and eliminating render-blocking scripts that delay the browser from painting.

A common LCP trap is using CSS background images for the hero. Background images are not discoverable by the browser's preload scanner, meaning they start downloading later than <img> elements. Switching from background-image to an <img> tag with proper sizing can reduce LCP by 0.5–1.5 seconds.

INP: Interaction to Next Paint

INP (which replaced FID in March 2024) measures the full duration of every user interaction — click, keypress, or tap — throughout the page lifecycle, and reports the worst-case latency. Unlike FID, which only measured the input delay before the browser began processing the first interaction, INP measures the complete input delay, processing time, and presentation delay. The Good threshold is 200ms or less.

High INP is almost always caused by long tasks on the main thread. The main thread can only execute one task at a time; if a JavaScript function takes 300ms to run after a user click, the browser cannot paint an update until that function completes. The fix involves breaking long tasks into smaller chunks using scheduler.yield() (or the older setTimeout(fn, 0) pattern), offloading heavy computation to Web Workers, and avoiding synchronous DOM queries inside event handlers. Framework-heavy pages (React, Vue, Angular) can also suffer from expensive re-render cascades — profiling with Chrome DevTools' Interactions track is the fastest way to pinpoint the culprit.

CLS: Cumulative Layout Shift

CLS measures unexpected visual movement of page content during loading. Every time an element moves without a user action, it scores a layout shift. The CLS score is the sum of all individual shift scores, where each individual shift score = impact fraction × distance fraction. The Good threshold is 0.1 or less.

The four most common CLS causes are: images without explicit width and height attributes (the browser reserves no space before the image loads, causing a reflow), web fonts using font-display: auto or block (causing a flash of invisible text followed by a reflow when the font loads), dynamically injected banners or ads above content, and iframes or embeds without reserved height. Setting explicit dimensions on images and using font-display: optional or swap with size-adjust to match fallback metrics resolves the majority of CLS issues.

FID: First Input Delay (Legacy)

FID measured the delay between a user's first interaction and the browser's response. It was replaced by INP in March 2024 because it only captured a single event and ignored interaction duration. FID is still reported in historical Search Console data and some RUM tools, so it remains useful for trend analysis. The Good threshold is 100ms or less. FID is primarily improved by reducing JavaScript execution time during page load, the same techniques that improve INP.

How to Measure Real-World Core Web Vitals

To get field data matching what Google uses for ranking, use: Google Search Console's Core Web Vitals report (shows your actual indexed pages with CrUX data), PageSpeed Insights (shows both lab and field data for any URL), or install the web-vitals JavaScript library to capture values from real users and send them to your analytics. The web-vitals library is the most accurate way to measure INP specifically, as INP is event-driven and varies significantly between sessions.

Use this tool to monitor your progress as you implement fixes. Log a reading before and after each optimization sprint to quantify the improvement. When your 75th-percentile values hit the Good thresholds for all three core metrics (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1), your page qualifies for the Good page experience classification in Google Search.