web-vitals

What is web-vitals?

The web-vitals npm package is a library that provides a set of functions to measure the web vitals, which are metrics that Google considers important for a website's user experience. These metrics include Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS), among others. The package helps developers capture and report on these metrics to improve the performance of their web applications.

What are web-vitals's main functionalities?

Measure Largest Contentful Paint (LCP)

This feature allows you to measure the Largest Contentful Paint (LCP), which reports the render time of the largest image or text block visible within the viewport. The code sample demonstrates how to import the getLCP function from the web-vitals package and use it to log the LCP metric to the console.

import { getLCP } from 'web-vitals';

getLCP(console.log);

Measure First Input Delay (FID)

This feature measures the First Input Delay (FID), which captures the time from when a user first interacts with your site to the time when the browser is actually able to respond to that interaction. The code sample shows how to use the getFID function to log the FID metric.

import { getFID } from 'web-vitals';

getFID(console.log);

Measure Cumulative Layout Shift (CLS)

This feature measures the Cumulative Layout Shift (CLS), which quantifies how often users experience unexpected layout shifts. The code sample illustrates how to use the getCLS function to log the CLS metric.

import { getCLS } from 'web-vitals';

getCLS(console.log);

Other packages similar to web-vitals

lighthouse

Lighthouse is an open-source, automated tool for improving the quality of web pages. It has audits for performance, accessibility, progressive web apps, and more. While web-vitals focuses specifically on performance metrics, Lighthouse provides a broader range of checks and can be used for comprehensive reporting and auditing.

pagespeed-insights

PageSpeed Insights is a tool that incorporates the Lighthouse performance metrics and provides insights on how to improve web page speed. It is similar to web-vitals in that it measures core web vitals, but it also offers suggestions for optimizations and can be used for both mobile and desktop performance analysis.

perfume.js

Perfume.js is a JavaScript library for web performance monitoring that includes Google's web vitals. It offers additional features like analytics integration, custom metrics, and automatic vitals tracking. Compared to web-vitals, Perfume.js provides a more extensive set of tools for performance monitoring and analytics.

README

web-vitals

• Overview
• Installation
• Usage
  • Log the results to the console
  • Report the value on every change
  • Report only the delta of changes
  • Send the results to an analytics endpoint
  • Send the results to Google Analytics
• API
  • Types
  • Functions
• Development
• Browser Support

Overview

The web-vitals library is a tiny (~1K), modular library for measuring all the Web Vitals metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. Chrome User Experience Report, Page Speed Insights, Search Console's Speed Report).

The library supports all of the Core Web Vitals as well as all of the other Web Vitals that can be measured in the field:

Core Web Vitals

• Cumulative Layout Shift (CLS)
• First Input Delay (FID)
• Largest Contentful Paint (LCP)

Other Web Vitals

• First Contentful Paint (FCP)
• Time to First Byte (TTFB)

Installation

You can install this library from npm by running:

npm install web-vitals

Usage

Each of the Web Vitals metrics are exposed as a single function that takes an onReport callback. This callback will fire any time either:

• The final value of the metric has been determined.
• The current metric value needs to be reported right away (due to the page being unloaded or backgrounded).

Log the results to the console

The following example logs the result of each metric to the console once its value is ready to report.

import {getCLS, getFID, getLCP} from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Note: some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try switching tabs and then switching back.

Report the value on every change

In most cases, you only want to call onReport when the metric is ready. However, for metrics like LCP and CLS (where the value may change over time) you can pass an optional, second argument (reportAllChanges). If true then onReport will be called any time the value of the metric changes, or once the final value has been determined.

This could be useful if, for example, you want to report the current LCP candidate as the page is loading, or you want to report layout shifts (and the current CLS value) as users are interacting with the page. In general, though, using reportAllChanges is not needed (or recommended).

import {getCLS, getFID, getLCP} from 'web-vitals';

getCLS(console.log, true);
getFID(console.log); // Does not take a `reportAllChanges` param.
getLCP(console.log, true);

