Timers: death by a thousand cuts
Even on a page that looks relatively quiet, below the surface there may be quite a lot of work going on. News and content sites that rely on advertisements, analytics trackers, and scroll listeners are often a good example of this. For instance, here’s a sample site illustrating some problems we often see on poorly optimized sites in the wild:
While this page is loading, and even well after it’s “settled,” there is still an enormous amount of work going on under the hood. A web page such as this one may make network requests for additional resources, or it may call
setTimeout to queue a task for the next “tick” of the event loop. Each of these callbacks can then schedule other timeouts and network requests, starting the process anew. It’s the browser’s job to coordinate these tasks, and to ensure that they’re processed correctly along with event listeners, Promises, and any other work in accordance with the HTML5 event loop spec.
Input blocking: the “Is this page broken?” effect
You’re probably familiar with this experience: you load a page, and the content appears on the screen, so you believe you can start interacting with it. However, if you try to click a link, several seconds pass by without anything happening. Or you might try to scroll using your keyboard’s up and down arrows, but the page moves at a glacial pace, or it doesn’t even scroll at all.
This often occurred in previous releases of Microsoft Edge on pages that queue up a lot of
For example, the “news site” below is doing several seconds’ worth of work on the UI thread while it’s loading. If you try to click the first link during that load, the navigation may be blocked, because mouse input is not being prioritized.
As of EdgeHTML 15, however, Microsoft Edge now prioritizes the click event ahead of other work, meaning that the next page loads nearly instantly:
Here’s another example showing the impact on scrolling. This page, like the sample news site, is running several
setTimeouts in the background, which can interfere with keyboard scrolling:
As of EdgeHTML 15, the page remains scrollable with the keyboard, even while the
setTimeouts are being processed. This reduces a common source of blocked or laggy scrolling on very active web pages.
Giving priority to the user
To understand what EdgeHTML 15 is doing under the hood to achieve this performance boost, let’s whip up a quick metaphor. Note that, as is often the case, the actual implementation is a bit more complex, but we’ll simplify a bit in the interests of clarity.
With a little help from some illustrations courtesy of Rachel Nabors, we can visualize the way tasks are processed in a web page by imagining a trendy club with a lineup of eager customers stretching out around the block, and a stern bouncer letting in only one client at a time.
In our club metaphor, this would be like a particularly inconsiderate patron calling their friend on the phone to say, “No problem, I can hold your place in the line. I’ll just tell the bouncer you’re on your way!” And then, insult of insults, the bouncer would actually allow them to hold up the entire line, waiting for their friend to show! All the while, the poor input event is still waiting at the back of the line.
As of the Creators Update, though, this lineup has been completely redesigned. Rather than maintaining a single queue to process all events, there is now a priority queue for input events. This is as if our club added a special VIP line, allowing high-profile guests to get in ahead of the thoughtless patron trying to call their buddy.
Prioritizing the browser UI itself over web content
In addition to creating a “fast lane” for user input to web pages, another improvement we made in the Creators Update was to make another special queue for input to the browser UI itself.
You can imagine that, if input is shared between a web page and the browser frame – i.e. the URL bar, tabs, favorite button, etc. – then a misbehaved web page could potentially render the entire browser unresponsive. For some web content, this was the situation before the Creators Update, but now Microsoft Edge is more intelligent about handling browser UI input separately from web page input.
In the Creators Update, however, browser UI input has been given special priority, allowing the user to close a misbehaving tab without waiting for it to respond. Note that this input is handled even earlier than the in-page user input. For instance, in the case of an infinite loop (another fun option on crashmybrowser.com), input to the web page itself would never be handled, but input to the browser UI itself should be able to respond regardless of what the web page is up to.
Circling back to our trendy club example, this special treatment of browser UI input would be like a hidden side entrance to the club, only available to members of the band and their entourage. While VIPs may get first dibs to line up into the club, the band is even more important! So they should be able to fast-track into the green room.
Real users see web content responsiveness improvements
To see the impact of this work on web content responsiveness, we can look at aggregated telemetry from EdgeHTML 15 Windows Insider devices, comparing November builds (before input prioritization was implemented) to March builds (after it was introduced). For interactions, we broadly bucket responsiveness into “great” sessions (<300ms), “poor” sessions (300-1000ms), and “terrible” sessions (>1000ms).
As you can see in the above chart, Microsoft Edge has increased the number of “great” sessions from 88.71% to 95.53%, while decreasing the number of “poor” sessions from 5.68% to 3% and the number of “terrible” sessions from 5.61% to 1.46%.
The confirms that Microsoft Edge users are seeing the benefits of this input prioritization effort firsthand. For most sites, users have a great session. However, when a site is bad, it can be a terrible experience. Aggregated Windows telemetry clearly shows that the input prioritization improvements in the Creators Update have significantly reduced the number of less-than-great sessions on heavy websites.
All these input changes serve one unique purpose: to put users in control of their browsing. Regardless of what a web page is trying to accomplish, the user should be able to interact with their browser and manage their tabs, scroll their content, and navigate to new pages as fast as their fingers can move. With these improvements in the Creators Update, Microsoft Edge users will enjoy a faster, more fluid, and more responsive browser.
As Bret Victor famously said, “creators need an immediate connection to what they’re creating.” This is true not only of creators but also of web surfers: when you type or click, the web page should immediately respond. This responsiveness helps maintain the most immersive aspects of the web, and creates a strong visceral connection between the user and their browser. Immediate feedback is crucial not only for creative flow, but also for seamless web surfing. With the Creators Update, Microsoft Edge has made a big step in achieving that vision.
Updated June 1, 2017 11:38 am