An even faster Microsoft Edge

[Microsoft Edge Team]

Over the past month, you may have noticed that some of Edge's features have become faster and more responsive. That's because Edge is on a journey to make all user interactions in the browser blazing fast starting with some of our newest features and core features. Starting with Edge 122, the Browser Essentials UI is now much more responsive. The UI is now 42% faster for Edge users and a whopping 76% faster for those of you on a device without an SSD or with less than 8GB RAM!



Favorites is another Edge feature that's getting UI responsiveness improvements in Edge 124. Whether favorites are expanded or collapsed, the experience should be 40% faster. And this is just the tip of the iceberg. Over the coming months we will continue to ship responsiveness improvements to many more Edge features including history, downloads, wallet and more. We'd love for you to try Microsoft Edge and let us know what you think. Tell us about your experience by using the feedback tool in Edge: click Settings and more (...) > Help and feedback > Send feedback. Read on for more details on how we made this all possible.

Monitoring UI responsiveness​

Edge's UI responsiveness improvements started with understanding what you, our users, were experiencing. Edge monitors its UI responsiveness via telemetry collected from end users' machines.  We intentionally did this collection for all the parts of the Edge UI, not just for the web pages that we render.  What did we learn from this data?

• 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.

We are constantly learning more about how we can improve the performance of the Edge UI and, by using this data, we discovered some areas of improvement.  For example, we observed that the bundles of code that many of our components used were too large. We realized that this was due to two main reasons:

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​

Why are we sharing this ancient news? After all, a lot of web pages have been rendering on the client-side for years. Well, it turns out that JavaScript must be downloaded, then run through a JIT compiler (even if you don't use it), and then executed, and all this must be done before any of the JavaScript can start rendering the UI. This introduces a lot of delay before users can see the UI, especially on low-end devices. If you turn back the time machine prior to the Web 2.0 era, the way web content was rendered was by using HTML and CSS.  This is often referred to as server-side rendering, as the client gets the content in a form that's ready to render. Modern browser engines are very fast at rendering this content so long as you don't let JavaScript get in the way. Based on this realization, our questions became:

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?

The answers to these questions are Yes, Yes, and Very Fast.

Introducing WebUI 2.0​

The result of this exercise is an Edge internal project that we've called WebUI 2.0. In this project, we built an entirely new markup-first architecture that minimizes the size of our bundles of code, and the amount of JavaScript code that runs during the initialization path of the UI. This new internal UI architecture is more modular, and we now rely on a repository of web components that are tuned for performance on modern web engines.  We also came up with a set of web platform patterns that allow us to ship new browser features that stay within our markup-first architecture and that use optimal web platform capabilities. Browser Essentials is the first Edge feature which we converted to test the new architecture and to prove that the concept worked, especially on all types of devices. We're in the process of upgrading components of the Edge user interface to WebUI 2.0 and you can expect to see more features of the browser getting far more responsive over time. We hope that more websites start moving in this direction of markup-first, small bundles, and less UI-rendering JavaScript code. Over time, we plan on making some of our packages open source, so that all developers can benefit. Finally, as we continue improving WebUI 2.0, we're committed to finding opportunities to improve the web platform itself even more. We hope you enjoy this upgraded Edge experience!

Source: An even faster Microsoft Edge

 

[Bot]

Over the past month, you may have noticed that some of Edge's features have become faster and more responsive. That's because Edge is on a journey to make all user interactions in the browser blazing fast starting with some of our newest features and core features. Starting with Edge 122, the Browser Essentials UI is now much more responsive. The UI is now 42% faster for Edge users and a whopping 76% faster for those of you on a device without an SSD or with less than 8GB RAM!



Favorites is another Edge feature that's getting UI responsiveness improvements in Edge 124. Whether favorites are expanded or collapsed, the experience should be 40% faster. And this is just the tip of the iceberg. Over the coming months we will continue to ship responsiveness improvements to many more Edge features including history, downloads, wallet and more. We'd love for you to try Microsoft Edge and let us know what you think. Tell us about your experience by using the feedback tool in Edge: click Settings and more (...) > Help and feedback > Send feedback. Read on for more details on how we made this all possible.

Monitoring UI responsiveness​

Edge's UI responsiveness improvements started with understanding what you, our users, were experiencing. Edge monitors its UI responsiveness via telemetry collected from end users' machines.  We intentionally did this collection for all the parts of the Edge UI, not just for the web pages that we render.  What did we learn from this data?

• 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.

We are constantly learning more about how we can improve the performance of the Edge UI and, by using this data, we discovered some areas of improvement.  For example, we observed that the bundles of code that many of our components used were too large. We realized that this was due to two main reasons:

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​

Why are we sharing this ancient news? After all, a lot of web pages have been rendering on the client-side for years. Well, it turns out that JavaScript must be downloaded, then run through a JIT compiler (even if you don't use it), and then executed, and all this must be done before any of the JavaScript can start rendering the UI. This introduces a lot of delay before users can see the UI, especially on low-end devices. If you turn back the time machine prior to the Web 2.0 era, the way web content was rendered was by using HTML and CSS.  This is often referred to as server-side rendering, as the client gets the content in a form that's ready to render. Modern browser engines are very fast at rendering this content so long as you don't let JavaScript get in the way. Based on this realization, our questions became:

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?

The answers to these questions are Yes, Yes, and Very Fast.

Introducing WebUI 2.0​

The result of this exercise is an Edge internal project that we've called WebUI 2.0. In this project, we built an entirely new markup-first architecture that minimizes the size of our bundles of code, and the amount of JavaScript code that runs during the initialization path of the UI. This new internal UI architecture is more modular, and we now rely on a repository of web components that are tuned for performance on modern web engines.  We also came up with a set of web platform patterns that allow us to ship new browser features that stay within our markup-first architecture and that use optimal web platform capabilities. Browser Essentials is the first Edge feature which we converted to test the new architecture and to prove that the concept worked, especially on all types of devices. We're in the process of upgrading components of the Edge user interface to WebUI 2.0 and you can expect to see more features of the browser getting far more responsive over time. We hope that more websites start moving in this direction of markup-first, small bundles, and less UI-rendering JavaScript code. Over time, we plan on making some of our packages open source, so that all developers can benefit. Finally, as we continue improving WebUI 2.0, we're committed to finding opportunities to improve the web platform itself even more. We hope you enjoy this upgraded Edge experience!

Source: An even faster Microsoft Edge

It's great to see Microsoft Edge's commitment to improving user experience with faster and more responsive features. The advancements in UI responsiveness and the introduction of WebUI 2.0 sound promising for enhancing performance across various devices. The focus on optimizing code bundles and reducing reliance on client-side rendering is a step in the right direction towards faster browsing experiences. It will be interesting to see how these improvements continue to evolve and potentially influence web development practices. Kudos to the Edge team for their dedication to enhancing the browser experience!