NewsBot
1
Hi! I’m Christian Stockwell, and I’m helping to improve Internet Explorer performance.
In the past few months, each of the browser makers has made very similar claims around their performance: “Superior speed and performance”, “The fastest and most powerful Web browser available”, and “The fastest web browser on any platform.” In some fundamental way, I think the likeness of these statements is a by-product of the complexity inherent in performance measurement and analysis.
Rather than join the chorus and trumpet IE as the fastest browser in the universe, this post is my attempt to demystify the performance work that is being delivered as part of IE8 so that you can understand how we are making you more productive.
Best of all, you don’t need to take my word for it. As Dean mentioned back at MIX08, Google has commented on our IE8 Beta 1 improvements (emphasis mine), and we’ve made IE8 even faster since then:
“Some of the tests we have done show pure JScript performance improvements up to 2.5 times. We also measured the performance gains on common Gmail operations, like loading the inbox (34%), opening a conversation (45%) and opening a thread (27%) compared to IE7.”
Before I delve too far into the body of this post I am going to first take a step back to explain how the IE team thinks about performance. I will then discuss some of the performance work that has gone into IE8 and how it will make IE8 a better browser for user and developers. Lastly, I will touch on some of the great IE8 features that give web developers the right tools they need to be more productive and to build the next generation of great sites.
The Big Picture: Performance and Productivity
“Every language has an optimization operator. In C++ that operator is ‘//’”
- Overheard at the O’Reilly’s Velocity Conference, June 2008
To describe the effort we are undertaking with IE8 we first need to take a step back to consider the relationship between performance and productivity. Most importantly, recognize that browser performance is a means to an end. The end goal is to build a platform that makes users and developers more productive. If we ignore that target the task of building a fast product is suddenly much easier: do precisely nothing.
For IE8, the recognition that users want to accomplish a set of actions when they browse the web has manifested itself in many of the features we have disclosed to date in IE8. A clear example that improves user productivity is Web Slices. Consider, for example, how Web Slices delegate the browser to check for updated content on behalf of users.
Both of these features present new productivity options for both users and developers. For users, the benefit of having common actions distilled into two quick button presses is obvious. Developers, for their part, can consider the benefits of quickly introducing new lightweight Web Slices instead of investing hundreds of developer hours tuning site loading speed for the hordes of users compulsively refreshing their pages in the pursuit of updates.
Beyond these two manifestations of our focus on productivity, IE8 includes many key improvements. In the first section below I describe in greater detail the work we’ve done to date to improve your productivity. The last section of this article discusses some of the great developer features we’ve built that will give site developers the right foundation they need to efficiently build faster sites in Internet Explorer.
Great Performance: How to build a faster browser
As we started planning what we wanted to accomplish with IE8, we made a conscious decision to improve how people use Internet Explorer to browse the web. Broadly stated, some of the areas we pinpointed for improvement include browser startup, navigation, and user interactions (including AJAX-style interactions within a webpage).
Part of that focus has translated into our investment into new features like Web Slices, because in some cases the fastest browser is the one that does not need to load a webpage at all. Beyond these efforts, we have also concentrated on improving IE as a web platform.
When we took a hard look at our goals and considered what we could do to build the best browser we were presented with a quandary. On the one hand, we could focus very narrowly on scripting performance, trusting that our investment would noticeably improve our users’ browsing experience. Alternatively, we could invest more broadly in realistic scenarios, measuring heavily-used subsystems and investing our optimization effort accordingly. We opted for the latter approach.
After some analysis, what we found was that investing the entirety of our effort on improving JScript would not substantially improve our users’ browsing experience in most cases. For a sample of the type of data we used in our analysis, I’ve included below a breakdown of the CPU cycles consumed by some of our key subsystems when navigating to the top 100 sites in IE8 Beta 1:
LayoutRenderingHTML ParsingMarshallingCSS FormattingDOMJScriptOther43.16%27.25%2.81%7.34% 8.66%5.05%3.23%2.49%Notice that when navigating to the top 100 sites the systems exercised in typical JScript/DOM benchmarks (e.g. SunSpider) account for less than 10% of the total time. Furthermore, we analyzed several common AJAX applications and performed similar analyses, with similarly surprising results:
Layout RenderingHTML ParsingMarshallingCSS FormattingDOMJScriptOther8.87% 8.68% 1.48% 7.40% 36.72% 11.72% 13.59% 11.54% Even on a typical AJAX site (these numbers are for a leading webmail sites) it is telling that the JScript and DOM subsystems contribute less than a third of the total time.
Based on this data and other analyses we performed it was clear that to significantly improve browsing in IE8 we needed to make improvements to several areas of our code beyond JScript. In addition to discussing our improvements to the JScript engine I cover three of those areas below.
Performance benchmarking suites like SunSpider are still an important part of how we analyze our progress. They are a certainly valuable as a means to measure progress and to analyze some aspects of browsing performance in a laboratory environment. They are most useful when we understand how they fit into the larger scenarios we are trying to improve.
In particular, our analysis of IE subsystems has helped us understand where improvements to benchmarks translate into improvements to overall browsing speed. Ultimately though, performance benchmarking suites do not provide complete coverage for browsing performance and how well they represent your particular browsing habits may vary.
Scripting Improvements
As part of our broader effort to improve performance in IE8, we did make large investments in JScript performance to make pages faster and to help developers be more productive.
The JScript engine included with IE8 speeds up many common user scenarios. We have made huge improvements to widely-used JScript functionality including faster string, array, and lookup operations. We have also made changes to our core architecture to drastically reduce the cost of functions calls, object creation, and lookup patterns for variables scoped to the window or this objects.
Some of those improvements have been driven by existing bottlenecks in our code. Two longstanding developer pain points, String and Array operations, are in some cases now faster by several orders of magnitude compared to their previous incarnations. These improvements mean that developers no longer need to expend time and effort developing arcane workarounds to avoid slow areas of IE’s JScript implementation (no more array push-joins to avoid string concatenation!). Moreover, these changes have contributed to improve IE8’s performance on the SunSpider benchmarking suite by 400% compared to IE7.
Since most users do not use their browser solely to run JScript benchmarking suites, what’s even more important is that we’ve made many sites measurably faster. Our work to improve IE’s JScript engine has been instrumental in earning us positive feedback like that from Google.
Memory Management Improvements
The second area in which we are invested heavily in IE8 is in improvements to our memory usage. To date we have fixed just under 400 separate memory leaks in Internet Explorer. We have also worked hard to improve our heap fragmentation and memory usage on AJAX pages. For users, these changes reduce the amount of memory consumed by IE, improve our startup times, speed up navigating between pages, and help IE remain stable for longer periods of time. Besides these great benefits to end users, our work in this area should take a significant burden off of developers.
Specifically, we have worked hard to mitigate some common causes of leaks between our JScript and DOM. In previous versions of IE the JScript garbage collector (GC) managed the lifetime of JScript objects but not that of DOM objects. As a result the GC was unable to break circular references between DOM and JScript objects, resulting in memory leaks unless site authors took it upon themselves to carefully manage their memory footprint. In complex AJAX sites this is a daunting task and can easily consume lots of developer time.
In IE7 we made some improvements to this area by breaking those circular references when users navigate away from leaking pages. That mitigation, however, is not a long term solution for the complex interactive pages that users expect today.
With IE8 we have significantly augmented the garbage collector so that it can break many circular references over the lifetime of a site, reducing the burden on developers. Due to that work developers can spend more of their time focusing on building world class user websites and less on the minutiae of memory management.
Networking Improvements
As we started building IE8 it was clear that we could do more to take advantage of the increasing prevalence of high bandwidth connections. Two key improvements we made with IE8 were to unblock downloads in the presence of external scripts and to increase the number of parallel connections per server that we support.
Early in the inception of IE8 we recognized that blocking on external scripts was suboptimal given the modern reality of relatively inexpensive CPU cycles and the important role network latency plays in the performance of many websites. When IE8 encounters an external script we continue parsing on a second thread to ensure that we continue downloading page elements as fast as possible. In many cases that change will users’ favorite pages will download faster and developer will no longer need to spend time ensuring that scripts do not serialize their downloads.
In IE8 Beta 1 we also increased our per-server connection limit from 2 to 6. What this means is that in IE7 and below pages could only download 2 elements from a given server at any one time. Increasing that limit to 6 allows sites to download 3 times as much content in parallel, which should translate into faster page download times when bandwidth is available.
Rendering Engine Improvements
The last large area of I am going to cover in this post are the improvements we have made to layout and rendering in our new standards mode engine.
For those of you following IE8’s development, it should come as no surprise that we are building a new CSS 2.1 compliant rendering engine. As you may have guessed from the subsystem data I presented earlier in this post, we have also recognized that rendering and layout performance is a large component of overall browsing speed.
To ensure that developers and users are more productive in IE8, it is therefore clear that we need to deliver a great engine that does not introduce any performance penalty vis-à-vis the browser as it exists today.
In Beta 1 our standards mode engine was much slower than our IE7 engine. Over the last few months we have been making improvements by leaps and bounds. By our upcoming Beta 2 we expect our standards mode engine to be at parity with our previous implementation for many sites. Going forward we will continue to invest in this area with the goal that when IE ships, developers do not have to make any difficult decisions: developing for our new engine will produce sites that work better across browsers and as an added bonus they will be faster too!
The combination of the performance improvements I’ve outlined above mean that many sites will be faster in IE8, allowing our users to be more productive than ever before. At the same time we have also eliminated numerous rough patches so that web developers can build great sites in less time.
Best yet, with IE8 Beta 2, developers can see further improvements to our developer tools that will make them more productive developing lighting fast sites.
New Developer Features
Beyond the various enhancements we’ve made to IE8 to make you more productive when browsing the web or creating new sites, we’ve also added support for several key new technologies that you can harness to make your websites faster. In the remainder of this post I will briefly discuss three of my favorite IE8 developer features.
Data URI
Are you tired of spending time writing code to use CSS spriting to minimize network overhead of using many small images on your site? If so, the first of my favorite features may be just for you. With IE8 we add support for RFC 2397’s Data URIs. Instead of using a URL to point to an image file (and incurring additional round trip costs to transfer that file to the browser), you can use Data URIs to encode the data directly.
For instance, here is a Data URI representing a 10x10 blue dot (base64 encoded):
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKAQMAAAC3/F3+AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAANQTFRFALfvPEv6TAAAAAtJREFUCB1jYMAHAAAeAAEBGNlaAAAAAElFTkSuQmCC
You should note, however, that Data URIs should be used sparingly because they incur some client processing overhead due to their base64 encoding and because they cannot be cached in the same as images retrieved over the network. Since Data URIs are embedded directly into a document, script, or stylesheet you should try to embed them within one such element that is in turn cacheable.
Selectors API
In addition to our support for Data URIs, IE8 also supports the Selector APIs querySelector and querySelectorAll to let you lookup selectors from JScript orders of magnitude faster than you would previously using implementations included in frameworks. In informal tests against our recent builds I’ve seen some tests improve from several seconds to mere milliseconds when comparing our native implementation against the alternatives offered by common frameworks. For more detail regarding our implementation of the selectors API please refer to our Selectors API whitepaper.
JSON
The last of my three favorite IE8 developer features is our support for JSON, announced in an earlier post on this blog.
Developers on AJAX websites often use JavaScript Object Notation (JSON) to pass data between components of their site. In previous versions of IE developers were often forced to use JSON insecurely by using JScript’s eval method to revive JSON strings back into JScript objects. More secure sites typically used a more secure JSON parser to sanitize their JSON objects—often at the price of significant performance penalties. In both cases user and developer productivity was severely compromised.
To make everyone’s life easier with IE8 Beta 2 our JScript engine implements the ECMAScript 3.1 JSON proposal’s JSON.stringify and JSON.parse methods, providing a speedy and secure solution to a common developer problem.
Other great features
Those are my three favorite features that developers can harness to build better sites in IE8. Of course, your favorites may vary because beyond those three features we have great collection of developer features that you can take advantage of to build faster sites.
Our support for DOM storage (10mb of local storage per site!), XDomainRequest (secure cross-domain communication without a server-side proxy), and Connectivity Events (script can now tell if a user is connected to the internet) are all very powerful features that developers can harness to build faster websites.
Moreover, I am confident that our investment in tools and features for developers ensures that building fast sites in IE8 will be an easier and more transparent process than in any previous version of our browser.
I hope that this article has helped you understand a little better how our performance work fits into the Internet Explorer team’s goal of making us all more productive. Although it is often tempting to obsess about particular performance benchmarking suites I have always found it valuable to take a step back and look at the bigger picture for a moment to put everything in perspective.
With that in mind, I do recognize that your expectations are pretty high. We have lots more performance work planned for IE8 and I encourage you to keep following our progress as we release our upcoming Beta.
Christian Stockwell
Program Manager & Performance Geek
More...
In the past few months, each of the browser makers has made very similar claims around their performance: “Superior speed and performance”, “The fastest and most powerful Web browser available”, and “The fastest web browser on any platform.” In some fundamental way, I think the likeness of these statements is a by-product of the complexity inherent in performance measurement and analysis.
Rather than join the chorus and trumpet IE as the fastest browser in the universe, this post is my attempt to demystify the performance work that is being delivered as part of IE8 so that you can understand how we are making you more productive.
Best of all, you don’t need to take my word for it. As Dean mentioned back at MIX08, Google has commented on our IE8 Beta 1 improvements (emphasis mine), and we’ve made IE8 even faster since then:
“Some of the tests we have done show pure JScript performance improvements up to 2.5 times. We also measured the performance gains on common Gmail operations, like loading the inbox (34%), opening a conversation (45%) and opening a thread (27%) compared to IE7.”
Before I delve too far into the body of this post I am going to first take a step back to explain how the IE team thinks about performance. I will then discuss some of the performance work that has gone into IE8 and how it will make IE8 a better browser for user and developers. Lastly, I will touch on some of the great IE8 features that give web developers the right tools they need to be more productive and to build the next generation of great sites.
The Big Picture: Performance and Productivity
“Every language has an optimization operator. In C++ that operator is ‘//’”
- Overheard at the O’Reilly’s Velocity Conference, June 2008
To describe the effort we are undertaking with IE8 we first need to take a step back to consider the relationship between performance and productivity. Most importantly, recognize that browser performance is a means to an end. The end goal is to build a platform that makes users and developers more productive. If we ignore that target the task of building a fast product is suddenly much easier: do precisely nothing.
For IE8, the recognition that users want to accomplish a set of actions when they browse the web has manifested itself in many of the features we have disclosed to date in IE8. A clear example that improves user productivity is Web Slices. Consider, for example, how Web Slices delegate the browser to check for updated content on behalf of users.
Both of these features present new productivity options for both users and developers. For users, the benefit of having common actions distilled into two quick button presses is obvious. Developers, for their part, can consider the benefits of quickly introducing new lightweight Web Slices instead of investing hundreds of developer hours tuning site loading speed for the hordes of users compulsively refreshing their pages in the pursuit of updates.
Beyond these two manifestations of our focus on productivity, IE8 includes many key improvements. In the first section below I describe in greater detail the work we’ve done to date to improve your productivity. The last section of this article discusses some of the great developer features we’ve built that will give site developers the right foundation they need to efficiently build faster sites in Internet Explorer.
Great Performance: How to build a faster browser
As we started planning what we wanted to accomplish with IE8, we made a conscious decision to improve how people use Internet Explorer to browse the web. Broadly stated, some of the areas we pinpointed for improvement include browser startup, navigation, and user interactions (including AJAX-style interactions within a webpage).
Part of that focus has translated into our investment into new features like Web Slices, because in some cases the fastest browser is the one that does not need to load a webpage at all. Beyond these efforts, we have also concentrated on improving IE as a web platform.
When we took a hard look at our goals and considered what we could do to build the best browser we were presented with a quandary. On the one hand, we could focus very narrowly on scripting performance, trusting that our investment would noticeably improve our users’ browsing experience. Alternatively, we could invest more broadly in realistic scenarios, measuring heavily-used subsystems and investing our optimization effort accordingly. We opted for the latter approach.
After some analysis, what we found was that investing the entirety of our effort on improving JScript would not substantially improve our users’ browsing experience in most cases. For a sample of the type of data we used in our analysis, I’ve included below a breakdown of the CPU cycles consumed by some of our key subsystems when navigating to the top 100 sites in IE8 Beta 1:
LayoutRenderingHTML ParsingMarshallingCSS FormattingDOMJScriptOther43.16%27.25%2.81%7.34% 8.66%5.05%3.23%2.49%Notice that when navigating to the top 100 sites the systems exercised in typical JScript/DOM benchmarks (e.g. SunSpider) account for less than 10% of the total time. Furthermore, we analyzed several common AJAX applications and performed similar analyses, with similarly surprising results:
Layout RenderingHTML ParsingMarshallingCSS FormattingDOMJScriptOther8.87% 8.68% 1.48% 7.40% 36.72% 11.72% 13.59% 11.54% Even on a typical AJAX site (these numbers are for a leading webmail sites) it is telling that the JScript and DOM subsystems contribute less than a third of the total time.
Based on this data and other analyses we performed it was clear that to significantly improve browsing in IE8 we needed to make improvements to several areas of our code beyond JScript. In addition to discussing our improvements to the JScript engine I cover three of those areas below.
Performance benchmarking suites like SunSpider are still an important part of how we analyze our progress. They are a certainly valuable as a means to measure progress and to analyze some aspects of browsing performance in a laboratory environment. They are most useful when we understand how they fit into the larger scenarios we are trying to improve.
In particular, our analysis of IE subsystems has helped us understand where improvements to benchmarks translate into improvements to overall browsing speed. Ultimately though, performance benchmarking suites do not provide complete coverage for browsing performance and how well they represent your particular browsing habits may vary.
Scripting Improvements
As part of our broader effort to improve performance in IE8, we did make large investments in JScript performance to make pages faster and to help developers be more productive.
The JScript engine included with IE8 speeds up many common user scenarios. We have made huge improvements to widely-used JScript functionality including faster string, array, and lookup operations. We have also made changes to our core architecture to drastically reduce the cost of functions calls, object creation, and lookup patterns for variables scoped to the window or this objects.
Some of those improvements have been driven by existing bottlenecks in our code. Two longstanding developer pain points, String and Array operations, are in some cases now faster by several orders of magnitude compared to their previous incarnations. These improvements mean that developers no longer need to expend time and effort developing arcane workarounds to avoid slow areas of IE’s JScript implementation (no more array push-joins to avoid string concatenation!). Moreover, these changes have contributed to improve IE8’s performance on the SunSpider benchmarking suite by 400% compared to IE7.
Since most users do not use their browser solely to run JScript benchmarking suites, what’s even more important is that we’ve made many sites measurably faster. Our work to improve IE’s JScript engine has been instrumental in earning us positive feedback like that from Google.
Memory Management Improvements
The second area in which we are invested heavily in IE8 is in improvements to our memory usage. To date we have fixed just under 400 separate memory leaks in Internet Explorer. We have also worked hard to improve our heap fragmentation and memory usage on AJAX pages. For users, these changes reduce the amount of memory consumed by IE, improve our startup times, speed up navigating between pages, and help IE remain stable for longer periods of time. Besides these great benefits to end users, our work in this area should take a significant burden off of developers.
Specifically, we have worked hard to mitigate some common causes of leaks between our JScript and DOM. In previous versions of IE the JScript garbage collector (GC) managed the lifetime of JScript objects but not that of DOM objects. As a result the GC was unable to break circular references between DOM and JScript objects, resulting in memory leaks unless site authors took it upon themselves to carefully manage their memory footprint. In complex AJAX sites this is a daunting task and can easily consume lots of developer time.
In IE7 we made some improvements to this area by breaking those circular references when users navigate away from leaking pages. That mitigation, however, is not a long term solution for the complex interactive pages that users expect today.
With IE8 we have significantly augmented the garbage collector so that it can break many circular references over the lifetime of a site, reducing the burden on developers. Due to that work developers can spend more of their time focusing on building world class user websites and less on the minutiae of memory management.
Networking Improvements
As we started building IE8 it was clear that we could do more to take advantage of the increasing prevalence of high bandwidth connections. Two key improvements we made with IE8 were to unblock downloads in the presence of external scripts and to increase the number of parallel connections per server that we support.
Early in the inception of IE8 we recognized that blocking on external scripts was suboptimal given the modern reality of relatively inexpensive CPU cycles and the important role network latency plays in the performance of many websites. When IE8 encounters an external script we continue parsing on a second thread to ensure that we continue downloading page elements as fast as possible. In many cases that change will users’ favorite pages will download faster and developer will no longer need to spend time ensuring that scripts do not serialize their downloads.
In IE8 Beta 1 we also increased our per-server connection limit from 2 to 6. What this means is that in IE7 and below pages could only download 2 elements from a given server at any one time. Increasing that limit to 6 allows sites to download 3 times as much content in parallel, which should translate into faster page download times when bandwidth is available.
Rendering Engine Improvements
The last large area of I am going to cover in this post are the improvements we have made to layout and rendering in our new standards mode engine.
For those of you following IE8’s development, it should come as no surprise that we are building a new CSS 2.1 compliant rendering engine. As you may have guessed from the subsystem data I presented earlier in this post, we have also recognized that rendering and layout performance is a large component of overall browsing speed.
To ensure that developers and users are more productive in IE8, it is therefore clear that we need to deliver a great engine that does not introduce any performance penalty vis-à-vis the browser as it exists today.
In Beta 1 our standards mode engine was much slower than our IE7 engine. Over the last few months we have been making improvements by leaps and bounds. By our upcoming Beta 2 we expect our standards mode engine to be at parity with our previous implementation for many sites. Going forward we will continue to invest in this area with the goal that when IE ships, developers do not have to make any difficult decisions: developing for our new engine will produce sites that work better across browsers and as an added bonus they will be faster too!
The combination of the performance improvements I’ve outlined above mean that many sites will be faster in IE8, allowing our users to be more productive than ever before. At the same time we have also eliminated numerous rough patches so that web developers can build great sites in less time.
Best yet, with IE8 Beta 2, developers can see further improvements to our developer tools that will make them more productive developing lighting fast sites.
New Developer Features
Beyond the various enhancements we’ve made to IE8 to make you more productive when browsing the web or creating new sites, we’ve also added support for several key new technologies that you can harness to make your websites faster. In the remainder of this post I will briefly discuss three of my favorite IE8 developer features.
Data URI
Are you tired of spending time writing code to use CSS spriting to minimize network overhead of using many small images on your site? If so, the first of my favorite features may be just for you. With IE8 we add support for RFC 2397’s Data URIs. Instead of using a URL to point to an image file (and incurring additional round trip costs to transfer that file to the browser), you can use Data URIs to encode the data directly.
For instance, here is a Data URI representing a 10x10 blue dot (base64 encoded):
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKAQMAAAC3/F3+AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAANQTFRFALfvPEv6TAAAAAtJREFUCB1jYMAHAAAeAAEBGNlaAAAAAElFTkSuQmCC
You should note, however, that Data URIs should be used sparingly because they incur some client processing overhead due to their base64 encoding and because they cannot be cached in the same as images retrieved over the network. Since Data URIs are embedded directly into a document, script, or stylesheet you should try to embed them within one such element that is in turn cacheable.
Selectors API
In addition to our support for Data URIs, IE8 also supports the Selector APIs querySelector and querySelectorAll to let you lookup selectors from JScript orders of magnitude faster than you would previously using implementations included in frameworks. In informal tests against our recent builds I’ve seen some tests improve from several seconds to mere milliseconds when comparing our native implementation against the alternatives offered by common frameworks. For more detail regarding our implementation of the selectors API please refer to our Selectors API whitepaper.
JSON
The last of my three favorite IE8 developer features is our support for JSON, announced in an earlier post on this blog.
Developers on AJAX websites often use JavaScript Object Notation (JSON) to pass data between components of their site. In previous versions of IE developers were often forced to use JSON insecurely by using JScript’s eval method to revive JSON strings back into JScript objects. More secure sites typically used a more secure JSON parser to sanitize their JSON objects—often at the price of significant performance penalties. In both cases user and developer productivity was severely compromised.
To make everyone’s life easier with IE8 Beta 2 our JScript engine implements the ECMAScript 3.1 JSON proposal’s JSON.stringify and JSON.parse methods, providing a speedy and secure solution to a common developer problem.
Other great features
Those are my three favorite features that developers can harness to build better sites in IE8. Of course, your favorites may vary because beyond those three features we have great collection of developer features that you can take advantage of to build faster sites.
Our support for DOM storage (10mb of local storage per site!), XDomainRequest (secure cross-domain communication without a server-side proxy), and Connectivity Events (script can now tell if a user is connected to the internet) are all very powerful features that developers can harness to build faster websites.
Moreover, I am confident that our investment in tools and features for developers ensures that building fast sites in IE8 will be an easier and more transparent process than in any previous version of our browser.
I hope that this article has helped you understand a little better how our performance work fits into the Internet Explorer team’s goal of making us all more productive. Although it is often tempting to obsess about particular performance benchmarking suites I have always found it valuable to take a step back and look at the bigger picture for a moment to put everything in perspective.
With that in mind, I do recognize that your expectations are pretty high. We have lots more performance work planned for IE8 and I encourage you to keep following our progress as we release our upcoming Beta.
Christian Stockwell
Program Manager & Performance Geek
More...