# RUMvision v5: modernized real-user tracking RUMvision v5 is a broader tracking architecture update focused on more reliable data collection, improved SPA navigation cleanup, better beacon handling and closer alignment with modern browser APIs, while leaving older compatibility layers behind. > **No action needed:** RUMvision v5 is already active for almost all eligible sites. Your embed code and configuration can stay as they are. With [`web-vitals.js` release of v5](https://github.com/GoogleChrome/web-vitals/blob/main/CHANGELOG.md#v500-2025-05-07), it was time to rethink and eventually refactor our tracking agent as well to be able to say goodbye to legacy implementations from earlier versions. Coincidentally, with this change, our own tracking agent also moved to v5. Although those version numbers align nicely, the migration was much bigger than simply updating a dependency. ## RUMvision v5 rollout In Q1 2026, we started the gradual rollout of our new v5 tracking architecture. For most sites, no embed code or configuration changes are needed, as we handle the version bump automatically on our side. ### Rollout timeline RUMvision v5 is now fully rolled out across eligible sites. This is how the rollout progressed: - February 24th, 2026: first production sites on v5 (~0.05% of all sessions) - March 24th, 2026: increased to 1% - March 31st, 2026: increased to 5% - April 7th, 2026: increased to 15% - May 1st, 2026: increased to 50% - May 11th, 2026: increased to 97.5% ### SRI users The remaining 2.5% mainly consists of websites using Subresource Integrity (SRI) to load our tracking script. Are you one of them? Then make sure to manually bump the inline snippet version from `v4` to `v5`. For all other websites, this migration happens automatically, even if the filename in your embedded code still references `v4`. ### Alignment with web-vitals.js To leave older compatibility layers behind, we now automatically align the RUMvision agent with the configured `web-vitals.js` version. - RUMvision v5 enforces `web-vitals.js` v5 as the minimum version. - Explicitly configuring `web-vitals.js` v5 also enforces RUMvision v5 as the minimum tracking architecture. This keeps our soft-navigation handling compatible with the `web-vitals.js` soft-navs build, while removing compatibility logic for older naming conventions and legacy metrics such as FID. ## Changes in web-vitals.js v5 Amongst other changes, the official `web-vitals.js` v5 migration guide introduced [several important changes](http://github.com/GoogleChrome/web-vitals/blob/main/docs/upgrading-to-v5.md) as well. ### Long Animation Frames (LoAF) The new version expands INP attribution with Long Animation Frame (LoAF) information, including longest-script attribution and LoAF buckets. Interestingly, we already built a custom version of this ourselves [when `web-vitals.js` v4 came out](https://www.rumvision.com/md/blog/google-web-vitals-v4-supports-loaf-inp-breakdown/). The official implementation now allows us to simplify parts of our own attribution logic over time. ### FID was removed [First Input Delay (FID) was fully removed](https://www.rumvision.com/md/blog/reshaping-ux-score-how-rumvision-is-aligning-with-fid-changes/) from the library, following its [replacement by INP as Core Web Vital](https://www.rumvision.com/md/blog/march-12-is-when-google-inp-becomes-core-web-vital/ "INP replaced FID as a Core Web Vital on March 12, 2024"). That also allowed us to remove legacy FID-specific ignore logic from our own tracking agent. ### Browser support changed `web-vitals.js` v5 now aligns with the [Baseline Widely Available](https://www.rumvision.com/md/blog/baseline-standardized-support-status-web-features/) browser support policy. In practice, this means browsers older than 30 months are no longer supported by the library. For us, that also simplified several compatibility layers and legacy workarounds. ## A rebuilt tracking architecture There were several reasons behind our own v5 architecture changes. ### Single Page Applications [Single Page Applications and their soft navigations](https://www.rumvision.com/md/blog/soft-navigations-better-core-web-vitals-attribution-for-spas/) break the assumption of one navigation per page life cycle completely. A single SPA session can contain multiple navigations, route transitions, bfcache restores and metric resets while the same HTML document remains alive. #### Better SPA navs handling Our new navigation model introduces tying navigationId's (as emitted by web-vitals library) together to own request UUIDs. With that change, we also introduced navigation eviction logic. ### New metric collection strategy We also changed how we collect late-changing metrics such as INP and CLS. By default, `web-vitals.js` only reports INP when a [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden). As RUMvision is doing additional attribution to enrich INP data, we noticed a dropoff of INP datapoints as our callbacks wouldn't always run. This would even result in loss of early INP datapoints. To prevent this loss of data, RUMvision v5 now uses [`reportAllChanges: true`](https://github.com/GoogleChrome/web-vitals/tree/main#report-the-value-on-every-change) for INP and CLS. This does not mean every interaction or every layout shift is reported. It only means the callback is triggered when the metric value itself changes. This only happens when there's a CLS or INP value became higher within that navigation. To prevent over-beaconing, we also had to switch beaconing strategy. ### Updated beaconing strategy Last year, we already adopted the [`fetchLater() API`](https://www.rumvision.com/md/blog/introducing-fetchlater-api-a-new-way-to-collect-core-web-vitals/) in our v4. This allows us to create a beacon, abort and re-create when new metric data comes in, and let the browser send it at the right lifecycle moment. In other words, our `reportAllChanges: true` usage would not result in more beacons. #### FireFox and Safari [FireFox](https://www.rumvision.com/md/blog/firefox-ships-inp-support/) and [Safari](https://www.rumvision.com/md/blog/safari-catching-up-inp-and-lcp-support-in-the-same-beta-release/) now support metrics such as LCP and INP, which is great for cross-browser Core Web Vitals monitoring. But they do not support `fetchLater()`, so those browsers would end up triggering a beacon for each reported metric-change. #### Shopify storefronts The same applies to Shopify storefronts as we detected and reported [a quota glitch](https://issues.chromium.org/issues/410528357) that left us unable to benefit from the fetchLater API. #### Keeping beacon volume low To avoid that, we align their behavior as closely as possible with the `fetchLater()` model. Instead of sending every metric change immediately, we queue updated data and send it through `fetch()` when the page becomes hidden or fires `pagehide`. This helps us keep beacon volume low across browsers, while still improving visibility into late INP and CLS changes. ### Investigating fetchLater edge cases During first implementation, we [detected and reported an issue with the fetchLater API](https://issues.chromium.org/issues/408010432). In short, `fetchLater()` beacons may not get delivered when the final browser tab in the final window gets closed. By always sending an initial eager beacon first, we will now have better visibility into how often this situation occurs in real-world traffic. That data may help the Chromium team further improve the API. ### Browser detection improvements Although v4 was not limiting us here, we decided to overhaul our browser and bot detection as well. With that, we also ended up tracking the browser's underlying rendering engine, such as: - Blink (58.8% of our datapoints, with 73.8% coming from Google Chrome) - WebKit (38.9%, 73.6% coming from Safari) - Gecko (2.0%, 100% coming from Firefox) Our v5 architecture also slightly improves browser detection. The new implementation better combines: - [User-Agent Client Hints](https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API) - traditional User-Agent parsing as a fallback - broadened in-app browser detection - WebView heuristics ## Invisible upgrade For customers, the migration was invisible. Existing snippets and configurations keep working, while dashboards benefit from richer and more accurately attributed data. ### Backwards compatibility One important goal during this migration was backwards compatibility. Most RUMvision customers embed our tracking script either directly in their source code or through Google Tag Manager Custom HTML tags. That embed snippet did not need to change. ### Existing integrations continue to work Site owners using custom integrations also did not need to change their setup. That includes: - `rumv('set', ...)` to set custom dimensions - `performance.mark()` and `performance.measure() `to track timings in JS - `Server-Timing` headers to track server-side timing and dimensions - `elementtiming` attributes to track timing of divs, headers and images Those integrations continue to work exactly as before.