Introducing fetchLater API: A new way to collect Core Web Vitals

The above might sound technical, but its benefits are easy to understand — and they're pretty exciting!

What exactly is fetchLater?

An initial proposal was called PendingBeacon API, but eventually replaced by fetchLater

Simply put, fetchLater is a JavaScript API introduced by the Chromium team (the folks behind Chrome, Edge, Opera, and Brave browsers) that allows websites to defer sending data (such as analytics and performance metrics) until the user leaves or closes the page.

When a webpage uses fetchLater, the browser queues requests until:

• the user closes the tab
• the browser decides it's appropriate
• or after a specified amount of time passes.

The API is already available today (from Chrome version 135 onwards).

Why was fetchLater introduced?

Before fetchLater, web developers had limited and often unreliable options to send data at the end of a page life cycle:

• users can navigate away
• users can close the browser tab or whole browser window
• users can switch to a different tab or app and never come back

In each scenario, you still want to collect final information.

Methods like sendBeacon, fetch with keepalive, or adding invisible images were commonly used but came with significant reliability challenges. Especially on mobile devices.

The above methods all suffer from reliability problems, stemming from one core issue

github.com/WICG/pending-beacon/

fetchLater solves this reliability issue by providing a consistent, browser-managed method to send analytics data exactly at the right time. Developers no longer need to guess the optimal moment to dispatch analytics, because the browser handles it intelligently.

Key benefits of fetchLater

Benefits for RUMvision and our customers are as follows:

• Less beacons and costs
  We're able to bundle multiple metric updates into fewer "beacons", drastically reducing data usage and associated AWS infrastructure costs.

• Less data
  Some metrics are dispatched multiple times per page life cycle. The maximum scrolling depth can be an example, or — in the case of a RUM tool — metrics like Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Instead of sending every new change, we’re now sending most recent and thus fewer and more meaningful updates for metrics.

• More data
  At the same time, we expect more data by moving to fetchLater. Certainly once other browsers are adopting the fetchLater API, as reliability of other events are diverse across browsers.

• Better data quality
  Because fetchLater ensures the browser sends data exactly when needed, Core Web Vitals data closely match those reported by Chrome’s official UX Report (CrUX). This is particularly helpful for our SEO-minded customers who want their data to closely align with CrUX.

• Simpler beacon handling
  Using fetchLater, our analytics can consistently capture critical data points without needing complex backend processing to filter or clean data — meaning data gets to your dashboard faster.

In general, for the web performance community:

• Reliability
  fetchLater is robustly integrated into modern browsers, ensuring data collection is stable and dependable across various devices and networks (although I filed a bug for a very specific scenario).

• Performance-friendly
  Reduces unnecessary network traffic by batching beacon requests, although web performance gains will be minor.

• Built-in bandwidth caps
  To avoid situations where documents abuse this bandwidth to send unlimited amounts of data over the network, the overall quota for a top level document is capped.

RUMvision and fetchLater

We’ve already begun gradually deploying fetchLater on client websites. Thanks to existing code examples, the integration was very straightforward. It was mainly back forward cache navigations where our fetchLater beacons weren't send. However, this was the result of our own implementation instead of how the fetchLater API works.

Another important part of our implementation was gracefully falling back to fetch for browsers that don't yet support it. This caveat applies to any other analytics and RUM providers wanting to adopt the fetchLater API.

Data outcome

In order to monitor results, we added the fetch type that was used in our beacons to indicate if data was collected using fetch or fetchLater. Early data is as expected and doesn't show anomalies. We do expect more datapoints in datasets for our customers as most recent data that would otherwise be dispatched late in time via other APIs were not able to be fully

This means that on top of the simplicity of implementing this API as a developer, initial results are highly promising, improved data reliability, and cost savings.

Browsers and support

For the reasons stated above, we're grateful to the Chromium team for this API that already turned out to be practical. Although other browser engines have stated to be positive about this API, we have to wait a bit more to see it land in Mozilla and in WebKit.

The Baseline badge below is an up-to-date badge showing latest browser support for the fetchLater API in the 4 major browsers.

Next steps

There are no real next steps aside from monitoring results and expecting costs reduction. When more data is available, we'll be sure to provide updates here.

Erwin Hofman

CTO & Pagespeed expert, GDE

• {label:mailto}
• linkedin-square
• twitter-square