--- title: "Blog" description: "Read about the background of our monitoring solution, new features and case studies" canonical: "https://www.rumvision.com/blog/introducing-fetchlater-api-a-new-way-to-collect-core-web-vitals/" --- Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog # Introducing fetchLater API: A new way to collect Core Web Vitals At RUMvision, we're always looking for smarter ways to optimize web performance data collection. That's why we're excited to announce we've begun rolling out support for a new browser API called fetchLater. 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](https://github.com/WICG/pending-beacon/blob/main/docs/pending-beacon-api.md), but eventually replaced by fetchLater Simply put, [`fetchLater` is a JavaScript API](https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md) 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](https://chromestatus.com/feature/4654499737632768)). ### 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/](https://github.com/WICG/pending-beacon/blob/main/README.md#motivation) `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)](https://www.rumvision.com/blog/interaction-to-next-paint/?format=md) and [Cumulative Layout Shift (CLS)](https://www.rumvision.com/blog/cumulative-layout-shift/?format=md). 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](https://www.rumvision.com/tools/core-web-vitals-history/?format=md) closely match those reported by [Chrome’s official UX Report (CrUX)](https://www.rumvision.com/help-center/glossary/monitoring/crux-api/?format=md). 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](https://issues.chromium.org/issues/408010432) 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](https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md#outline). ## RUMvision and fetchLater We’ve already begun gradually deploying `fetchLater` on client websites. Thanks to [existing code examples](https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md#update-a-pending-request), the integration was very straightforward. It was mainly [back forward cache navigations](https://www.rumvision.com/blog/meet-bfcache-instant-pageloading-solution/?format=md) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1936180) and [in WebKit](https://bugs.webkit.org/show_bug.cgi?id=284347). The [Baseline badge](https://www.rumvision.com/blog/baseline-standardized-support-status-web-features/?format=md) 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.