We’ve had 10 million downloads in the six weeks since we released the IE9 beta. That popularity reflects the significant improvements in browsing that IE9 brings to the web. Users can pin sites directly to the Windows task bar, and sites can program jump lists and offer notifications just as Windows applications do. The web standard markup (HTML, CSS, and script) in pages runs faster and smoother, taking advantage of modern PC hardware.
The popularity of the beta also reflects the early exposure to and extensive impact on IE9 that developers have had. Developers downloaded the first five Platform Previews over 2.5 million times. The sixth Platform Preview of Internet Explorer 9, available now, reflects developer feedback and delivers better performance as well as more standards support, like CSS3’s 2D transforms:
var videos = document.getElementsByTagName(‘video’);
if (videos.length != 0) {
if (videos[0] && videos[0].canPlayType && !videos[0].canPlayType(“video/mp4”).match(/^(probably|maybe)$ /i)) {
for(i=0;i
Testing Performance across Browsers
We think people should evaluate performance with real-world scenarios. Real-world scenarios involve using all the subsystems in the browser together rather than looking at single subsystems in isolation. For example, the IE Test Drive site offers samples that deliberately represent real-world site patterns rather than microbenchmark-style samples. The visualization of the real-world samples is often more fun than a graph, as in browser hunt and speed reading.
Engineers design microbenchmarks to isolate and exercise very narrow and specific aspects of a system. That’s the opposite of real-world websites that use the different subsystems together in order to deliver something useful or entertaining. Measuring the performance of a browser, subsystem by individual subsystem, is inherently flawed because it’s not how real sites work.
The issue isn’t a specific flaw in a particular benchmark, but that the results so often have little in common with the actual user experience of the larger system when browsing sites. Microbenchmarks of ray tracing or Fourier transforms matter a lot if the sites you rely on use them. A ten percent difference in one JavaScript benchmark often translates to no actual difference in real sites. All benchmarks have some variability in measurement. When benchmarks run other benchmarks in turn, the errors often add up instead of cancelling. This post offers a good survey of what several different microbenchmarks measure.
Side by side comparisons of different browsers running real-world samples show significant differences. The new SVG Helicopter test drive shows performance differences between browsers on sites that use SVG and script together with HTML5 audio. In Track splash, you can see the performance differences between browsers when HTML5 video interacts with canvas. This customer model also shows performance differences in SVG when you zoom in and out, a common activity in wading through data. Unfortunately, you can also see differences in how different browsers display the same SVG in the real world samples as well; as an industry we have more work to do so the same markup delivers the same results.
The performance differences between browsers can be striking, and reflect how we’ve designed for end-to-end performance rather than relative performance of particular subsystems like JavaScript or DOM.
Platform Preview 6 continues improvements to individual sub-systems, like the JavaScript engine. One measure of JavaScript performance is the Webkit Sunspider microbenchmark. Here is a chart of the latest results:
The differences between browsers on this microbenchmark are converging within thousandths of seconds on tests that repeat operations many, many times to find any differences at all.
Testing ‘Same Markup’ across Browsers
We think people should evaluate web standards compliance through an industry standard test suite. On the web today, individuals have many choices of tests to assess and use as shorthand for standards support. Unfortunately, each test in its own way is incomplete and has inaccuracies.
We look to the standards body for a test suite to assess the quality and completeness of a browser’s standards support. The W3C’s open and consensus-based approach is the best way to bring the community of browser vendors and web developer and design professionals together in building a comprehensive and accurate test suite.
Today, you can see an early version of the W3C’s Official HTML5 Test Suite Conformance Results on their website. It’s a great example of open and consensus-driven collaboration at work. Anyone can submit tests. The tests are available for public comment. Browser vendors submit their test results for public review. Microsoft has submitted a total of 2853 tests to the W3C across HTML5, CSS3, DOM, SVG, and JavaScript (ECMAScript 5) to date. We’re engaged in the process, taking feedback, and reviewing the tests that others submit as well. We listened to feedback on our previously submitted test cases and updated 53 of them.
Test suites are a crucial complement to specifications. The benefits to consumers are clear looking at USB devices and wireless networking hardware, and the market’s higher expectations around interoperability from those products.
The goal of standards and interoperability is that the same HTML, script, and formatting markup work the same across different browsers. Eliminating the need for different code paths for different browsers benefits everyone, and creates more opportunity for developers to innovate. Developers face a hard challenge today: they need to work harder than they should, to write more and different HTML, script, and markup, just to get similar but not always the same results across different browsers. When developers spend less time re-writing their sites to work across browsers they have more time to create amazing experiences on the web.
In the short term, developers will likely focus on delivering HTML5-enabled sites that work well (as designed, and with good performance) across browsers. That’s a pattern we’ve started to see as sites enable HTML5 video support, and it makes sense. Tuning sites for specific performance characteristics of different browsers may, longer term, make sense for developers as well.
At the IE test drive site, you can try some other samples of same markup running across different browsers. For example, Flickr Postcards shows same markup for CSS3 2D transforms in action. Semantic Notepad shows the same markup for HTML5 semantic elements, and A New Day shows the same mark-up for CSS3 box shadow.
Our investments in standards and interoperability are all about enabling the same markup to just work across different browsers. With IE9, we’re doing for the rest of the web platform what we’ve done with CSS 2.1. Developers should expect more from across the industry on this front in order to make HTML5 applications easier to write.
A Word about IE6 (and Why to Avoid Browser Detection)
People on our team actively work closely with Microsoft customers to reduce IE6 usage, helping them to migrate their key sites so they can switch from IE6 to a browser with better performance, standards support, and safety.
Sites that code browser detection rather than feature detection are one of the hardest obstacles they face.
As an example, someone recently asked me about this page because the site told him that “You are using an out-of-date browser version. Please upgrade! Many features of our new site may not be supported in your browser.”
The page incorrectly detects IE6 by running a script from this file – prompting any IE user running a version other than IE7 or IE8 (“ltIE7 = (client.isIE && !client.isIE7 && !client.isIE8)”).
You can see similar patterns in many other pages around the web. For example, this page incorrectly initializes a canvas library for users of any IE version, rather than using IE9’s native canvas support.
Sites that use feature detection are better off. As browsers and standards change over time, these sites will continue to work, and as a community we avoid part of the “IE6 phenomenon” of sites hard-coded to browser specific behavior.
F12 Developer Tools and Formatting Minified Script
To make the F12 Developer Tools even more convenient, we’ve added a feature in Platform Preview 6. Many developers minify their JavaScript to save bandwidth and speed up their sites, but minified code is painful to read and debug. With IE9’s built-in JavaScript formatting, you can keep your code minified while still having easy-to-read code in the debugger:
Getting ready for the Release Candidate
With the sixth Platform Preview, developers, designers, and partners are in a great position to prepare their sites for the IE9 Release Candidate that will follow Platform Preview 6 and precede the final IE9 product.
- Deliver the best performance and best experience possible for visitors with IE9. We recommend sending IE9 the same standards-based markup your site sends other browsers, and sending it in the default IE9 mode that offers the best performance. Use feature detection, not browser detection, to handle any cross browser differences in behavior or feature support. This pattern will keep your site working even as browsers change. If your site relies on legacy IE behavior, place an X-UA-Compatible meta tag or header on your site so IE9 users have a good experience.
- Take advantage of HTML5, CSS3, SVG, Canvas, WOFF, DOM, ES5, navigation timing, the new F12 Developer Tools, and more… described here in the guide for developers. With IE9, the amazing experiences you write using web standard markup have an advantage, running hardware accelerated and using whole PC.
- Please continue to report issues on Connect if you’re giving IE9 the same code as you’re giving to other modern browsers and your site doesn’t look or work right. With IE9 Platform Preview 6, we’ve fixed over 80 community-reported issues involving common user scenarios, commonly used frameworks, JavaScript, DOM, and aspects of the platform. We’ve also added support for additional standards. We will fix even more between now and the IE9 Release Candidate, and want your feedback.
Platform Preview 6 is an important milestone on the way to the Release Candidate (RC). The IE9 platform is nearly complete. We appreciate your help delivering a richer and faster web that takes advantage of the new web standards the IE9 Release Candidate will support. We continue to welcome your feedback via Connect.
Thanks,
Dean Hachamovitch