The The library supports all of the
Core Web Vitals as well as a number of other metrics that are useful in diagnosing real-user performance issues. You can install this library from npm by running: Note: If you're not using npm, you can still load There are a few
different builds of the For details on the difference between the builds, see which build is right for you. 1. The "standard" build To load the "standard" build, import modules from the Note: in version 2, these functions were named 2. The "attribution" build Measuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't good, the next step is to understand why they're not good and work to improve them. The "attribution" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix. The "attribution" build is slightly larger than the "standard" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features. To load the "attribution" build, change any - import {onLCP, onFID, onCLS} from 'web-vitals'; + import {onLCP, onFID, onCLS} from 'web-vitals/attribution'; Usage for each of the imported function is identical to the standard build, but when
importing from the attribution build, the See Send attribution data for usage examples, and the
3. The "base+polyfill" build ⚠️ Warning ⚠️ the "base+polyfill" build is deprecated. See #238 for details. Loading the "base+polyfill" build is a two-step process: First, in your application code, import the "base" build rather than the "standard" build. To do this, change any - import {onLCP, onFID, onCLS} from 'web-vitals'; + import {onLCP, onFID, onCLS} from 'web-vitals/base'; Then, inline the code from <!DOCTYPE html> <html> <head> <script> // Inline code from `dist/polyfill.js` here </script> </head> <body> ... </body> </html> It's important that the code is inlined directly into the HTML. *Do not link to an external script file, as that will negatively affect performance: <!-- GOOD --> <script> // Inline code from `dist/polyfill.js` here </script> <!-- BAD! DO NOT DO! --> <script src="/path/to/polyfill.js"></script> Also note that the code must go in the Tip: while it's certainly possible to inline the code in From a CDNThe recommended way to use the The following examples show how to load Important! The unpkg.com CDN is shown here for example purposes only. Load the "standard" build (using a module script) <!-- Append the `?module` param to load the module version of `web-vitals` --> <script type="module"> import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module'; onCLS(console.log); onFID(console.log); onLCP(console.log); </script> Load the "standard" build (using a classic script) <script> (function() { var script = document.createElement('script'); script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js'; script.onload = function() { // When loading `web-vitals` using a classic script, all the public // methods can be found on the `webVitals` global namespace. webVitals.onCLS(console.log); webVitals.onFID(console.log); webVitals.onLCP(console.log); } document.head.appendChild(script); }()) </script> Load the "attribution" build (using a module script) <!-- Append the `?module` param to load the module version of `web-vitals` --> <script type="module"> import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module'; onCLS(console.log); onFID(console.log); onLCP(console.log); </script> Load the "attribution" build (using a classic script) <script> (function() { var script = document.createElement('script'); script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js'; script.onload = function() { // When loading `web-vitals` using a classic script, all the public // methods can be found on the `webVitals` global namespace. webVitals.onCLS(console.log); webVitals.onFID(console.log); webVitals.onLCP(console.log); } document.head.appendChild(script); }()) </script> UsageBasic usageEach of
the Web Vitals metrics is exposed as a single function that takes a The following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report. (The examples below import the "standard" build, but they will work with the "attribution" build as well.) import {onCLS, onFID, onLCP} from 'web-vitals'; onCLS(console.log); onFID(console.log); onLCP(console.log); Note that 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 reloading the page (with preserve log enabled) or switching tabs and then switching back. Also, in some cases a metric callback may never be called:
In other cases, a metric callback may be called more than once:
Warning: do not call any of the Web Vitals functions (e.g. Report the value on every changeIn most cases, you only want the This can be useful when debugging, but in general using import {onCLS} from 'web-vitals'; // Logs CLS as the value changes. onCLS(console.log, {reportAllChanges: true}); Report only the delta of changesSome 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 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 import {onCLS, onFID, onLCP} from 'web-vitals'; function logDelta({name, id, delta}) { console.log(`${name} matching ID ${id} changed by ${delta}`); } onCLS(logDelta); onFID(logDelta); onLCP(logDelta); Note: the first time the In addition to using the Send the results to an analytics endpointThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical The import {onCLS, onFID, onLCP} from 'web-vitals'; function sendToAnalytics(metric) { // Replace with whatever serialization method you prefer. // Note: JSON.stringify will likely include more data than you need. 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}); } onCLS(sendToAnalytics); onFID(sendToAnalytics); onLCP(sendToAnalytics); Send the results to Google AnalyticsGoogle 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 As an example of this, the Web Vitals Report is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics. In order to use the Web Vitals Report (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below: Using |
Filename (all within dist/* )
| Export | Description |
web-vitals.js
| pkg.module
| An ES module bundle of all metric functions, without any attribution features. This is the "standard" build and is the simplest way to consume this library out of the box. |
web-vitals.umd.cjs
| pgk.main
| A UMD version of the web-vitals.js bundle (exposed on the window.webVitals.* namespace).
|
web-vitals.iife.js
| -- | An IIFE version of the web-vitals.js bundle (exposed on the window.webVitals.* namespace).
|
web-vitals.attribution.js
| -- | An ES module version of all metric functions that includes attribution features. |
web-vitals.attribution.umd.cjs
| -- | A UMD version of the web-vitals.attribution.js build (exposed on the window.webVitals.* namespace).
|
web-vitals.attribution.iife.js
| -- | An IIFE version of the web-vitals.attribution.js build (exposed on the window.webVitals.* namespace).
|
web-vitals.base.js
| -- | This build has been deprecated. An ES module bundle containing just the "base" part of the "base+polyfill" version. Use this bundle if (and only if) you've also added thepolyfill.js script to the <head> of your pages. See how to use the polyfill for more details.
|
web-vitals.base.umd.cjs
| -- | This build has been deprecated. A UMD version of the |
web-vitals.base.iife.js
| -- | This build has been deprecated. An IIFE version of the |
polyfill.js
| -- | This build has been deprecated. The "polyfill" part of the "base+polyfill" version. This script should be used with either |
Which build is right for you?
Most developers will generally want to use "standard" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.
However, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the "attribution" build.
For guidance on how to collect and use real-user data to debug performance issues, see Debug performance in the field.
How the polyfill works
⚠️ Warning ⚠️ the "base+polyfill" build is deprecated. See #238 for details.
The polyfill.js
script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the
accuracy of CLS, FCP, LCP, and FID). It also polyfills the Navigation Timing API Level 2 in browsers that only support the original (now deprecated) Navigation Timing API.
In order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any
content to the screen. This is why it needs to be added to the <head>
of the document.
The "standard" build of the web-vitals
library includes some of the same logic found in polyfill.js
. To avoid duplicating that code when using the "base+polyfill" build, the web-vitals.base.js
bundle does not include any polyfill logic, instead it coordinates with the code in polyfill.js
, which is why the two scripts must be used together.
API
Types:
Metric
interface Metric { /** * The name of the metric (in acronym form). */ name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB'; /** * The current value of the metric. */ value: number; /** * The rating as to whether the metric value is within the "good", * "needs improvement", or "poor" thresholds of the metric. */ rating: 'good' | 'needs-improvement' | 'poor'; /** * 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 instance. This ID can * be used by an analytics tool to dedupe multiple values sent for the same * metric instance, or to group multiple deltas together and calculate a * total. It can also be used to differentiate multiple different metric * instances sent from the same page, which can happen if the page is * restored from the back/forward cache (in that case new metrics object * get created). */ id: string; /** * Any performance entries relevant to the metric value calculation. * The array may also be empty if the metric value was not based on any * entries (e.g. a CLS value of 0 given no layout shifts). */ entries: (PerformanceEntry | LayoutShift | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[]; /** * The type of navigation. * * This will be the value returned by the Navigation Timing API (or * `undefined` if the browser doesn't support that API), with the following * exceptions: * - 'back-forward-cache': for pages that are restored from the bfcache. * - 'prerender': for pages that were prerendered. * - 'restore': for pages that were discarded by the browser and then * restored by the user. */ navigationType: 'navigate' | 'reload' | 'back-forward' | 'back-forward-cache' | 'prerender' | 'restore'; }
Metric-specific subclasses:
CLSMetric
FCPMetric
FIDMetric
INPMetric
LCPMetric
TTFBMetric
MetricWithAttribution
See the attribution build section for details on how to use this feature.
interface MetricWithAttribution extends Metric { /** * An object containing potentially-helpful debugging information that * can be sent along with the metric value for the current page visit in * order to help identify issues happening to real-users in the field. */ attribution: {[key: string]: unknown}; }
Metric-specific subclasses:
CLSMetricWithAttribution
FCPMetricWithAttribution
FIDMetricWithAttribution
INPMetricWithAttribution
LCPMetricWithAttribution
TTFBMetricWithAttribution
ReportCallback
interface ReportCallback { (metric: Metric): void; }
Metric-specific subclasses:
CLSReportCallback
FCPReportCallback
FIDReportCallback
INPReportCallback
LCPReportCallback
TTFBReportCallback
ReportOpts
interface ReportOpts { reportAllChanges?: boolean; durationThreshold?: number; }
LoadState
The LoadState
type is used in several of the metric attribution objects.
/** * The loading state of the document. Note: this value is similar to * `document.readyState` but it subdivides the "interactive" state into the * time before and after the DOMContentLoaded event fires. * * State descriptions: * - `loading`: the initial document response has not yet been fully downloaded * and parsed. This is equivalent to the corresponding `readyState` value. * - `dom-interactive`: the document has been fully loaded and parsed, but * scripts may not have yet finished loading and executing. * - `dom-content-loaded`: the document is fully loaded and parsed, and all * scripts (except `async` scripts) have loaded and finished executing. * - `complete`: the document and all of its sub-resources have finished * loading. This is equivalent to the corresponding `readyState` value. */ type LoadState = 'loading' | 'dom-interactive' | 'dom-content-loaded' | 'complete';
FirstInputPolyfillEntry
If using the "base+polyfill" build (and if the browser doesn't natively support the Event Timing API), the metric.entries
reported by onFID()
will contain an object that polyfills the PerformanceEventTiming
entry:
type FirstInputPolyfillEntry = Omit<PerformanceEventTiming, 'processingEnd' | 'toJSON'>
FirstInputPolyfillCallback
interface FirstInputPolyfillCallback { (entry: FirstInputPolyfillEntry): void; }
NavigationTimingPolyfillEntry
If using the
"base+polyfill" build (and if the browser doesn't support the Navigation Timing API Level 2 interface), the metric.entries
reported by onTTFB()
will contain an object that polyfills the PerformanceNavigationTiming
entry using timings from the legacy performance.timing
interface:
type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming, 'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' | 'encodedBodySize' | 'decodedBodySize' | 'type'> & { type: PerformanceNavigationTiming['type']; }
WebVitalsGlobal
If using the "base+polyfill" build, the polyfill.js
script creates the global webVitals
namespace matching the following
interface:
interface WebVitalsGlobal { firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void; resetFirstInputPolyfill: () => void; firstHiddenTime: number; }
Functions:
onCLS()
type onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void
Calculates the CLS value for the current page and calls the callback
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 score).
If the reportAllChanges
configuration option is set to true
, the callback
function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.
Important: CLS should be continually monitored for changes
throughout the entire lifespan of a 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, callback
is always called when the page's visibility state changes to hidden. As a result, the callback
function might be called multiple times during the same
page load (see Reporting only the delta of changes for how to manage this).
onFCP()
type onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void
Calculates the FCP value for the current page and calls the callback
function once the value is ready, along with the relevant paint
performance entry used to determine the value. The reported value is a
DOMHighResTimeStamp
.
onFID()
type onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void
Calculates the FID value for the current page and calls the callback
function once the value is ready, along with the relevant first-input
performance entry used to determine the value. 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.
onINP()
type onINP = (callback: INPReportCallback, opts?: ReportOpts) => void
Calculates the INP value for the current page and calls the callback
function once
the value is ready, along with the event
performance entries reported for that interaction. The reported value is a DOMHighResTimeStamp
.
A custom durationThreshold
configuration option can optionally be passed to control what event-timing
entries are considered for INP reporting. The default threshold is 40
,
which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended good threshold).
If the reportAllChanges
configuration option is set to true
, the callback
function will be called as soon as the value is
initially determined as well as any time the value changes throughout the page lifespan.
Important: INP should be continually monitored for changes throughout the entire lifespan of a 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, callback
is always called when the page's visibility state changes to hidden. As a result, the callback
function might be called multiple times during the same page load (see Reporting only the delta of changes for how to manage this).
onLCP()
type onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void
Calculates the LCP value for the
current page and calls the callback
function once the value is ready (along with the relevant largest-contentful-paint
performance entry used to determine the value). The reported value is a DOMHighResTimeStamp
.
If the reportAllChanges
configuration option is set to true
, the callback
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.
onTTFB()
type onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void
Calculates the TTFB value for the current page and calls the callback
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 callback
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 server processing time.
import {onTTFB} from 'web-vitals'; onTTFB((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.
Attribution:
The following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.
See the attribution build section for details on how to use this feature.
CLS attribution
:
interface CLSAttribution { /** * A selector identifying the first element (in document order) that * shifted when the single largest layout shift contributing to the page's * CLS score occurred. */ largestShiftTarget?: string; /** * The time when the single largest layout shift contributing to the page's * CLS score occurred. */ largestShiftTime?: DOMHighResTimeStamp; /** * The layout shift score of the single largest layout shift contributing to * the page's CLS score. */ largestShiftValue?: number; /** * The `LayoutShiftEntry` representing the single largest layout shift * contributing to the page's CLS score. (Useful when you need more than just * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`). */ largestShiftEntry?: LayoutShift; /** * The first element source (in document order) among the `sources` list * of the `largestShiftEntry` object. (Also useful when you need more than * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`). */ largestShiftSource?: LayoutShiftAttribution; /** * The loading state of the document at the time when the largest layout * shift contribution to the page's CLS score occurred (see `LoadState` * for details). */ loadState?: LoadState; }
FCP attribution
:
interface FCPAttribution { /** * The time from when the user initiates loading the page until when the * browser receives the first byte of the response (a.k.a. TTFB). */ timeToFirstByte: number; /** * The delta between TTFB and the first contentful paint (FCP). */ firstByteToFCP: number; /** * The loading state of the document at the time when FCP `occurred (see * `LoadState` for details). Ideally, documents can paint before they finish * loading (e.g. the `loading` or `dom-interactive` phases). */ loadState: LoadState, /** * The `PerformancePaintTiming` entry corresponding to FCP. */ fcpEntry?: PerformancePaintTiming, /** * The `navigation` entry of the current page, which is useful for diagnosing * general page load issues. */ navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry; }
FID attribution
:
interface FIDAttribution { /** * A selector identifying the element that the user interacted with. This * element will be the `target` of the `event` dispatched. */ eventTarget: string; /** * The time when the user interacted. This time will match the `timeStamp` * value of the `event` dispatched. */ eventTime: number; /** * The `type` of the `event` dispatched from the user interaction. */ eventType: string; /** * The `PerformanceEventTiming` entry corresponding to FID (or the * polyfill entry in browsers that don't support Event Timing). */ eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry, /** * The loading state of the document at the time when the first interaction * occurred (see `LoadState` for details). If the first interaction occurred * while the document was loading and executing script (e.g. usually in the * `dom-interactive` phase) it can result in long input delays. */ loadState: LoadState; }
INP attribution
:
interface INPAttribution { /** * A selector identifying the element that the user interacted with for * the event corresponding to INP. This element will be the `target` of the * `event` dispatched. */ eventTarget?: string; /** * The time when the user interacted for the event corresponding to INP. * This time will match the `timeStamp` value of the `event` dispatched. */ eventTime?: number; /** * The `type` of the `event` dispatched corresponding to INP. */ eventType?: string; /** * The `PerformanceEventTiming` entry corresponding to INP. */ eventEntry?: PerformanceEventTiming; /** * The loading state of the document at the time when the even corresponding * to INP occurred (see `LoadState` for details). If the interaction occurred * while the document was loading and executing script (e.g. usually in the * `dom-interactive` phase) it can result in long delays. */ loadState?: LoadState; }
LCP attribution
:
interface LCPAttribution { /** * The element corresponding to the largest contentful paint for the page. */ element?: string, /** * The URL (if applicable) of the LCP image resource. If the LCP element * is a text node, this value will not be set. */ url?: string, /** * The time from when the user initiates loading the page until when the * browser receives the first byte of the response (a.k.a. TTFB). See * [Optimize LCP](https://web.dev/optimize-lcp/) for details. */ timeToFirstByte: number; /** * The delta between TTFB and when the browser starts loading the LCP * resource (if there is one, otherwise 0). See [Optimize * LCP](https://web.dev/optimize-lcp/) for details. */ resourceLoadDelay: number; /** * The total time it takes to load the LCP resource itself (if there is one, * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for * details. */ resourceLoadTime: number; /** * The delta between when the LCP resource finishes loading until the LCP * element is fully rendered. See [Optimize * LCP](https://web.dev/optimize-lcp/) for details. */ elementRenderDelay: number; /** * The `navigation` entry of the current page, which is useful for diagnosing * general page load issues. */ navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry; /** * The `resource` entry for the LCP resource (if applicable), which is useful * for diagnosing resource load issues. */ lcpResourceEntry?: PerformanceResourceTiming; /** * The `LargestContentfulPaint` entry corresponding to LCP. */ lcpEntry?: LargestContentfulPaint; }
TTFB attribution
:
interface TTFBAttribution { /** * The total time from when the user initiates loading the page to when the * DNS lookup begins. This includes redirects, service worker startup, and * HTTP cache lookup times. */ waitingTime: number; /** * The total time to resolve the DNS for the current request. */ dnsTime: number; /** * The total time to create the connection to the requested domain. */ connectionTime: number; /** * The time time from when the request was sent until the first byte of the * response was received. This includes network time as well as server * processing time. */ requestTime: number; /** * The `PerformanceNavigationTiming` entry used to determine TTFB (or the * polyfill entry in browsers that don't support Navigation Timing). */ navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry; }
Browser Support
The web-vitals
code has been tested and will run without error in all major
browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).
Browser support for each function is as follows:
-
onCLS()
: Chromium -
onFCP()
: Chromium, Firefox, Safari 14.1+ -
onFID()
: Chromium, Firefox (with polyfill: Safari, Internet Explorer) -
onINP()
: Chromium -
onLCP()
: Chromium -
onTTFB()
: Chromium, Firefox, Safari 15+ (with polyfill: Safari 8+, Internet Explorer)
Limitations
The web-vitals
library is primarily a wrapper around the Web APIs that measure
the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well.
The primary limitation of these APIs is they have no visibility into <iframe>
content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).
For same-origin iframes, it's possible to use the
web-vitals
library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and postMessage()
the results to the parent frame for aggregation.
Note: given the lack of iframe support, the onCLS()
function technically measures DCLS (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes).
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.
To build the code and watch for changes, run:
Running the tests
The web-vitals
code is tested in real browsers using webdriver.io. Use the following command to run the tests:
To test any of the APIs manually, you can start the 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.
Integrations
- Web Vitals Connector: Data Studio connector to create dashboards from Web Vitals data captured in BiqQuery.
- Core Web Vitals Custom Tag template: Custom GTM template tag to add measurement handlers for all Core Web Vitals metrics.
-
web-vitals-reporter
: JavaScript library to batchcallback
functions and send data with a single request.
License
Apache 2.0