Note: when using the reportAllChanges option, pay attention to the isFinal property of the reported metric, which will indicate whether or not the value might change in the future. See the API reference below for more details.

Report only the delta of changes

Some analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same id).

Other analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.

The following example shows how to use the id and delta properties:

import {getCLS, getFID, getLCP} from 'web-vitals';

function logDelta({name, id, delta}) {
  console.log(`${name} matching ID ${id} changed by ${delta}`);
}

getCLS(logDelta);
getFID(logDelta);
getLCP(logDelta);

Note: the first time the onReport function is called, its value and delta properties will be the same.

Send the results to an analytics endpoint

The following example measures each of the Core Web Vitals metrics and reports them to a hypothetical /analytics endpoint, as soon as each is ready to be sent.

The sendToAnalytics() function uses the navigator.sendBeacon() method (if available), but falls back to the fetch() API when not.

import {getCLS, getFID, getLCP} 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});
}

getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

Send the results to Google Analytics

Google Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric id) on every metric instance that you send to Google Analytics, including that dimension in a custom report will allow you to construct a distribution manually.

Using the Google Analytics Reporting API and a tool like Data Studio (or your own visualization library), you can create dashboards with histograms reporting quantile data (the 75th percentile is recommended) for all of the Web Vitals metrics.

The following code examples show how to send your metrics to Google Analytics in order to enable reporting quantile data:

Using analytics.js

import {getCLS, getFID, getLCP} from 'web-vitals';

function sendToGoogleAnalytics({name, delta, id}) {
  // Assumes the global `ga()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/analyticsjs
  ga('send', 'event', {
    eventCategory: 'Web Vitals',
    eventAction: name,
    // Google Analytics metrics must be integers, so the value is rounded.
    // For CLS the value is first multiplied by 1000 for greater precision
    // (note: increase the multiplier for greater precision if needed).
    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),
    // The `id` value will be unique to the current page load. When sending
    // multiple values from the same page (e.g. for CLS), Google Analytics can
    // compute a total by grouping on this ID (note: requires `eventLabel` to
    // be a dimension in your report).
    eventLabel: id,
    // Use a non-interaction event to avoid affecting bounce rate.
    nonInteraction: true,
  });
}

