Performance: Profiling how different web sites use browser subsystems

When we first showed IE9 at the Professional Developers Conference last fall, we discussed how real world browser performance involves many different subsystems. Different websites use these subsystems in different ways, and to build a fast real world browser you have to start by understanding these overall patterns. This post provides an inside look at how these subsystems impact the performance of five real world websites. We use Internet Explorer 8 for this analysis, and as IE9 approaches we’ll talk more about how these performance characteristics evolve.

All modern web browsers are conceptually similar. Browser vendors have different priorities (for example, supporting many different operating systems or optimizing for one). Browser vendors also have different engineering approaches which influence their programming languages, tools, and processes. When you step back from the specific engineering details though, all modern browsers connect to a server and execute the same markup and script. They all essentially do the same thing to enable customers to interact with web sites.

Browser Subsystems

The Internet Explorer web platform is composed of 11 core subsystems. All modern browsers provide these capabilities, and while the names and component boundaries vary slightly between browsers, the process is nearly identical.

Progression of IE subsystems.  Networking --> HTML --> CSS --> Collections --> Javascript --> Marshalling --> Native OM --> Formatting --> Block Building --> Layout --> Display

Here’s a brief overview of these subsystems in the order they’re encountered when you load a web site:

Networking: The first subsystem generally encountered is networking. The networking subsystem is responsible for all communication between the client and server, including local caching of web content. The networking subsystem is generally gated on the performance of the user’s network

HTML: As HTML documents are downloaded from the server they’re passed to an HTML subsystem which parses the document, initiates additional downloads in the networking subsystem, and creates a structural representation of the document. Modern browsers also contain related subsystems which are used for XHTML, XML and SVG documents.

CSS: When CSS is encountered, whether that’s inside an HTML document or a CSS document, it’s passed to a CSS subsystem which parses the style information and creates a structural representation that can be referenced later.

Collections: HTML documents often contain metadata, for example the information described in the document head or the attributes applied to an element. The collections subsystem is responsible for storing and accessing this metadata.

JavaScript: When script is encountered, it’s passed directly to the JavaScript subsystem which is responsible for executing that script. The JavaScript subsystem is probably the most well-known of the browser subsystems thanks to the visibility it has received over the last few years.

Marshaling: Because most JavaScript engines are not directly integrated into the browser, there is a communication layer between the browser and the script engine. Passing information through this communication layer is generally referred to as marshaling.

Native OM: JavaScript interacts with the document through the Document Object Model API’s. These API’s are generally provided through a subsystem which knows how to access and manipulate the document and is the primary interaction point between the script engine and the browser.

Formatting: Once the document is constructed, the browser needs to apply the style information before it can be displayed to the user. The formatting subsystem takes the HTML document and applies styles.

Block Building: CSS is a block based layout system. After the document is styled, the next step is to construct the rectangular blocks that will be displayed to the user. This process determines things like the size of the blocks and is tightly integrated with the next stage – layout.

Layout: Now that the browser has styled the content and constructed the blocks, it can go through the process of laying out the content. The layout subsystem is responsible for this algorithmically complex process.

Rendering: The final stage of the process occurs inside the rendering subsystem where the final content is displayed to the user. This process is often referred to as “drawing to the screen” and may occur on the CPU, the GPU, or a combination of both.

As we’ve mentioned, different websites use these subsystems in different ways. Even websites that provide similar functionality, for example some of the world’s largest news websites which provide comparable experiences on their home pages including headlines and video, have very different performance characteristics.

Profiling News Sites

To help you understand what we mean, we took five of the world’s largest news websites and profiled them loading inside IE8 using the Windows Performance Tools. We do this in a controlled environment to remove external variables and we load each site multiple times to ensure high confidence with the results. We factor out networking performance from these charts because that’s user dependent. This approach allows us to see how long it takes the browser to load the web site and the breakdown of CPU time across subsystems. In the below chart, you can see that it took between 1,117 and 3,704 milliseconds to load these five pages – that’s between 1.1 and 3.7 seconds. The color coding represents the browser subsystem where the time was spent.

