Web Vitals

Web Vitals is a Google initiative to provide unified guidance for web page quality signals that are essential to delivering a great user experience on the web. It aims to simplify the wide variety of available performance-measuring tools, and help site owners focus on the metrics that matter most, the Core Web Vitals.

Core Web Vitals

Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and are surfaced across all Google tools. Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.

The metrics that make up Core Web Vitals will evolve over time. The current set focuses on three aspects of the user experience: loading, interactivity, and visual stability. It includes the following metrics:

Largest Contentful Paint threshold recommendations Interaction to Next Paint threshold recommendations Cumulative Layout Shift threshold recommendations
  • Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP must occur within 2.5 seconds of when the page first starts loading.
  • Interaction to Next Paint (INP): measures interactivity. To provide a good user experience, pages must have a INP of 200 milliseconds or less.
  • Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, must should maintain a CLS of 0.1. or less.

For each of these metrics, to ensure you're hitting the recommended target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

Tools that assess Core Web Vitals compliance should consider a page compliant if it meets the recommended targets at the 75th percentile for each of these three metrics.


Metrics on the Core Web Vitals track go through a lifecycle consisting of three phases: experimental, pending, and stable.

The three lifecycle phases of Core Web Vitals metrics, visualized as a series of three chevrons. From left to right, the phases are Experimental, Pending, and Stable.
The stages of the Core Web Vitals lifecycle.

Each phase is designed to signal to developers how they should think about each metric:

  • Experimental metrics are prospective Core Web Vitals that may still be undergoing significant changes depending on testing and community feedback.
  • Pending metrics are future Core Web Vitals that have passed the testing and feedback stage and have a well-defined timeline to becoming stable.
  • Stable metrics are the current set of Core Web Vitals that Chrome considers essential for great user experiences.

The Core Web Vitals are at the following lifecycle stages:


When a metric is initially developed and enters the ecosystem, it is considered an experimental metric.

The purpose of the experimental phase is to assess a metric's fitness, first by exploring the problem to be solved, and possibly iterating on what previous metrics might have failed to address. For example, INP was initially introduced as an experimental metric in 2022 to address the web's runtime performance issues more comprehensively than First Input Delay (FID).

The experimental phase of Core Web Vitals lifecycle is also intended to give flexibility in a metric's development by identifying bugs and even exploring changes to its initial definition. It's also the phase in which community feedback is most important.


When the Chrome team determines that an experimental metric has received sufficient feedback and proven its efficacy, it becomes a pending metric. For example, INP was promoted in 2023 from experimental to pending status with the intent to eventually retire FID.

Pending metrics are held in this phase for a minimum of six months to give the ecosystem time to adapt. Community feedback remains an important aspect of this phase, as more developers begin to use the metric.


When a Core Web Vital candidate metric is finalized, it becomes a stable metric. This is when the metric can become a Core Web Vital.

Stable metrics are actively supported, and can be subject to bug fixes and definition changes. Stable Core Web Vitals metrics won't change more than once per year. Any change to a Core Web Vital will be clearly communicated in the metric's official documentation, as well as in the metric's changelog. Core Web Vitals are also included in any assessments.

Stable metrics aren't necessarily permanent. A stable metric can be retired and replaced by another metric that addresses the problem area more effectively. This is exactly what happened to FID as INP became a stable Core Web Vital metric in 2024.

Measure and report Core Web Vitals

Google believes that the Core Web Vitals are critical to all web experiences. As a result, it is committed to surfacing these metrics in all of its popular tools. The following sections details which tools support the Core Web Vitals.

Field tools to measure Core Web Vitals

The Chrome User Experience Report collects anonymized, real user measurement data for each Core Web Vital. This data allows site owners to quickly assess their performance without requiring them to manually set up analytics for their pages, and powers tools like PageSpeed Insights and Search Console's Core Web Vitals report.

Chrome User Experience Report
PageSpeed Insights
Search Console (Core Web Vitals report)

The data provided by Chrome User Experience Report offers a quick way to assess site performance, but it doesn't provide the detailed, per-pageview telemetry that's often necessary to accurately diagnose, monitor, and quickly react to regressions. As a result, we strongly recommend that sites set up their own real-user monitoring.

