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, 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.jsv5 as the minimum version. - Explicitly configuring
web-vitals.jsv5 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 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. 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 from the library, following its replacement by INP as Core Web Vital.
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 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 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. 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 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 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 and Safari 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 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. 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
- 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 dimensionsperformance.mark()andperformance.measure()to track timings in JSServer-Timingheaders to track server-side timing and dimensionselementtimingattributes to track timing of divs, headers and images
Those integrations continue to work exactly as before.
