Core Web Vitals

Core Web Vitals are Google’s three real-user performance metrics that quantify how a page feels in the field: LCP (Largest Contentful Paint) for loading speed, INP (Interaction to Next Paint) for responsiveness, and CLS (Cumulative Layout Shift) for visual stability. They have been a confirmed Google ranking signal since 2021 (Page Experience update), and INP officially replaced First Input Delay (FID) on March 12, 2024. This guide covers the 2026 thresholds, lab vs field measurement, the four main tools (PageSpeed Insights, CrUX, Search Console, web-vitals JS), how to send Core Web Vitals into GA4 events, the most common LCP / INP / CLS fixes, and what is rumored next.

What Are Core Web Vitals

Core Web Vitals are a small, opinionated subset of Google’s Web Vitals initiative — three metrics every site owner is expected to monitor. They are LCP, INP, and CLS, each targeting a distinct dimension of perceived page quality, each measured at the 75th percentile of real user visits over a rolling 28-day window. A page must pass all three to get the green “Good” classification in Search Console.

The metrics come from actual devices of actual visitors — not a clean lab machine — through the Chrome User Experience Report (CrUX) dataset. Lab tools like Lighthouse approximate the same metrics for debugging, but only field data drives ranking signals and Search Console verdicts. Internalize this distinction before tuning your site.

The Three Core Metrics: LCP, INP, CLS

Each Core Web Vital answers a different question about the visit:

1. LCP — Largest Contentful Paint: when does the largest visible element (hero image, hero heading, or video poster) finish rendering? Target ≤ 2.5 seconds at the 75th percentile. Measures loading.
2. INP — Interaction to Next Paint: across every click, tap, and keypress in the visit, what is the slowest delay between input and the next visual response? Target ≤ 200 milliseconds. Measures responsiveness.
3. CLS — Cumulative Layout Shift: a unitless score (0 = perfectly stable, 1 = a full-viewport shift) summing the largest unexpected shifts the user experiences. Target ≤ 0.1. Measures visual stability.

INP officially replaced FID in March 2024. INP captures the worst single interaction across the entire visit, while FID only measured the first interaction. Most sites that passed FID failed INP at first launch — INP is meaningfully harder, especially on JS-heavy pages with long-running event handlers.

How to Measure CWV: Lab vs Field Data

There are two fundamentally different ways to measure Core Web Vitals, and confusing them is the most common mistake in performance work:

• Field data (Real User Monitoring, RUM): samples from millions of actual Chrome users via CrUX. Reflects every device, every network, every cache state your visitors actually experience. This is what Google ranks on.
• Lab data (synthetic): a single test run on a controlled environment, typically Lighthouse simulating a mid-tier mobile device on slow 4G. Useful for debugging because it is reproducible, but it is not what the algorithm sees.

A page can pass lab and fail field if the real audience is on older devices, slow networks, or hits an uncached cold load. The reverse is also possible — a page can be marked “Needs Improvement” by Lighthouse but pass field thresholds if real visitors mostly land on warm caches. Always validate optimizations against field data after a 28-day rollout window before declaring victory.

CWV Tools: PageSpeed Insights, CrUX, Search Console

Five tools cover the full Core Web Vitals workflow. Each has a different role:

For routine monitoring, Search Console is the source of truth — it is the same data Google uses for ranking. PageSpeed Insights is faster for spot-checking a single URL and gives you Lighthouse diagnostics in the same view. The web-vitals library is the only way to slice CWV by your own segments (logged-in users, traffic source, device class) inside GA4.

CWV Thresholds: Good / Needs Improvement / Poor

The current 2026 thresholds, unchanged since the INP migration in March 2024:

The p75 detail matters: Google takes the slowest 25% of your visitors and uses the cutoff between the 25th-slowest percentile and the rest as the reported number. A page where 74% of visits load in 1.5 s and 26% load in 6 s reports an LCP near 6 s — not the median. Tail performance on slow devices and bad networks dominates the rating.

CWV in GA4 + Web Vitals JS Library

GA4 does not collect Core Web Vitals out of the box. Send them yourself as custom events using Google’s official web-vitals npm package. The library batches and reports metrics to your callback as the visit progresses:

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

function sendToGA4(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.delta * 1000 : metric.delta),
    metric_id: metric.id,
    metric_value: metric.value,
    metric_rating: metric.rating,   // 'good' | 'needs-improvement' | 'poor'
    non_interaction: true
  });
}

onLCP(sendToGA4);
onINP(sendToGA4);
onCLS(sendToGA4);