getCLS(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getLCP(sendToGoogleAnalytics);

Using gtag.js

import {getCLS, getFID, getLCP} from 'web-vitals';

function sendToGoogleAnalytics({name, delta, id}) {
  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/gtagjs
  gtag('event', name, {
    event_category: 'Web Vitals',
    // Google Analytics metrics must be integers, so the value is rounded.
    // For CLS the value is first multiplied by 1000 for greater precision
    // (note: increase the multiplier for greater precision if needed).
    value: Math.round(name === 'CLS' ? delta * 1000 : delta),
    // The `id` value will be unique to the current page load. When sending
    // multiple values from the same page (e.g. for CLS), Google Analytics can
    // compute a total by grouping on this ID (note: requires `eventLabel` to
    // be a dimension in your report).
    event_label: id,
    // Use a non-interaction event to avoid affecting bounce rate.
    non_interaction: true,
  });
}

getCLS(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getLCP(sendToGoogleAnalytics);

API

Types:

Metric

interface Metric {
  // The name of the metric (in acronym form).
  name: 'CLS' | 'FCP' | 'FID' | 'LCP' | 'TTFB';

  // The current value of the metric.
  value: number;

  // The delta between the current value and the last-reported value.
  // On the first report, `delta` and `value` will always be the same.
  delta: number;

  // A unique ID representing this particular metric that's specific to the
  // current page. This ID can be used by an analytics tool to dedupe
  // multiple values sent for the same metric, or to group multiple deltas
  // together and calculate a total.
  id: string;

  // `false` if the value of the metric may change in the future,
  // for the current page.
  isFinal: boolean;

  // Any performance entries used in the metric value calculation.
  // Note, entries will be added to the array as the value changes.
  entries: PerformanceEntry[];
}

ReportHandler

interface ReportHandler {
  (metric: Metric): void;
}

Functions:

getCLS()

type getCLS = (onReport: ReportHandler, reportAllChanges?: boolean) => void

Calculates the CLS value for the current page and calls the onReport function once the value is ready to be reported, along with all layout-shift performance entries that were used in the metric value calculation. The reported value is a double (corresponding to a layout shift value).

If the reportAllChanges param is true, the onReport function will be called any time a new layout-shift performance entry is dispatched, or once the final value of the metric has been determined.

Important: unlike other metrics, CLS continues to monitor changes for the entire lifespan of the page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often will not fire additional callbacks once the user has backgrounded a page, onReport is always called when the page's visibility state changes to hidden. As a result, the onReport function might be called multiple times during the same page load (see Reporting only the delta of changes for how to manage this).

getFCP()

type getFCP = (onReport: ReportHandler) => void

Calculates the FCP value for the current page and calls the onReport function once the value is ready, along with the relevant paint performance entry used to determine the value. The reported value is a DOMHighResTimeStamp.

getFID()

type getFID = (onReport: ReportHandler) => void

Calculates the FID value for the current page and calls the onReport function once the value is ready, along with the relevant first-input performance entry used to determine the value (and optionally the input event if using the FID polyfill). The reported value is a DOMHighResTimeStamp.

Important: since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads.

getLCP()

type getLCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void

Calculates the LCP value for the current page and calls the onReport function once the value is ready (along with the relevant largest-contentful-paint performance entries used to determine the value). The reported value is a DOMHighResTimeStamp.

If the reportAllChanges param is true, the onReport function will be called any time a new largest-contentful-paint performance entry is dispatched, or once the final value of the metric has been determined.

getTTFB()

type getTTFB = (onReport: ReportHandler) => void

Calculates the TTFB value for the current page and calls the onReport function once the page has loaded, along with the relevant navigation performance entry used to determine the value. The reported value is a DOMHighResTimeStamp.

Note, this function waits until after the page is loaded to call onReport in order to ensure all properties of the navigation entry are populated. This is useful if you want to report on other metrics exposed by the Navigation Timing API.

For example, the TTFB metric starts from the page's time origin, which means it includes time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and just captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:

import {getTTFB} from 'web-vitals';

getTTFB((metric) => {
  // Calculate the request time by subtracting from TTFB
  // everything that happened prior to the request starting.
  const requestTime = metric.value - metric.entries[0].requestStart;
  console.log('Request time:', requestTime);
});

Note: browsers that do not support navigation entries will fall back to using performance.timing (with the timestamps converted from epoch time to DOMHighResTimeStamp). This ensures code referencing these values (like in the example above) will work the same in all browsers.

Browser Support

This code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9 (when transpiled to ES5). However, some of the APIs required to capture these metrics are only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).

Browser support for each function is as follows:

• getCLS(): Chromium
• getFCP(): Chromium
• getFID(): Chromium, Firefox, Safari, Internet Explorer (with polyfill, see below)
• getLCP(): Chromium
• getTTFB(): Chromium, Firefox, Safari, Internet Explorer

FID Polyfill

The getFID() function will work in all browsers if the page has included the FID polyfill.

Browsers that support the native Event Timing API will use that and report the metric value from the first-input performance entry.

Browsers that do not support the native Event Timing API will use the value reported by the polyfill, and the entries array will contain a plain-object version of the native PerformanceEventTiming object.

Note: the duration and processingEnd properties of the PerformanceEventTiming will not be present, as they're not exposed by the polyfill.

Development

Building the code

The web-vitals source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.

npm run build

To build the code and watch for changes, run:

npm run watch

Running the tests

The web-vitals code is tested in real browsers using webdriver.io. Use the following command to run the tests:

npm test

To test any of the APIs manually, you can start the test server

npm run test:server

Then navigate to http://localhost:9090/test/<view>, where <view> is the basename of one the templates under /test/views/.

You'll likely want to combine this with npm run watch to ensure any changes you make are transpiled and rebuilt.

License

Apache 2.0

Changelog

v0.2.1 (2020-05-06)

• Ensure all modules are pure modules (#23)
• Ensure proper TypeScript exports and config (#22)