次の方法で共有

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: Becausemost 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

  • Anonymous
    August 30, 2010
    Great article thanks Jason - one of the best I have read on the IUEBlog!

  • Anonymous
    August 30, 2010
    The comment has been removed

  • Anonymous
    August 30, 2010
    The comment has been removed

  • Anonymous
    August 30, 2010
    "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 :)

  • Anonymous
    August 30, 2010
    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.

  • Anonymous
    August 30, 2010
    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.

  • Anonymous
    August 31, 2010
    The comment has been removed

  • Anonymous
    August 31, 2010
    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?

  • Anonymous
    August 31, 2010
    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!

  • Anonymous
    August 31, 2010
    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.

  • Anonymous
    August 31, 2010
    The comment has been removed

  • Anonymous
    August 31, 2010
    @ 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. Cheers Harry

  • Anonymous
    August 31, 2010
    The comment has been removed

  • Anonymous
    September 01, 2010
    thanks.I need it.

  • Anonymous
    September 04, 2010
    The comment has been removed

  • Anonymous
    September 12, 2010
    The comment has been removed

  • Anonymous
    September 12, 2010
    The comment has been removed