Chart of subsystem Breakdownfor Common News Sites

There are some revealing patterns in these results. For example, News Site #1 spent the majority of the time in JavaScript, News Site #2 spent the majority of the time in Marshaling, and News Site #5 spent the majority of time in the Layout process which includes Formatting and Block Building. For each website a different subsystem made the largest impact on performance.

It’s also interesting to see how much control the web developer has over their own site’s performance. Even though News Site #3 provided a comparable experience to their competitors, they follow performance best practices and the site is quickly loaded in just over a second. In contrast, News Site #4 doesn’t follow many best practices and takes over three times as long to load.

When we average these results together we can start to understand the relative impact each subsystem has across news sites. As you see below, every subsystem plays an important role in the performance of these News Sites with JavaScript (29%), Marshalling (18%) and Rendering (17%) making the largest impact.

Chart of amount of time inside each browser subsystem on News Sites

Profiling Top AJAX Sites

News sites provide one view into how performance is multidimensional; however it’s important to look at other classes of web sites to see how these patterns change. When we perform the same analysis on the world’s top 25 AJAX sites, including some of the most sophisticated JavaScript applications like Facebook, Gmail and Hotmail, we get the following results.

Chart of Amount of time inside each browser subsystem on AJAX sites

As you can see the distribution has shifted slightly. Some subsystems including HTML, CSS and JavaScript become relatively less important and other subsystems including Formatting, Layout, Block Building and Rendering become extremely important. This can be surprising at first since most people associate AJAX sites with JavaScript. When you think about the patterns inside AJAX sites though, these results make sense. Inside most AJAX sites you generally have a small amount of JavaScript that manipulates the document. Once that script executes, the browser needs to go through almost all of the subsystems for that change to become visible to the user. That process is generally more expensive than executing the script itself.

You can see that performance of AJAX sites is also multi-dimensional and impacted by all of the subsystems in the browser. For AJAX sites, the most important subsystem is rendering which accounts for 31% of the time, followed by the JavaScript subsystem which accounts for 21% of the time. It’s interesting to see how JavaScript subsystem performance has proportionately more impact when loading a web page than when interacting with an AJAX site.

Bringing It All Together

To build a fast real world browser you have to understand how different browser subsystems impact performance in real world scenarios, and you have to focus on the subsystems that matter. For AJAX sites, that means focusing on Rendering (31%), JavaScript (21%), Formatting (14%) and Layout (12%). For news sites, that means focusing on JavaScript (29%), Marshalling (18%) and Rendering (17%).

With Internet Explorer 9, we worked on building the right foundation across the browser to ensure developers have a reliably fast platform. Over the last few months we’ve talked about some of the fundamental changes we made including hardware accelerated graphics, compiled JavaScript, and natively integrating JavaScript directly inside the browser. As we get closer to the IE9 beta we’ll talk more about how these subsystems come together in IE9 to change the performance characteristics compared to today’s generation of non-hardware accelerated browsers including IE8.

Jason Weber
Lead Program Manager, Internet Explorer Performance

