Focusing on Real World Web Performance with Internet Explorer 9

One engineering objective of Internet Explorer 9 is to build the world’s fastest browser. Browser performance matters to everyone. Consumers, enterprises, developers, and the technology industry share a desire for a faster and more capable Web platform.

To build the world’s fastest browser we focused on the real world Web performance metrics that matter to customers. Web performance is a complex and nuanced problem and while some in the industry have become distracted with artificial performance benchmarks, which only measure one aspect of the browser, we have remained focused on the real world scenarios that matter to customers.

As we near the close of the Internet Explorer 9 development cycle, now is a good time to look at the five performance objectives we focused on this release. These performance objectives formed the core of our work including architectural changes to support hardware accelerated graphics, compiled JavaScript, and native JavaScript integration, along with over 2,000 targeted performance optimizations like our caching improvements.

Five Internet Explorer 9 Performance Objectives:

  1. Display Time: Perform user actions faster than any modern browser
  2. Elapsed Time: Execute Web site code faster than any modern browser
  3. CPU Time: Effectively scale computation better than any modern browser
  4. Resource Utilization: Require less overall system resources than any modern browser
  5. Power Consumption: Require less power than any modern browser

We believe being the world’s fastest browser means being best in breed at all five of these objectives across the real world scenarios that matter to customers.

Visualization of IE9 Performance Objectives

Let’s take a closer look at what each of these five objectives means through the scenario of loading a large sports site over a DSL connection for the first time. The above diagram shows what happens on the CPU while the sports site is loading, important points along the way, and how these map to our objectives. We use these same metrics for complex AJAX/Web2.0 JavaScript applications as well.

  1. Display Time
    The most important objective is what we refer to as “Display Time.” This has many names across the industry including “time to glass” and “primary paint.” Display Time measures the time from when the user performs an action until the user sees the result of that action on the screen. In the case of the sports site, this is the duration from when the user navigates to the site until when the site is visually complete loading. Our objective is to display the results of these user actions faster than any browser, providing customers with real-time responsiveness.
  2. Elapsed Time
    Most sites continue to perform work in response to the user action after the content has been displayed to the screen. This might include downloading user data (e.g., email messaging) or sending analytics back to a provider. From the users’ perspective the site might appear loaded, however significant work is often occurring in the background which can impact responsiveness. Our objective is to execute the Web site code (HTML, CSS, and script) more efficiently than any browser—making sites load faster, Web experiences more responsive, and enabling Web developers to create richer experiences.
  3. CPU Time
    Web browsers are almost exclusively limited by the CPU. What work a browser performs on the CPU and how efficiently that work occurs will make the single largest impact to performance. That’s one of the reasons offloading work to the GPU has made such a significant impact to IE9’s performance. The amount of CPU time required to perform the action and the CPU efficiency are critical. Our objective is to more effectively use the CPU and leverage multiprocessor architectures better than any browser.
  4. Resource Utilization
    Building a fast browser means ensuring resources across the entire PC work well together. This includes network utilization, memory usage patterns, GPU processing, graphics, memory, and hundreds of other dimensions. Since customers run several applications at the same time on their PC, it’s important for browsers to responsibly share these resources with other applications. Our objective is to effectively use system resources like the GPU while requiring less system resources (including working set, CPU load, and GPU load) than any modern HTML5 browser.
  5. Power Consumption
    When utilizing the underlying PC hardware it’s important to take power consumption into consideration. The more efficiently a browser uses power, the longer batteries will last in mobile scenarios, the lower the electricity costs for operating the device, and the smaller the environmental impact. Power and performance are complimentary goals and our objective is to require less power than any other browser without compromising performance.

Internet Explorer 9 Beta was a great step toward achieving these goals. What’s coming next will provide an equally significant step forward. Over the next few weeks we’re going to talk more about each of these five objectives, discuss how we measure progress against these objectives, and share our internal engineering analysis. First, though, we’re heading to San Francisco.

—Jason Weber, Lead Program Manager, Internet Explorer Performance

Comments (19)

  1. Speedy says:

    I have to say that the beta is speedy in my usage. Looking forward to the RC – glad it's coming soon

  2. Raffi21 says:

    I noticed a lot of browsers show performance degradation the longer the page has been running.  If you run some sort of JS benchmark over and over without reloading the page, it gets progressively slower.  I don't know what the reason is, maybe memory fragmentation or the JS garbage collector or something.  Firefox seems particularly bad at this.

  3. temp says:

    Do you also have plan for a better bookmarks manager ?

  4. Toni says:

    Jason – Can you programatically get what the Display Time is, either via JavaScript – or in the case of hosted control, C#/C++ etc? In other words is this available to web and software developers?

  5. thenonhacker says:

    @Temp: I like that Chrome associated the "New Tab" action with their "Bookmarks Toolbar". It's making "New Tab" the new "Open Webpage" dialog.

    Internet Explorer 9.5 or 10 can capitalize on this basic idea:

    – Clicking New Tab will bring out an "Open Webpage" Backstage.

    – At the right side is the list of recently opened pages, and a link to view the full History.

    – At the left side, a big area dedicated to search and pick from your Favorites Folder. Maybe make this act & look like the Windows Start Menu?

    – At the top is the Favorites Toolbar links just like Chrome. You can drag link to the Favorites Toolbar within this Backstage.

  6. Arieta says:

    In b4 copypasta

    Dear IE Team, I'd like to ask a few questions – though I know they'll get answered in two days, but I'm very curious:

    – Will it be possible to have tabs in their own bar again? There just isn't enough space for multiple tabs in the Beta.

    – Will it be possible to move the bookmark/home/settings buttons to the left side, and not the right side of the browser screen? It makes no sense to put them in the right corner: all other controls are already on the left side!

    – Will it be possible to disable font smoothing? This is the only single reason why I can't get pixel-exact display in all browsers, because IE9 smooths out fonts very unnecessarily.

  7. Stifu says:

    @Arieta: "This is the only single reason why I can't get pixel-exact display in all browsers"

    Ah, how did you get fonts to look the exact same on Linux, Mac, and other OSes?

    The web isn't about pixel perfection. If that's what you're trying to achieve, you're missing the point.

  8. Aethec says:

    There's a sixth point you need. Rendering fonts the same way modern browsers do, whatever the GPU. I don't know if that is achieved by fixing IE9 or DirectWrite, but you have to do it.

  9. IEFan says:

    Will users be able to remove the Home and Favorites buttons? I use a Delicious bookmark as my "home button" and I also use the Favorites Bar, so I have no need for either of those buttons. Removing said buttons would allocate more tabs space.

  10. Aethec says:

    @IEFan : +65535. I don't use them either.

    Another good thing would be to allow add-on developpers to put buttons near the Home/Favorites/Settings button. Currently, adding one button to IE9 means adding a whole toolbar.

  11. EricLaw [MSFT] says:

    @Toni: Have a look at…/ff975118(v=vs.85).aspx for one interesting new object available for collecting timing information, introduced in IE9.

  12. Arieta says:

    Stifu: I embed my own fonts to the site. I didn't check them on Linux and Mac, but that counts for less than 5% of my viewers, and Firefox SHOULD render them the same as nothing on the site depends on the OS. The only real difference I have is text-align justify having some differences in text-heavier modules, and border-radius behaving differently in all browsers.

  13. Jawed says:

    @Arieta: Yes, there will be an option to show tabs below the address bar in the RC (as it happens, combining Platform Preview 7 with the Beta will also enable the option).

  14. Petr says:

    @Arieta I can sign below the first two points. I would love to see the tab bar (also) in the window's title bar where there is plenty of unused space.

  15. Alexey says:

    Before installing this, I would like to know, whether the IE team has fixed the user interface, at least with with the possibility of having tabs in a separate row and search in a separate field. The beta IE9 UI was unusable.

  16. The IE9 RC is slow to load XML files. I need the PDBs to see details in the Xperf trace. When can we see the PDBs on the Symbol server?

  17. Björn says:

    @Arieta: Tried the Firefox 4 beta yet? Same font smoothing as IE9.

  18. marcuscf says:

    Does it still take 2 seconds to open a new **empty** tab? It's so slow it's infuriating.

  19. Glenn says:

    In both the RC & Beta, I experience a problem clicking a link from within a Web Page.  Example on RC from the Blizzard Hoime Page then clicking on Diablo III then when it goes to the next page the upper tab says Diablo III with a spinning circles.  On the Beta if I went back to the original page and tried it again it would bring the page up on the 2nd try.  The RC isn't doing it.  I would also like to see the Favorites Tab back on the Toolbar.