web-vitals
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
Other Web Vitals
Installation
You can install this library from npm by running:
npm install web-vitalsUsage
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) => voidCalculates 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) => voidCalculates 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) => voidCalculates 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) => voidCalculates 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) => voidCalculates 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(): ChromiumgetFCP(): ChromiumgetFID(): Chromium, Firefox, Safari, Internet Explorer (with polyfill, see below)getLCP(): ChromiumgetTTFB(): 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 buildTo build the code and watch for changes, run:
npm run watchRunning the tests
The web-vitals code is tested in real browsers using webdriver.io. Use the following command to run the tests:
npm testTo test any of the APIs manually, you can start the test server
npm run test:serverThen 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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent