Microsoft Edge Introduces New Delayed Message Timing API to Supercharge Complex Web Apps

Making Complex Web Apps Faster: Microsoft Edge Proposes New API for Developers

The Microsoft Edge team revealed a major new effort to enhance the performance of complex web applications. The feature, called the Delayed Message Timing API, aims to give developers the tools they need to understand, diagnose, and eliminate hidden slowdowns in multi-threaded or multi-context web apps.

The announcement, co-authored by Joone Hur from the Outlook team and Patrick Brosset, provides a look at how the Edge engineering team continues to push browser performance forward — not just through internal optimizations, but by empowering developers to build faster and more responsive web apps.

Why Browser Speed Still Matters

In an age where web apps rival native applications in complexity, speed and responsiveness remain critical. Every millisecond matters — from how fast a page loads to how quickly user input gets processed. Microsoft Edge has focused on performance improvements across three dimensions:

1. Within the browser itself, by enhancing responsiveness and making Edge faster overall.

2. Within the browser engine, with deep changes that make complex applications run smoother.

3. For developers, by introducing new APIs that help identify bottlenecks and optimize performance-critical paths.

The Delayed Message Timing API falls into that third category. Its purpose: to shine light on one of the least understood but most frustrating sources of lag — communication between multiple parts of a web app.

The Hidden Cost of Cross-Context Messaging

Modern apps increasingly rely on distributed architectures. They use iframed interfaces, Web Workers, or service threads to keep UI rendering and background computations separate. However, that separation introduces messaging overhead. When one component sends a message to another — say, from the main window to a worker — performance can suffer if messages pile up or get delayed.

The problem, Edge engineers note, is that developers have had no clear way to measure where or why these delays occur. Messages sent with the familiar postMessage() API may seem instant, but when threads are busy or overloaded, those messages can get stuck in a queue for noticeable periods.

The Edge team identified three main sources of delay that the new API directly addresses.

1. The Receiving Context Is Busy

Sometimes the receiving thread or window is simply processing another heavy synchronous task, making it unavailable to handle incoming messages. This causes blocking delays that ripple across the application.

To tackle this, the Delayed Message Timing API introduces a new metric: blockedDuration. This property tells developers exactly how long a message sat in the queue before being processed, providing visibility into situations where one context is monopolizing thread time.

2. The Task Queue Is Congested

Even when no single task is too long, a buildup of too many small tasks can create congestion similar to a traffic jam. This happens frequently in pages juggling UI rendering, event handling, and server communication simultaneously.

To help developers quantify this issue, the new API adds taskCount and scriptTaskCount properties. These values represent how many tasks were blocking the message, giving engineers a detailed view into the nature of the bottleneck — whether it’s caused by scripts, user events, or background operations flooding the queue.

3. Serialization and Deserialization Overhead

Messages exchanged between browser contexts must be serialized when sent and deserialized when received. Although this might seem trivial, serialization overhead can be significant for larger or more frequent messages.

The new API measures this precisely through two additional metrics: serialization and deserialization. These properties expose exactly how much time was consumed in converting the data, helping developers decide when to restructure or simplify their messaging strategies.

Real-Time Performance Insights for Developers

The best part of the Delayed Message Timing API is its integration with the existing PerformanceObserver framework, making it easy for developers to collect and analyze data in real time.

For example, a developer can create an observer in JavaScript that listens for "delayed-message" performance entries and outputs the timing details whenever a message passes between contexts. The resulting data includes timestamps, durations, and even information about which script or function triggered the send and receive events.

By correlating entries collected from both the sender and receiver, developers can create a complete “round-trip” performance profile — something that was nearly impossible before this API.

The following code snippet shows how to use the proposed API:

// Create a PerformanceObserver instance.
const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

// Start observing "delayed-message" Performance entries.
observer.observe({type: 'delayed-message', buffered: true});

And here is an example of the properties available on the corresponding “delayed-message” Performance entry:

