Performance Improvements in Internet Explorer 8 Beta 2 (Cont.)
Great New Features
In Internet Explorer 8 Beta 2 Microsoft is introducing several new features that developers can take advantage of to improve their site performance. Several of those features have been discussed in other articles in this issue.
One of the things that Web developers have told us is that they need a way to extend the DOM with cutting-edge new features they can deliver as rapidly as their business demands.
Sunava Dutta introduced the Microsoft implementation of the HTML5 specification’s DOM Storage, Cross-Document Request (XDR), and Connectivity Events in his article, “Better AJAX Development with Internet Explorer 8 Beta 2”. Web developers can take advantage of these great cross-platform features to speed up their sites.
Beyond these three key features, John Hrvatin has introduced the JScript profiler built into the Internet Explorer 8 Beta 2 developer tools. A crucial addition to any Web developer’s toolbox, the profiler gives site authors the tools they need to understand and improve the speed of their sites.
In addition to these great enhancements, Internet Explorer 8 Beta 2 includes support for several new standards that developers can exploit to build lighting fast sites. The Internet Explorer 8 Beta 2 implementation of the ECMAScript 3.1 JSON recommendation, support for mutable DOM prototypes, and native support for the Selectors API are all cutting edge features that will form the basis for the next generation of Web sites and frameworks.
Native JSON support
Security-conscious developers instead use a more secure JSON parser to ensure that the JSON object does not contain executable script, often at the price of a significant performance penalty.
To illustrate, here is an example of serializing and deserializing data using the JSON.stringify and JSON.parse methods: var testObj = new Object();
testObj.numVal = 4;
testObj.strVal = "fool";
testObj.dateVal = new Date(2008, 3, 1);
testObj.arrVal = new Array(1,2,"test");
testObj.boolVal = true;
// Convert the object to a string
var stringifiedValue = JSON.stringify(testObj);
// Create a new object from the string
var parsedValue = JSON.parse(stringifiedValue);
Streamlined DOM Searching
Do you find yourself caught in the trap of assigning an ID to every element in your source code in order to use the ubiquitous getElementById API to retrieve what you are looking for? Perhaps you are a veteran user of getElementsByTagName? Whatever element lookup technique you employ, you have probably run into those scenarios where one of these APIs just does not stretch as far as you need it to.
To experiment with the syntax, try replacing a call to getElementById(‘id’) with querySelector(‘#id’)-the results are the same. The following example uses querySelectorAll to grab all relevant elements by class and turn off their collective display status. Listing 1 illustrates the original unoptimized code demonstrating that the use of the Selectors API results in significantly less-code to download and execute on the client.function useSelectors(clsName)
// Hide everything...
var unset =
document.querySelectorAll('h3, p, ul, code');
for (var i = 0; i < unset.length; i++)
unset[i].style.display = 'none';
var set =
document.querySelectorAll("." + clsName);
for (var i = 0; i < set.length; i++)
set[i].style.display = 'block';
The Selectors APIs are available at two different scopes: document and element. If you want to find the first result of a particular selector, then use querySelector (which returns the found element directly). Alternatively, if you want to find all matching elements use querySelectorAll. Using element scope can be important when you want to narrow your results to a particular subtree of the DOM instead of collecting results from everywhere. Interestingly enough, the provided selector-string parameter is first checked against the entire document, however the elements returned must be within the proper subtree of the element on which the API was called.
Mutable DOM Prototypes
As with the support for the Selectors APIs, the support for mutable DOM prototypes gives developers the building blocks to create efficient and compact abstractions.
// Check to see if there's a "xyz"
// (it should not exist because it is not
// part of the object or its prototype)
// Add xyz to the prototype
Array.prototype.xyz = "xyz string";
// Now xyz is available to the instance
Compared to frameworks released by Web developers, features provided by a browser release at a slower pace and cater to a more general audience. One of the things that Web developers have told us is that they need a way to extend the DOM with cutting-edge new features-features only they can deliver as rapidly as their business demands. Essentially, developers need to be able to fill functionality gaps long before a native implementation shows up in any browser. DOM prototypes give Web developers the basic building blocks that they can supplement the DOM directly with extra functionality or replace existing implementations with their own.
Drawing from the previous example, if I want to add a feature to all image elements in the DOM I could add it to the HTMLImageElement prototype:// Apply the change to the prototype.
HTMLImageElement.prototype.grow = function()
this.width *= 1.5;
this.height *= 1.5;
// Grow all the images in the document.
for (var i= 0; i < document.images.length; i++)
The alternative approach is to add the feature API manually to each individual image element separately-crippling performance. You can see how mutable prototypes provide a much simpler and efficient approach to this common problem.
<div id="div2" class="abc xyz">More</div>
<div id="div3" class="xyz abc box">Other</div>
// Invoke getElementsByClassName.
var div1 = document.getElementById('div1');
If you are like me, you have at one point likely built a website that required at least a few small images. In some cases you can use CSS sprites to combine images and avoid network round trips. In some cases, however, I had to resign myself to the inevitable and incur the cost of an extra round trip. No longer!
Normally, URLs act as pointers to network locations that contain data. For instance, http://www.example.com/ie.gif instructs the Web browser to download the image file named “ie.gif” from the HTTP server running at www.example.com.
Internet Explorer 8 Beta 2 introduces support for Data URIs. Rather than acting as a resource locator, a Data URI contains the resource data directly within the URI string. In order to embed binary data within the string, the data is first encoded using base64 encoding.
For instance, here is a Data URI that represents a 10x10 blue dot:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA
Internet Explorer 8 Beta 2 permits Data URIs of up to 32kb in length. Careful use of Data URIs in place of URLs can help you avoid costly network round trips and improve the overall performance of your sites.
The Big Picture
Now that I have completed my whirlwind tour of some of the great features that Microsoft will deliver in Internet Explorer 8 Beta 2, I think it’s important to take a step back to see the big picture. The focus of the performance improvements in Internet Explorer 8 Beta 2 center on building a platform that allows developers to get more done when they build and browse sites.
With that in mind, I hope you are eager to see how Microsoft’s investment to improve scripting speed, download pages faster, and reduce browser overhead enables you to browse faster.
The full benefit of Internet Explorer 8 Beta 2 is not limited to these immediate gains. Not only is Internet Explorer 8 Beta 2 speeding up the Web as it exists today, but it is delivering groundbreaking features that will let you build the next generation of lighting fast websites.
With Internet Explorer 8 Beta 2, one thing is clear. It’s a great time to be online.