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.
The first IE9 Platform Preview unveiled IE9’s initial support of SVG. As explained previously, SVG is a vector image format managed by the W3C. The release of the third and fourth Platform Previews come with feature-complete SVG. Major additions include support for SVG gradients, patterns, clipping, and masking. These features are often used to create images with depth and texture and are typically found in more complex SVG files. Just like the rest of SVG in IE9, the newly added features are fully hardware accelerated. This results in impressive performance especially for computationally complex features such as clipping and masking. We continue to work with the SVG Working Group to resolve ambiguities in the SVG 1.1 2nd edition specification and to ensure that IE9’s SVG implementation is interoperable.
SVG’s benefits are multifaceted. It’s an incredibly flexible and powerful format that is ideal for a variety of use cases. Here are just a few of the reasons why SVG can play a critical part of the HTML5 web:
1. Scale-ability
An obvious benefit of SVG is scalability, as evidenced by the name Scalable Vector Graphics. This makes it an ideal format for maps, charts, and graphs – graphics where the detail is as important as the overall picture. With SVG, the fidelity of the graphic is maintained at all resolutions. A company logo or website icon can be created once and used many times in different places or sizes. The same image no longer needs to be saved at multiple resolutions, each tailored towards a specific purpose. Maps often need to be viewed as a whole in addition to being able to selectively see sections in detail. Currently, a common format for maps is a PDF file. This format makes it easy to to scale the map to different sizes,print at many resolutions with full fidelity, and provides the user with the ability to search within the document. SVG has all of these positive qualities natively supported; no plugins are required. Preset views of the same document can even be defined to make navigation to different sections simpler.
How do we decide whether to implement a feature that isn’t included in a standards specification? Like all browser providers, we often have to make this decision. In this post, I’ll use some real-world JavaScript examples to illustrate some of the principles we use to deliver an interoperable browser when the standards specification isn’t enough.
In an ideal world, a standards specification is the complete story. A JavaScript implementation would just include everything in the ECMAScript specification and nothing more. We believe that specifications published by standards organizations such as Ecma International or the W3C are essential for interoperability among web browsers. Ideally, such specifications tell the browser implementers what features they need to provide and tell web developers what features they should be able to use.
In the real world of the web, things are not so clear-cut. Specifications are seldom perfect and sometimes they are intentionally incomplete or ambiguous. Having served as editor for the ES5 specification, I know that there are always issues that don’t get fully resolved. The result is that there are widely implemented and used features that are not defined by any standard specification. If you are trying to build a browser that runs the existing web you have to implement many features that are not defined by a standards specification.
We built Chakra by carefully following the ECMAScript 5 (ES5) specification including the grammar for regular expressions. But when we started testing on actual web sites we started seeing pages not work because of syntax errors on some regular expression literals. For example, we failed on regular expressions containing a right square bracket such as:
next = /]/.exec(buffer);
IE has traditionally drawn a 2-pixel border around the content area of a site. This border, drawn as part of the page rather than IE’s frame, affects calculations of distance from the top and left of the page. It also creates a not-so-modern beveled look.
In the fourth Platform Preview, you’ll notice pages running in IE9’s Standards Mode no longer have the border. Here’s a before and after:
IE9 introduces support for the CSS3 Color Module, including its popular opacity property. As we have done with other standards-based features, opacity is implemented so that the same markup used in other browsers just works in IE9’s standard mode.
Internet Explorer 8 and earlier versions implemented an alternative mechanism to apply opacity using the alpha filter of the IE-specific filter property. This creates a compatibility challenge because IE9’s standard mode supports only opacity and not the alpha filter. (IE9’s compatibility modes Quirks, 7, and 8 still support the alpha filter but do not implement opacity.)
For sites that use best practice feature detection, this is not a problem. They will detect that opacity is supported in IE9 and use it instead of filter. The problem is with sites that use browser detection and mistakenly assume that IE always uses filter alpha instead of opacity and then change only the filter property in script. The opacity effect will appear broken in those Web pages when run in IE9’s default 9 document mode. The fix is to detect the standards-based opacity feature first and browser-specific filter feature second as we’ve described in previous posts.