Microsoft explains how Microsoft Edge defeats laggy web pages

Microsoft Edge got a couple of new features with the Windows 10 Creators Update in April. Along with all the new features, Microsoft makes significant improvements behind the scenes to improve Microsoft Edge’s performance and stability. These improvements were mostly added to the browser engine of Microsoft Edge known as EdgeHTML. With the release of EdgeHTML 15, Microsoft made substantial improvements to how some of the JavaScript operations are handled on a web page to improve the responsiveness of input on web pages, as well as the actual browser UI of Microsoft Edge.

With EdgeHTML 15, Microsoft Edge now prioritizes input events over some of the other JavaScirpt operations such as setTimeout(). Microsoft Edge engineers implemented a new schedule into EdgeHTML 15 that allows inputs to be prioritized over setTimeout, making sites more responsiveness. In other words, if you visit a website that uses a lot of setTimeouts, you’ll now be able to interact with the site’s links and other elements even before those setTimeouts are executed. This will also make scrolling in web pages much smoother, as you’ll be able to start scrolling on a page as soon as it loads while the setTimeouts are being handled by the browser.

Another substantial improvement Microsoft made to Edge with EdgeHTML 15 and the Windows 10 Creators Update is prioritizing the browser UI. Microsoft Edge and EdgeHTML15 now prioritizes inputs in the browser UI over the in-page events. Put simply, this will make sure the actual browser UI of Microsoft Edge continues to function even when a web page starts to lag because of things like infinite loops, or ridiculous amounts of timeout functions. As a result, when a web page starts to lag, you will still be able to interact with Edge’s browser UI (the address bar, tabs, new tab button, favorites button, etc.):

Microsoft says the improvements to how input events are handled by Edge resulted in an increase in the number of great responsive sessions (less than 300ms response time) to increase from 88.71% to 95.53%. The improvements also brought down the number of sessions with poor responsiveness (between 300ms and 1s response time) from 5.68% to only 3% and sessions with terrible responsiveness (more than 1 second response time) from 5.61% to a mere 1.46%.