Comments (17)

  1. Mike McGrath says:

    Great article thanks Jason – one of the best I have read on the IUEBlog!

  2. jabcreations says:

    The profiler tab in the developer tools is great for a breakdown of JavaScript performance however are there currently any tools for us to use to analyze the subsystem performance of our sites?

    Even if putting script elements in to the body instead of the head gains small amounts of performance it ultimately leads to sloppy coding ethics such as using document.write and innerHTML.

  3. Shiv Kumar says:

    Hi Jason,

    Great article indeed. I remember seeing this before (at MIX probably?) but it was good to be able to digest the info, cause there is a lot here and the implications to not only browsers vendors but to site designers is huge.

    I wanted to to take this opportunity to say that I think you guys have doing a fantastic job with IE. I just want to see this browser out and in use so we can get moving on designing our sites for Html 5. the other thing that has impressed me quite a bit is the performance of html 5 video in IE 9. I'm part of the ExposureRoom team ( and we have been developing our Html 5 video player, making it such that it works across all major browsers. Barring a few bugs (that's I've meticulously reported) and finding work arounds, I'm happy to report that we have a fully functional html 5 player that will work across all browsers, supported pretty much all the features one would expect in a video player including:

    1. Full screen

    2. Skip ahead/back

    3. Changing the source while a video is playing

    4. A lot more

    The full screen in IE has a small bug (also reported) that when fixed will make IE stand apart from the rest since the performance (the ability to play back really high quality video effortlessly is tremendous. you can find the results of my test here…/html-5-video-and-flash

    One more thing, if IE 9 supports WebM out of the box it would be the best browser for html 5 today. Chrome supports H.264, Ogg, and WebM but the performance of their video player sucks. So please think real hard about out of the box support for WebM because you'll make everybody's lives a lot better.

    A more detailed report can be found here…/1048

    And soon, we'll be releasing our Html 5 player to our site visitors and members.

  4. Jan Wikholm says:

    "As you can see" is not an accurate assumption when using pie charts. Please, for the love of <gods/>, stop using them :-) Otherwise a brilliant post, but I would rather see the data in a better graphical visualisation — the first chart was promising :)

  5. Toni says:

    Very interesting post. I agree with Jan, use Bar Charts – the pie charts are useless!

    One thing that is unclear is how you collected the data for subsystem with the profiler. Would have been great if you gave step by step instruction on how to collect it.

  6. says:

    Great article.

    I agree with a couple others above – a tutorial on how to profile subsystem performance for web apps/sites would be very useful.

  7. Jace says:

    I like pie charts :-) With fall approaching, I expect to be closely associated with some vegetarian pie charts soon. Pumpkin, apple, cherry…

  8. Ryan says:

    Can you guys explain what 'rendering' is and how it's affected? What affects rendering time? Too many DOM nodes? Too many CSS rules? JavaScript changing the page before load?

  9. Drake92 says:

    Pie charts are wrong. Should start at 0 degrees with highest percentage item first, then go around clockwise in descending order. Let's hope more attention was paid to the browser's development!

  10. MisterW says:

    What about the real world of the future? IE, being the browser with the largest market share, controls to some extend how the future web applications will look like, so IE should improve on all fronts, even on those which don't play a big role on current web sites.

  11. AM says:

    This is a nice article, it will be really nice if the developer tools in the new IE9 can build the same chart, or at least give the time for each layer; this will help many developers improve their web applications.

    It reminds me of “Show execution plan in SQL server” :-)

  12. Harry Richter says:

    @ Drake92

    If you like pie charts or bar charts, that is a matter of personal preferencies. Having said that, the pie charts in this article are NOT wrong, as they are in order of occurence, , starting as you've said at 0 degrees, continuing clockwise, which makes much more sense.



  13. hAl says:

    @ Shiv Kumar

    Using WebM would make a lot of people unhappy.

    It uses more significantly bandwith for the same video. Especially anoying is you have a limited 3G subscription.

  14. giuseppe says:

    @ jabcreations (30 Aug 2010 6:52 PM)

    i totally agree

    @ Shiv Kumar (30 Aug 2010 8:40 PM)


    "we have a fully functional html 5 player that will work across all browsers, supported pretty much all the features one would expect in a video player"

    I wonder why it silently fails in firefox 3.6.

    And "all browsers" is an inclompletely defined set.

    "1. Full screen"

    No. No fullscreen as suggested by spec. That's probably why your player doesn't have fullscreen. As I am sure you already knew that, I wonder why you wrote something different. Maybe you should review your advertising text.

    However, you could hide the scrollbar(s) of the containing page while in 'fullwindow' mode, and hint the user to how to toggle browser fullscreen mode. Oh, and fixed positioning for the maximized player would seem like a good idea to me.


  15. Shiv Kumar says:


    Rather than waste bandwidth with you pointless comments, I'd ask that you add value to this conversation (if you have anything of value to add that is).

    The player is fully functional in all major browsers. Yes, I should have been clear about that means. However, one would assume if the browser in question does not support the html 5 video element completely, then testing with it would be a moot point, no? I mean a little bit of common sense is all it takes, so I suggest you use it, why don't you? May I suggest using the beta version of Firefox since it's support for the html 5 video element at this time is more complete?

    Full screen:

    The spec? Man, what a joke! It's not about the specs. Since when have specs met all the requirements? And certainly, the Html 5 video specs lack badly in this regard. Again, the idea is that one can go full screen. So a little bit of common sense will go a long way.

    Now as regards the specs on the Full Screen aspect. Read it and you'll soon discover that the spec the way it is, is useless. It implies that either you can't build your own skin/player or they expect users to right-click to get access to the option. The issue with that is that most video websites would want to have their own player and most users won't think to right-click to get the full screen option. Besides, most websites will block the right click option anyway.

    Safari has gone against the so called "spec" and provided a programmable interface that they in turn ensure has been called using a user gesture. Oh, and guess what, we use it too.

    Keep in mind that the reason we have the mess that we do as regards browsers and meeting specs is that the specs have never been enough. They’ve never addressed the real needs and they’ve not been explicit enough when that needed to.

    Another “spec” joke is the poster attribute for the video element. It’s completely useless. So much so that any website that has implemented their own Html 5 video player doesn’t use it. Or they have to find other in order to be able to use it like not setting the source of the video element so the poster doesn’t vanish after about half a second.

    Oh, and if it's all about showing how smart you are, then yes, please have the last word.

  16. Giuseppe says:

    @Shiv Kumar 12 Sep 2010 9:24 PM

    sorry, i didnt mean to insult you, neither did i intend to 'show how smart i am' (because i am not). i wanted to be concise. still i thought i added value. maybe i failed. and i should have mentioned that i examined the player from a user's point of view, rather than a developer's. finally i should have pointed out that the rest of the player, the whole site and also the 1.5 short movies i watched are very nice, but i didnt want to have nested off-topics for brevity's sake.

    but let me try again:

    "we have a fully functional html 5 player that will work across all browsers, supported pretty much all the features one would expect in a video player"

    a visitor that loads your page does not get an error message or fallback when his browser does not support the video element. it silently fails, and visitors usually dont like this. I am, and was, aware that switching to the html5 video player had to done explicitely by the visitor, but what i wanted to imply (and should have done in a more clear and friendly way) is that a "fully functional html5 player" should provide some kind of fallback. no piece of software should fail silently.


    i did not rate the practicality of the spec concerning fullscreen to stay more objective. of course, fullscreen is absolutely necessary for video content. personally i favor safari's approach, but only the 'right click' triggering of fullscreen complies to the spec in its current state. i would like to see the spec changed towards allowing the safari way, but i cannot demand so due lack of insight on the security implications (can a user be tricked into clicking the 'button'? can the 'button' be styled (see input[@type='file'])? etc.).

    maybe i should have applied common sense and used safari until other browsers follow their way of even the spec is changed, but again, a regular visitor would not know about the fullscreen case, and thus get unexpected result.

    "It implies that either you can't build your own skin/player or they expect users to right-click to get access to the option"

    that's where we are today. but the user could be informed about the right-click possibility (like 'press escape to exit fullscreen' seen on some flash video players). And/or you could inform the user how to enable the browser's fullscreen mode (e.g. F11).

    "hide scrollbars" and "fixed positioning"

    i thought by this, as by the former suggestions, you could improve your html5 video player. and to introduce a tiny bit of criticism, i really don't see how that was pointless. however, i should have expressed myself more clearly and polite.