Measure Core Web Vitals in JavaScript

Each of the Core Web Vitals can be measured in JavaScript using standard web APIs.

The easiest way to measure all the Core Web Vitals is to use the web-vitals JavaScript library, a small, production-ready API wrapper that measures each metric in a way that accurately matches how the Google tools report them.

With the web-vitals library, measuring each metric is as simple as calling a single function (see the documentation for complete usage and API details):

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

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
    fetch('/analytics', {body, method: 'POST', keepalive: true});


After you configure your site to use the web-vitals library to measure and send your Core Web Vitals data to an analytics endpoint, the next step is to aggregate and report on that data to see if your pages are meeting the recommended thresholds for at least 75% of page visits.

While some analytics providers have built-in support for Core Web Vitals metrics, even those that don't should include basic custom metric features that allow you to measure Core Web Vitals in their tool.

One example of this is the Web Vitals Report, which allows site owners to measure their Core Web Vitals using Google Analytics. For guidance on measuring Core Web Vitals using other analytics tools, see Best practices for measuring Web Vitals in the field.

You can also report on each of the Core Web Vitals without writing any code using the Web Vitals Chrome Extension. This extension uses the web-vitals library to measure each of these metrics and display them to users as they browse the web.

This extension can be helpful in understanding the performance of your own sites, your competitor's sites, and the web at large.

Web Vitals Extension

Developers who prefer to measure these metrics directly using the underlying web APIs can instead use these metric guides for implementation details:

For additional guidance on measuring these metrics using popular analytics services or your own in-house analytics tools, see Best practices for measuring Web Vitals in the field.

Lab tools to measure Core Web Vitals

While all of the Core Web Vitals are, first and foremost, field metrics, many of them are also measurable in the lab.

Lab measurement is the best way to test the performance of features during development. It's also the best way to catch performance regressions before they happen.

The following tools can be used to measure the Core Web Vitals in a lab environment:

Chrome DevTools (use TBT instead)
Lighthouse (use TBT instead)

Tools like Lighthouse that load pages in a simulated environment without a user can't measure INP because they don't have user input. However, the Total Blocking Time (TBT) metric is lab-measurable and is an acceptable proxy for INP issues that might be due to contention on the main thread during startup. Performance optimizations that improve TBT in the lab should improve INP in the field. For more guidance, see Recommendations for improving your scores.

Although lab measurement is an essential part of delivering great experiences, it is not a substitute for field measurement. A site's performance can vary dramatically based on a user's device capabilities, their network conditions, what other processes may be running on the device, and how they're interacting with the page. In fact, each of the Core Web Vitals metrics can have its score affected by user interaction. Only field measurement can accurately capture the complete picture.

Recommendations for improving your scores

The following guides offer specific recommendations for how to optimize your pages for each of the Core Web Vitals:

Other Web Vitals

Although the Core Web Vitals are the critical metrics for understanding and delivering a great user experience, there are also other vital metrics.

These other Web Vitals often serve as proxy or supplemental metrics for the Core Web Vitals, to help capture a larger part of the experience or aid in diagnosing a specific issue.

For example, Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and both are useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).

Similarly, a metric like Total Blocking Time (TBT) is a vital lab metric for catching and diagnosing potential interactivity issues that can impact INP. However, it isn't part of the Core Web Vitals set because it's not field-measurable, and doesn't reflect a user-centric outcome.

Changes to Web Vitals

Web Vitals and Core Web Vitals represent the best available signals developers have today to measure quality of experience across the web, but these signals aren't perfect and future improvements or additions should be expected.

The Core Web Vitals are relevant to all web pages and featured across relevant Google tools. Because changes to these metrics have wide-reaching impact, developers should expect the definitions and thresholds of the Core Web Vitals to be stable, as well as prior notice and a predictable schedule for updates.

The other Web Vitals are often context or tool specific, and can be more experimental than the Core Web Vitals. As such, their definitions and thresholds might change with greater frequency.

For all Web Vitals, changes are documented in this public changelog.