{
"name": "delayed-message",
"entryType": "delayed-message",
"startTime": 154.90000009536743,
"duration": 169,
"traceId": 4,
// The type of message-passing event.
"messageType": "cross-worker-document",
// The timestamp for when the message was added to the task queue.
"sentTime": 155,
// The timestamps for when the receiving context started and stopped
// processing the message.
"processingStart": 274.90000009536743,
"processingEnd": 324.7000000476837,
// The time the message spent waiting in the receiver's task queue.
"blockedDuration": 119.90000009536743,
// The time needed to serialize and deserialize the message.
"serialization": 0,
"deserialization": 0,
// The number of queued tasks blocking the postMessage event.
"taskCount": 38,
// The number of entry-point JavaScript tasks, including those with
// a duration lower than 5ms.
"scriptTaskCount": 2,
// The time needed to run all script.
"totalScriptDuration": 119,
// The list of PerformanceScriptTiming instances that contribute to the
// delay.
"scripts": [
{
"name": "script",
"entryType": "script",
"startTime": 154.90000009536743,
"duration": 119,
"invoker": "DedicatedWorkerGlobalScope.onmessage",
"invokerType": "event-listener",
"windowAttribution": "other",
"executionStart": 154.90000009536743,
"forcedStyleAndLayoutDuration": 0,
"pauseDuration": 0,
"sourceURL": "...",
"sourceFunctionName": "runLongTaskOnWorker",
"sourceCharPosition": 267
}
],
// The PerformanceMessageScriptInfo instance which provides details
// about the script that sent the message.
"invoker": {
"name": "invoker",
"sourceURL": "...",
"sourceFunctionName": "sendMessage",
"sourceCharPosition": 531,
"sourceColumnNumber": 14,
"sourceLineNumber": 13,
"executionContext": {
"name": "",
"type": "window",
"id": 0
}
},
// The PerformanceMessageScriptInfo instance which provides details
// about the script that handled (or is handling) the message.
"receiver": {
"name": "receiver",
"sourceURL": "...",
"sourceFunctionName": "runLongTaskOnWorker",
"sourceCharPosition": 267,
"sourceColumnNumber": 41,
"sourceLineNumber": 9,
"executionContext": {
"name": "",
"type": "dedicated-worker",
"id": 1
}
}
}

A New Step in Collaborative Web Optimization

Microsoft’s move isn’t just about improving Edge’s speed alone — it’s about improving the web itself. The Delayed Message Timing API proposal is being developed in collaboration with the Web Incubator Community Group (WICG), ensuring open discussion and feedback from the broader web development community.

The company is actively encouraging developers to review the proposal on GitHub and share feedback through GitHub Issues. By crowdsourcing developer insights, Microsoft hopes to refine the API for real-world use cases across different browsers and web architectures.

Why This Matters for Developers and Users

For web developers, tools like this are a breakthrough. Diagnosing performance issues in complex, multi-threaded apps has historically been a guessing game. With clear metrics from the Delayed Message Timing API, developers can finally pinpoint where bottlenecks occur — whether due to blocked threads, message congestion, or expensive serialization.

For users, the benefits manifest as faster, smoother web apps. Whether it’s Outlook on the web, an online game, or a cloud-based productivity tool running in Edge, these insights help developers ensure seamless performance and responsiveness.

Microsoft Edge’s Ongoing Performance Commitment

This latest announcement underscores Edge’s continued push toward becoming the most developer-friendly, performance-optimized browser available. Following major improvements earlier this year — including faster startup times and better multitasking performance in Edge 134 — the browser is now setting its sights on helping developers close the gap between performance theory and practice.

As Joone Hur summarized in the post, “Complex applications require complex architectures,” and Microsoft’s mission is to make sure those architectures don’t get in the way of speed.

Looking Ahead

The Delayed Message Timing API remains a proposal for now, but with developer interest and WICG collaboration, it has strong potential to become a web standard. Microsoft’s open approach invites anyone building modern web apps to try out the specification, provide feedback, and help shape the API’s final form.

By focusing on transparency, collaboration, and data-driven optimization, Edge continues to lead by example in browser innovation — and this latest step could make complex web apps faster for everyone.