---
title: "Blog"
description: "Read about the background of our monitoring solution, new features and case studies"
canonical: "https://www.rumvision.com/blog/interop-2026-key-apis-for-sitespeed-and-rum/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog

# Interop 2026: Key APIs for sitespeed & RUM

At RUMvision, our focus is helping site owners make their sites faster. To do that well, we depend on the data browsers give us through APIs. Some of those APIs are already incredibly useful — but not all browsers support them consistently.

That’s where Interop comes in. Interop is the annual cross-browser initiative where vendors agree on sets of features and tests to prioritize for interoperability. For 2026, several new topics are under consideration. Some of these are critical for Real User Monitoring (RUM), while others are just generally exciting for site speed, Core Web Vitals, and web performance.

We care about both, but especially the RUM-focused ones, since they directly affect our ability to give site owners the insights they need.

## Why interop matters

Every year, browser vendors align on a list of features to make interoperable. That doesn’t mean every idea with lots of upvotes makes it in, but strong support and at least one implementation can help.

### Becoming a candidate

The key point: if something already exists in at least one major browser, it can be a candidate for Interop. That’s why RUM providers, performance engineers, and developers should pay attention to the proposals below.

### Exceptions

Sometimes vendors disagree for technical or strategic reasons, so not everything with traction ends up cross-browser. For example:

- Firefox removed the Battery Status API due to privacy concerns: the data could be used for fingerprinting.
- Firefox is holding back JPEG XL support until their Rust implementation is stable, even though the feature has strong demand.
 
One of the cool things about Interop is that anyone can propose ideas. Not every proposal makes it, but by raising awareness and voting we can show browser vendors where the community sees value. Even if we can’t decide the outcome, we can still help each other by supporting the proposals that make the web faster, safer, and more consistent.

## RUM-driven proposals we care about

### 1. Long Animation Frames API

[Long Animation Frames](https://www.rumvision.com/blog/long-animation-frames/?format=md) (LoAF) is particularly compelling: the ability to break down the rendering pipeline beyond what Long Tasks API provides would be huge for diagnosing jank. Being able to pinpoint whether it's style, layout, or paint that's causing the slowness and caused by which JavaScript file is exactly the kind of granular data RUM providers need.

We even ended up introducing a [Third Party dashboard](https://www.rumvision.com/help-center/monitoring/dashboard/third-parties/?format=md) for our users around the data exposed by the LoAF API.

- **What it is:** Reports frames delayed over 50ms, whether by JS or rendering work, blocking the next paint.
- **Why it matters:** Gives better insights than Long Tasks for fixing responsiveness, INP, and smoothness issues.
- **RUM impact:** Lets us measure rendering slowness more precisely in real user conditions.
 
👉 Help make this interoperable across browsers in 2026 by voting for [LoAF on the Interop GitHub issue](http://github.com/web-platform-tests/interop/issues/1067).

### 2. fetchLater API

[fetchLater API](https://www.rumvision.com/blog/introducing-fetchlater-api-a-new-way-to-collect-core-web-vitals/?format=md) is a browser-managed deferred requests (e.g. send analytics after navigation). Unlike unreliable unload beacons, the browser takes responsibility for guaranteed delivery, sending queued requests when the document is destroyed, after a specified time, or when the browser decides it's optimal.

- **What it is:** A declarative way to defer network requests (e.g. send analytics after navigation).
- **Why it matters:** Today, unload beacons are unreliable. fetchLater would standardize this.
- **RUM impact:** Reliable delivery of telemetry and analytics beacons — a core use case for RUM.
 
👉 Help make this interoperable across browsers in 2026 by voting for [fetchLater on the Interop GitHub issue](http://github.com/web-platform-tests/interop/issues/1069).

### 3. Signature-based Integrity

[Signature-based Integrity](https://www.rumvision.com/blog/javascript-flexibility-same-security-with-signature-based-sri/?format=md) is interesting from a supply-chain security angle and especially relevant given how not just our clients, but all websites out there depends on third-party scripts and the security concerns around that.

- **What it is**: Evolved Subresource Integrity using cryptographic signatures instead of fragile hashes.
- **Why it matters:** Allows sites to verify third-party resources securely, even when they’re updated frequently.
- **RUM impact:** Stronger supply-chain security for scripts and libraries we depend on.
- **Status:** Chromium shipped in v141; Firefox positive; Safari unannounced.
 
👉 Help make this interoperable across browsers in 2026 by voting for [Signature-based Integrity on the Interop GitHub issue](http://github.com/web-platform-tests/interop/issues/1071).

## Other sitespeed-relevant proposals

### Network Information API

- **What it is:** An API that exposes details like effective connection type (e.g. 4G, 3G), round-trip time, and downlink.
- **Why it matters:** Helps adapt content delivery to real-world network conditions.
- **RUM impact:** Lets us segment performance data by connection quality, giving a clearer picture of how sites perform for users on slow networks.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1079)

### Resource Timing

- **What it is:** A standardized way to capture detailed timing data for every resource (scripts, styles, images, etc.).
- **Why it matters:** Crucial for diagnosing bottlenecks in loading.
- **RUM impact:** More consistent metrics for critical resources, making cross-browser comparisons fairer and more accurate.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1078)

### Speculation Rules

- **What it is:** Declarative hints that tell the browser which pages are good candidates for prefetch or prerender.
- **Why it matters:** Lets developers speed up navigation without relying on heavy JS or guesswork.
- **RUM impact:** If interoperable, could improve user-perceived speed while still letting us measure those effects consistently.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1081)

### requestIdleCallback

- **What it is:** An API to allow developers to run non-critical work when the main thread is idle.
- **Why it matters:** Helps keep the main thread free, reducing input blocking and jank.
- **RUM impact:** No direct metric, but can improve INP, especially once Safari rolls out INP.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1005)

### Cumulative Layout Shift

- **What it is:** CLS is a Core Web Vitals metric that tracks unexpected layout movements via the Layout Instability API
- **Why it matters:** Layout shifts disrupt users. Consistent measurement across browsers ensures fairness.
- **RUM impact:** More data across all browsers gives a clearer picture of the shifting experience.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1057)

### HTML blocking="render" attribute

- **What it is:** A new attribute to mark scripts, links or styles as render-blocking.
- **Why it matters:** Lets developers declare render-blocking resources instead of relying on hacks.
- **RUM impact:** Indirect: could improve LCP if used well, or hurt it if misused.
 
[Vote or find it here](https://github.com/web-platform-tests/interop/issues/1070)

## Takeaway

Interop 2026 isn’t just about new shiny APIs, it’s about making sure the features that matter for *real user experience* work the same across browsers.

For us at RUMvision, **LoAF, fetchLater, and SbSRI** stand out as the highest-impact proposals. They would:

- Provide better visibility into rendering slowness.
- Make analytics more reliable.
- Strengthen security for third-party code.
 
But we’re also excited about **Network Information, Resource Timing, and Speculation Rules**, which would give both developers and RUM providers new tools to understand and improve site performance.

And remember: **upvotes are not guarantees**. They signal interest, but vendors ultimately decide what to implement. Still, by voicing support, we can help important features gain visibility and traction.

*\*edit: votes are closed and update coming in [first half of February](https://github.com/web-platform-tests/interop/blob/main/2026/README.md)*