What causes delays in cross-context messaging?

Slowdown 1 – The receiving context is busy

Slowdown 2 – The task queue is congested

Slowdown 3 – Serialization and deserialization overhead

Using the Delayed Message Timing 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});

{
    "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
        }
    }
}

Let us know what you think

• Settings: you can now more quickly load and navigate to the browser settings and customize your browsing experience.
• Read aloud: to experience AI-powered reading of webpages in more languages, accents, and voices—all with reduced startup time and smoother playback.
• Split screen: effortlessly switch between tasks and windows with near-instant navigation and less loading delays.
• Workspaces: from the moment you open a page, tasks feel more responsive and intuitive, allowing you to dive into your work without delay.

Looking ahead

Goals

• To make it possible for you to control the performance impact of the content you embed, and make it easy to do so, without having to determine exactly the individual constraints that are needed.
• And to make it possible for you to know when performance violations occur, so that you can understand when the user experience is negatively impacted by embedded content and improve the experience.

Proposal

• basic - Basic web development best practices that are scenario agnostic This category encompasses fundamental web development best practices to ensure websites are optimized for performance across various environments. These tasks are typically simple to implement but are frequently overlooked, leading to significant performance issues. Constraints include limits on oversized assets (images, web fonts, etc.), and flagging unzipped assets and uncompressed resources.
• early-script - JavaScript constraints to enhance performance and minimize impact on user experience before interaction begins This category focuses on JavaScript development best practices that can be done to minimize performance issues before user interaction begins. This includes capping JavaScript resources loaded initially to avoid overwhelming devices with limited processing power or bandwidth, serving JavaScript with constrained content-length headers, and requiring animations to run on the compositor thread.
• globals - Overall media and system resource usage constraints This category entails imposing limits on overall media and system resource usage during interactions to help prevent websites from over-consuming resources and degrading user experiences. This includes capping total media usage, iframe count, iframe depth, and CPU usage before the first interaction.
• script - Strict JavaScript restrictions while running/post-load This category enforces restrictions on more complex JavaScript to further enhance performance. This includes limiting long tasks running on the main thread and capping high CPU usage tasks, particularly those involving workers that exceed certain execution times.

Example

Let us know what you think

Monitoring UI responsiveness

• Research indicates that there are certain absolute responsiveness targets that must be met for a user to perceive the UI as fast, and data showed our UI could be more responsive.
•  We had an opportunity to improve responsiveness for lower resourced devices.

1. The way we organized the UI code in Edge wasn't modular enough. Teams who worked on different components shared common bundles even when that wasn't strictly necessary. This resulted in one part of the UI code slowing down another part by sharing things unnecessarily.
2. A lot of our code was using a framework that relied on JavaScript to render the UI.  This is referred to as client-side rendering, which has been a popular trend amongst web developers over the past decade because it helped web developers be more productive and enabled more dynamic UI experiences.

Rendering web UI like it was meant to be

1. Could we maintain the developer productivity that JavaScript frameworks have given us while generating code that renders UI fast?
2. Could the browser be its own best customer?
3. How fast could we make things if we removed that framework and built our UI just by using the web platform?

Introducing WebUI 2.0

How to access resource controls

How to keep an eye on browser performance

• Speedometer 2.1 determines the responsiveness of a browser, so it's a good benchmark to use for overall website performance.
• MotionMark 1.2 is a graphical browser test suite that measures the rendering performance of complex webpages that have lots of graphics & animations, such as Excel Online.
• And JetStream measures how quickly browsers can start & run code. It's a good measure for how responsive the browser is on code-intensive sites.

Reducing CPU sampling overhead by 95%

Simplified source maps everywhere you need them

Beyond JavaScript performance

A slew of memory improvements

• The Memory tool can now load much larger heap snapshot files: when memory gets out of control and a memory leak investigation is needed, it helps if the tool can deal with large amounts of data.
• We also made recording large heap snapshots much faster. Generating large heap snapshots that weigh over 1GB is now 70% to 86% faster.
• We made it possible to compare two heap snapshots by their retainer paths. For applications with a size and complexity that’s comparable to the Microsoft 365 web apps, this makes finding memory leaks much easier. You can now see what top level objects are growing in retained size.
• Navigating large memory heap snapshots is also easier now with the ability to filter snapshopts by node types.

In the end, it’s all about teamwork

In practice, does it matter?

Measure!

Selector stats to the rescue

1. Open the Performance tool.
2. Open the tool’s settings by clicking the cog icon in the top-right corner.
3. Check the Enable advanced rendering instrumentation (slow) option.
4. Click Record, execute the scenario on the webpage that you want to improve, and then click Stop.
5. In the recorded profile, identify a long style recalculation that you want to improve and select it in the waterfall view ("Main" section).
6. In the bottom tab bar, click Selector Stats.

Case study

• Load the demo page, and wait for the filters to be ready.
• Switch the camera model filter to another value and start the performance recording.
• Switch back to all camera models and stop the recording.

• `.gallery .photo .meta ::selection`
• `.gallery .photo .meta li strong:empty`
• `[class*=" gallery-icon--"]::before`
• `.gallery .photo .meta li`
• `*`
• `html[dir="rtl"] .gallery .photo .meta li button`

Improving the ::selection selector

Improving the :empty selectors

.gallery .photo .meta li strong:empty {
  padding: .125rem 2rem;
  margin-left: .125rem;
  background: var(--dim-bg-color);
}

html[dir="rtl"] .gallery .photo .meta li strong:empty {
  margin-left: unset;
  margin-right: .125rem;
}

.gallery .photo .meta li strong:empty {
  padding: .125rem 2rem;
  margin-inline-start: .125rem;
  background: var(--dim-bg-color);
}

Improving the [class*=" gallery-icon--"] selector

[class*=" gallery-icon--"]::before {
  content: '';
  display: block;
  width: 1rem;
  height: 1rem;
  background-size: contain;
  background-repeat: no-repeat;
  background-position: center;
  filter: contrast(0);
}

.gallery-icon--camera::before { background-image: url(...); }
.gallery-icon--aperture::before { background-image: url(...); }
.gallery-icon--exposure::before { background-image: url(...); }
...

.gallery-icon::before {
  content: '';
  display: block;
  width: 1rem;
  height: 1rem;
  background-size: contain;
  background-repeat: no-repeat;
  background-position: center;
  filter: contrast(0);
}

.gallery-icon.camera::before { background-image: url(...); }
.gallery-icon.aperture::before { background-image: url(...); }
.gallery-icon.exposure::before { background-image: url(...); }

Improving the .gallery .photo .meta li selector

.photo-meta {
  display: flex;
  align-items: center;
  gap: .5rem;
  height: 1.5rem;
}

Improving the * selector

* {
  box-sizing: border-box;
}

Results

Conclusion