Once these events flow into GA4 you can build Explorations slicing CWV by data stream, page path, traffic source, or device. For a richer pipeline send the same events via Measurement Protocol server-side and join them against backend logs. If you use tag management via GTM, push the metric to the dataLayer and fire a GA4 event tag — same outcome, different plumbing. Validate the events fire with DebugView before relying on them.

Common CWV Issues and Fixes

Three short playbooks, ordered by impact-per-effort:

1. LCP — image and server response. Identify the LCP element in DevTools (it is almost always the hero image or hero heading). Compress and serve in WebP/AVIF, set explicit width and height, add fetchpriority="high", preload it from the head, and put your origin behind a CDN. On WordPress sites the single biggest LCP win is moving the LCP image out of a lazy-loaded carousel.
2. INP — main-thread cleanup. Audit long tasks (≥ 50 ms) in the Performance panel. Break heavy event handlers with scheduler.yield() or setTimeout(0), defer third-party scripts (especially chat widgets and ad libraries), and move CPU-bound work to a Web Worker. Audit your tag manager container for tags that fire on every interaction.
3. CLS — reserve space. Set explicit dimensions on every <img>, <video>, and <iframe>. Reserve a min-height for ad slots, dynamically injected banners, and cookie consent widgets. Use font-display: optional or preload the web font to avoid late swaps. Never insert content above existing content after the page has rendered — append below the viewport instead.

Analytics tags themselves can hurt INP. Multiple synchronous trackers add main-thread work on every click. Load them async, batch their dispatch, and consider sending heavy events through Measurement Protocol server-side instead of from the browser.

CWV and SEO: Ranking Factor since 2021

Google rolled Core Web Vitals into rankings as part of the Page Experience update in May 2021 (mobile) and February 2022 (desktop). The official Google line has been consistent since: CWV is one of many ranking signals, used as a tiebreaker between pages of comparable content quality. Pages with poor CWV are not penalized in isolation, but they lose ground in competitive SERPs where multiple pages address the same intent.

In practice, fixing CWV most often improves analytics quality before rankings — your tag firing stabilizes, pageview count rises, and mobile screen views become more reliable. Ranking gains follow 4-8 weeks after the field-data window catches up.

CWV by Device: Mobile vs Desktop differences

Search Console reports Core Web Vitals separately for mobile and desktop, and the gap is often large. Mobile is harder to pass: weaker CPUs, slower networks, smaller viewports that surface different LCP elements, and apps competing for resources. A typical pattern from audits:

• Desktop LCP: 2.1 s (Good) — same page, mobile LCP: 4.3 s (Poor)
• Desktop INP: 120 ms (Good) — same page, mobile INP: 280 ms (Needs Improvement)
• CLS is usually similar across devices, but ad-heavy mobile layouts are worse

Google uses mobile Core Web Vitals as the primary ranking signal under mobile-first indexing. Optimize mobile first; desktop usually passes automatically when mobile does. Test on a mid-tier Android device — iPhone Safari hides problems that Chrome on a $200 Android exposes immediately.

Future of CWV (rumored next metric, INP migration, ROI of optimization)

The Chrome team has signalled three trajectories worth watching:

• A scroll-jank metric is the most likely fourth Core Web Vital — the team has incubated a responsiveness-during-scroll measurement for years.
• INP threshold tightening — the 200 ms target was set conservatively. Expect a tightening to 150 ms or lower as the ecosystem catches up.
• LCP sub-parts — TTFB, resource load delay, and render delay are being exposed as diagnostic sub-metrics.

The ROI of CWV optimization shows up most reliably in conversion lift, not ranking lift. Web.dev case studies report 5-25% conversion lift per second of LCP improvement on transactional pages. Run the experiment on your own funnel using a conversion event as the dependent variable and LCP rating as the independent variable in GA4 Explorations.

Frequently Asked Questions

Related Terms

• Event — the GA4 unit you use to send Core Web Vitals into reports
• Custom Events — how the web-vitals library reaches GA4
• Data Stream — the GA4 stream that receives the CWV events
• Data Layer — the GTM bridge for Core Web Vitals values
• Tag Management — GTM implementation pattern for web-vitals
• Container — the GTM container that holds the CWV tag
• Measurement Protocol — server-side delivery for heavy CWV pipelines
• DebugView — verifying that CWV events fire correctly
• BigQuery — raw CrUX dataset for cross-origin analysis
• Pageview — the metric most affected by poor LCP
• Screen View — the mobile-app analogue impacted by responsiveness