IE8 Performance

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:

Layout Rendering HTML Parsing Marshalling CSS Formatting DOM JScript Other
43.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 Rendering HTML Parsing Marshalling CSS Formatting DOM JScript Other
8.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):


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.


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

Comments (97)
  1. William J. Edney says:

    My Challenge to the JScript team:

    Great news on all of these performance updates!! Excellent, excellent work!

    The Mozilla team just spent 60 days doing a JIT engine for Spidermonkey, the Mozilla JavaScript engine. They’re seeing amazing performance gains, as you probably already know. The Safari / Webkit crew has been working on Squirrelfish since way before that, again seeing stunning performance from a dynamic language.

    And these guys are only getting started.

    My challenge to you is to spend the next 60 days doing a JIT for JScript. Microsoft is filled with smart, language, compiler guys – I’m sure you can do something to match these efforts, if not do better :-).

    That is my challenge to you.

    Thanks again for this performance work – it is much appreciated by your developers and customers.


    – Bill

  2. Bruno says:

    I skimmed your post and found nothing relating to IE7’s biggest performance problem, which is sometimes it takes up to 12 seconds merely to open a new tab (particularly if I leave the computer for a while with IE running, then returning a few hours later and open a new tab).  I don’t have any problem with the rendering speed or ajax speed or any of that; the UI performance is dog slow and that is the main problem that affects users.

  3. Open Web Standards says:

    Awww, how cute. You quote the competitors but you don’t even mention who they are.

    “Superior speed and performance” – Mozilla Firefox

    “The fastest and most powerful Web browser available” – Opera

    “The fastest web browser on any platform.” – Apple Safari

    I guess mentioning them is a big no no, since they’re leaps and bounds ahead compared with the dinosaur browser with Trident engine that just starting to support CSS 2.1 "properly".

    "Since most users do not use their browser solely to run JScript benchmarking suites"

    LOL, insinuating that the other browser makers only run Javascript benchmarking suites, what a laugh.

  4. Thanks for the great post.  I love hearing that there are real people behind these projects and to get a glimpse of the stuff that you are all working on.  

    Looking forward to using IE8! 🙂

  5. 8675309 says:

    personally the only reason why some browsers are slower are because of an isp’s dns backbone

  6. Eduardo Valencia says:


    Now add the download manager with pause/resume capability!!!!!!

  7. Mark says:

    Interesting. But why do I get the sense that this is the excuse memo for why IE8 beta 2 is slower than all other competitors once the first benchmarks are done?

  8. Eddie de Bear says:

    Gotta say I love it. Haven’t been this excited about a browser release for a long time.

    Keep up the good work

  9. Jemmbab says:

    Looking forward to using IE8!

    Awesome IE I think,fast as you can ,dude ,I am waitting for!

  10. Juliano says:

    This will be the greatest release ever!

    Improved security, performance, usability, disaster recovery, etc…..thank you very much!

    Now I won’t need to use both IE and Opera (yeah, I said Opera, ’cause Firefox is a shame).

  11. Anonymous says:

    @Open Web Standards

    I wish you wouldn’t misinterpret every last phrase to be an attack.  When you do so, it encourages a bureaucratic sort of minimal communication which is harder to read.

    What he’s describing is Amdahl’s law, using a very common literary device that goes "X is better for Y, but most people don’t just use X for Y".  It’s often used to describe why reported gas mileage doesn’t match actual use in a car, for instance (city driving vs. rural driving).

  12. wheres_the_beef? says:

    I love hearing about all this stuff, I really do.

    But this blog is beginning to seem like the opening act at a nightclub that’s been told to stall and keep the audience entertained because the featured performer’s stuck in traffic crosstown.

    Enough, already. Where’s Beta2? 😉

  13. zzz says:

    I’ve seen IE threads go to 100% for seconds on 3 GHz core 2 and page with no javascript at all. I’ve sent repros years ago before IE7 and it’s still not fixed. The problem appears to be somewhere in GIF parsing.

    There’s also another similar issue affecting tables and css. This was seen on recently but they’ve now removed the offending code. The site was nearly unusable for few days on IE.

  14. fearphage says:

    Are data URIs limited to images as I have heard before? In ever other browser that supports data uris, they can represent any piece of data (PDF, html, etc).

    Are you looking into any xpath support (document.evaluate) or extending document.selectNodes and document.selectSingleNode out beyond mere XML files? The selector API is strong but xpath still has the ability to out perform it and has advanced built-in functionality that make it useful.

    Are devs planning to update jscript to support something beyond js version 1.3? Functionality in version 1.6 are becoming commonly emulated in javascript frameworks but benefit greatly from native iimplementations.

  15. youambition says:

    great! today i could open my college web(LAN),but somedays before it can not open this address:

  16. Roman says:

    I second the "new tab" issue. I’ve never had 12 second open times, but even 1 second (which is typical) is too much for plain opening a new tab. And on my older computer it takes about 3 seconds, which is unacceptable.

    Also, it appears that data: URIs don’t work when pasted into the address bar. Is this expected? Why?

  17. Cameron says:

    This is great news, it’s good to know Microsoft is taking the browser seriously again!

    I agree with some of the other commenters, a JIT JavaScript engine works for the other browser vendors.

    I can’t wait to test my curvyCorners on IE8 Beta 2!

  18. Mike says:

    Rather than join the chorus and trumpet IE as the fastest browser in the universe

    Which would have everyone laughing out loud!!!

    It has been noted before and could just be a coincidence but whenever a post has a huge amount of negative feedback

    Another post is rushed out immediately!!!

  19. Mephiles says:

    IE8 is going to be the best of all the internet explorer versions. It’s a giant clean-up of all of the problems in the previous versions.

  20. Joe says:

    I second second the issue with the new tab. I’m assuming that’s the same issue as when opening the browser itself. The dreaded "Connecting…" message. It says connecting, so you assume it’s some kind of network thing, but it’s actually "Initializing…" of the add-ons/plugins. I don’t see why that can’t be done in parallel.

    It’s incredibly annoying to fire up IE, start typing something into the search box and halfway through your focus is taken away because the "connecting…" has finally finished after several seconds. I don’t get that on Firefox and I have half a dozen plugins installed on that.

    I’ve seen (while researching why connecting stays there so long) that some people out there say it lasts much longer for them, or never goes away at all.

    I suggest any of the following:

    1. Change the "Connecting…" message to "Initializing Add-on <name_of_addon>…"

    2. Allow Esc to quit the initializing if it appears to hang on one add-on.

    3. Allow the Tools menu to be used while initializing to disable the add-on.

    4. Stop making this Connecting a blocking synchronous operation. We shouldn’t need to know about it and it shouldn’t be slowing us down.

  21. Joe says:


    A Runtime Error has occurred.

    Do you with to Debug?

    Line: 318

    Error: Invalid Argument

    I got that on this very page with XP/IE7. I did debug it and a function is trying to access the .href property of a link and it doesn’t seem to have one. The code isn’t written defensively enough to avoid the JS error.

    You either want to check if the property exists before trying to use it, or wrap the whole thing in a try/catch.

  22. RichB says:

    I don’t get it. You say that layout perf will be no worse than the IE7 layout engine and imply it will be no better.

    Yet you say that layout/css are the biggest perf candidates and that it’s better to optimize these than spend time on JScript perf.

    Further, you have the Silverlight team sat in another building complaining about the performance of JScript and how much faster C# is.

    You can’t all be right? This is a very confusing message.

  23. rodjer says:


    A Runtime Error has occurred.

    Do you wish to Debug?

    Line: 318

    Error: Invalid Argument

    I had this same error, also debugged it, but nothing happened, going for it again.


  24. hAl says:

    Data URL increase security risk by delivering files in manners that can obfuscate known malware patterns in binary files. It makes it easier to exploit unpatched vunerabilities on machines that rely on malware scannig products to keep them safe untill patches are available.

    I asume adding compliance for acid 2 test has brought on the addition of data url’s to be used.

    The slight advantages of such data url’s are likely to be soon forgotten when malware builders see this new road for them to explore.

    It is not good that adding features to comply with some arbitrary test increase the attacksurface of IE without adding much benefits.

  25. Mena says:

    It is great to see that IE8 will have performance improvements, it was really needed.

    I did though, have the feeling that this blog entry was a bit defensive and kind of excusing itself for the speed that IE8 will have compared to other browsers. Instead new feature x is mentioned as something that would make up for the poor performance compared to other browsers.

    This impression was made bigger after reading the term "take a step back" too many times.

  26. Michael says:

    Great work… but why don’t you use hardware acceleration to speed up the rendering engine?

    Considering the speed of mordern graphics hardware, which typically isn’t used that much while browsing, it would mean quite an increase in speed.

  27. Frustrated says:

    Great. Thanks a lot. Another MS browser to support without being able to have all three major versions installed in a single OS while developing.

    Until MS fixes the issue of the still huge installer base of IE6 all you are doing is making life worse for developers.

  28. titrat says:

    I start typing a new URL in the address bar as soon as the IE opens – but shortly after it overwrites my typing with "about:blank", and steals the focus.

    If i set the focus to the addressbar, no one ever should steal the focus or overwrite my typing.

    I set the start-page to "blank page", but it overwrites my typing anyway – that should not happen.

    Why lasts it so long to open a new window from JavaScript? You could open a invisible dummy-window in the background, and recycle that, if windows are so expensive to open.

    And how about multithreading? Sometimes when loading a page the browser seems not to react any more – we live in the age of octo-cores!

    I’m thankful for your work towards standards, safety and speed, heading in this direction is the key to success. You must win the developers, not make them angry.

    Congratulations to the IE-Team for your proceedings  so far, great work!

  29. SamY says:

    Why is it not possible for your blog software to number the comments? Some of these posts receive a considerable number of comments. I suspect I am not the only person who is unable to read all the comments at once. Being able to make a note of the number of the last comment read would make life much easier.

  30. Stifu says:

    Frustrated: get IETester, it’s the best and most simple solution to have multiple IE versions on the same PC.

  31. Brian says:


    You can subscribe to the comment RSS feed to keep up with the discussion.

    It wouldn’t make sense to number the comments since many times a few (abusive and/or offtopic) comments get deleted.

  32. billybob says:

    On the download agreement for the selector API it says that you must not use it for commercial reasons.

    What exactly does this mean?

    I cannot use the selectors API in a commercial website?  I cannot use the PDF if I plan to use it with a commercial website (ie I must get my documentation from elsewhere)?

    The agreement seems to allow me to sell the PDF as long as I attribute it to Microsoft, so what does the Noncommercial clause mean?

  33. Aaargh! says:

    " In the past few months, each of the browser makers has made very similar claims around their performance (…) ‘The fastest web browser on any platform.’  (…)

    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."

    But how is IE8’s cross-platform performance, is it just as fast on OSX or Linux as on Windows ?

  34. Roman says:

    Hmm… it looks like one of my comments didn’t get through.

    Please make IE *not* hang when visiting Not sure if it’s a performance issue, but it’s definitely a major robustness failure.

    Right now it completely locks IE 8 up.

  35. That sounds like a good improvement. Congrats.

  36. losing faith says:

    Before you downplay the efforts of your competition to improve their ECMAScript performance, please remember that they’ve already more-or-less cleared the hurdles that are just coming into your view (SVG, HTML5 video/audio, Canvas.. the list goes on and on).

    Also, what top 100 list are you referring to? Should I somehow feel comforted that you ignored 99.99999% of the web in favor of some sites that may not even use Javascript extensively? I agree with your approach, but using a vague sample with such a miniscule size shows that this was either back-of-the-enveloped at the last second, or that you are suffering from delusions of grandeur. Remember: you are still steadily losing market share. Don’t give people a any more reasons to lose it even faster.

  37. wai says:

    a little suggestion on IE’s ui: on the bottom there are some squares(buttons) for those functions like Popup blocker, security certificate information, phishing filter etc. There are no explanation/tag/highlight for the user to know what’s these square used for (some user may even don’t know these squares can access those functions). It will be better if highlight/tag presents when the mouse cursor moves on them.

  38. Ran says:

    Dear IE team,

    first let me thank you for frequently updating this blog with relevant information.

    Speaking of the performance of IE8, I have two points I would like to mention:

    1. The time it takes for IE8 to load i.e. to about:blank as the home page. It says "Connecting…" for a few seconds. I guess this could be optimized to allow a faster start-up.

    2. The ghost service problem. If I work with IE8 during the day, at the end of the day there will be around five "iexplore.exe" services loaded in memory. I believe only one is needed. I really hope you fix this, even though the mem. foot prints of the ghost processes are relatively small.

    Best regards,

  39. marco.chila says:

    One great improvement, should be reach the same performance and trust level from the competitors. For an example, if IE renders as fast as mozilla firefox and being as safe as they are… IE will became the choice #1 for both users and developers.

    See you.


  40. Fantastic work with the performance increase this is what we have been waiting all along. I have made a request before and I believe it was partially fixed; it involves enabling script debugging. Most developers have their script debugging enabled for use with Visual Studio. Fantastic feature but when we visit sites we have to press No 100 times for jscript errors. This is fine if you are using integrated debugger but not an external one.

  41. David Naylor says:

    Great news! And to think, all this thanks to the original Firefox team. Boy, we owe them more than we will ever understand.

  42. Mitch 74 says:

    That’s… errr… nice. No, really.

    I would just like to point out that some other browsers had a lot to gain from optimizing their Javascript core: Firefox uses Javascript for a good part of its GUI interactions.

    Meaning that accelerating Javascript gave them faster response time in browser usage.

    Now, this isn’t the case with other browsers: Opera and Safari have a separate approach to their GUI. Yet, they still try to make their engines go faster.


    The answer can be found in Yahoo! Mail, Gmail, and Hotmail’s opening pages: loading times are radically reduced under those more recent browsers. The same for the interface itself: on older/slower machines, in current versions of IE, the lag is noticeable – while it just doesn’t happen in firefox, or Opera, or Safari…

    Please remember too that a faster application will also tax the CPU less; what are the most sold PCs today? Laptops. what happens when a CPU is less taxed? It uses less juice. Thus it lasts longer.

    The above may seem far fetched. However, if you spend your time browsing, between a browser that averages on 40% CPU use and another that barely reaches 2-3%, while at the same time displaying results a bit faster (if only to open a tab), this may result in (10 minutes lost by lag) + (15 minutes of battery times wasted) = 25 minutes on a 4 hours battery.

    I’m not criticizing what the IE team accomplished; it’s great. However, IE is still playing catch-up and some nice features such as native SVG support are still MIA. We also didn’t get a straight answer: will data URIs support stuff other than images? Although the 32 Kb upper limit doesn’t allow much, it’d be nice to know.

  43. franco says:

    hey, i’m from Firefox team

    we are missing your cakes

    when you will send another?

    keep trying to be Firefox, IE , good work

  44. SamY says:


    "You can subscribe to the comment RSS feed to keep up with the discussion."

    Thanks for the thought. Regrettably it doesn’t seem to work properly in IE7. 🙁

  45. Moondog says:

    I really appreciate the IE team giving us ‘almost’ daily news on their work, but really I feel that the actual "beta1" is so buggy (css wise, at least) that should be an alpha.

    A bug like this is **really** bad and I wouldn’t expect to have it in a beta release.

    Please, concentrate on the important stuff not on something like "InPrivate" features : |

    What about Canvas (or at least allow googlecanvas to it did in ie7)?No silverlight is not a replacement for it.

    On the plus side: finally some good debugging tools!

    Final question: how many rendering modes does ie8 have??? The "emulate ie7" is NOT working like ie7, whereas the "View/change compatibility mode/Strict(ie7)" does.Well, it looks like you introduced IE 7.5 together with version 8!Not that we needed that.

    Thanks for reading.

  46. "when navigating to the top 100 sites"

    Using the top 100 sites as a metric is absolutely the wrong way to go — the top 100 web sites have to optimize for the slow speed of IE6. Even big AJAX applications if they are popular. It can produce the wrong set of goals.

    For example, a site could use canvas to create some custom border that would otherwise use 8 background images. You might then optimize for the 8 background images, when really, the developer would rather use canvas to avoid the downloads altogether!

    At any rate, I’m looking forward to beta2 with its speed increases! Like everyone, most of our users use IE. A forced upgrade from IE6 to IE7 or IE8 would be the biggest relief you could give developers. I like beating a dead horse.. 😉

  47. Robin Walker says:

    I am concerned that Data URIs might offer another attack vector for malware.  There have previously been vulnerabilities in the interpretation of graphics file formats: there might be others discovered in the future.  But this time, the attack code can be embedded in plain text in a web page.  And that plain text can presumably be arbitrarily obfuscated.  I hope that the decoded data string is presented to the resident anti-virus application as if the data were a downloaded file.

  48. Abhishek says:

    First off, I have *very* high hopes for IE8 (given IE7 vis-à-vis 6), so I hope the IE Team doesn’t let me (and everyone else) down. I’m an ardent MS supporter, but there’s only *so* much a guy can take before freaking out. My demands as a simple end-user aren’t many, but they are extremely important to me so let me know right off the bat if I’m being unrealistic in expecting even this much, ok?

    IE7 starts up lightening-quick for me as compared to FF2 especially (I can click the FF icon and then have multiple instances of IE load before FF decides to put in an appearance – and yeah, I *know* FF3 is better in this regard).

    However, what irritates me NO end is IE’s abysmal tab performance. Tabs take ages to load; often tabs just cause the whole browser to hang without any apparent reason and while sometimes they’ll unfreeze after a while, more often than not I have to forcibly quit and restart IE (boom! all tabs gone). Switching tabs after some amount of continuous usage is also a real PITA.

    IE’s also prone to crashing suddenly for me in the midst of a serious browsing session (with 15+ tabs of ‘heavy’ content loaded), which leaves me frustrated no end as IE has no built-in crash/tab recovery or save feature. And no, no extra add-ins loaded here either, and the behaviour has been observed on multiple machines.

    Another thing about tabs you’d do well to copy (err, be inspired) from FF – make them support the mouse wheel *please*. I also want to move in the tab bar left or right *without* switching from the current tab.

    Fix these things – tab performance/features, crash recovery and automated tab save on close without asking every $%^#ing time (who was the genius who came up with that anyway, huh?) – and you’ll have an *extremely* satisfied user who’ll be more than ready to junk his copy of FF (installed purely because of better tab performance and better stability with tab auto-save).

    Cheers and shouts of encouragement to the IE Team!

  49. John says:

    Scrolling through a long Favorites menu with the mouse wheel like in Firefox is also a must have. And a much better Favorites management like in Firefox would be great. In IE it’s really a pain to manage them. And please make the save file dialog window remember the last directory and don’t always use the documents folder as standard directory. I never save anything in the documents folder and it’s a pain to always have to navigate to my folders.

  50. Athan says:

    Thank you for giving us more info about IE8 performance. However I have a question for IE team.

    What about screen rendering performance? You said nothing about it, although it is the major performance bottleneck.

  51. IEBlog says:

    We’re excited to release IE8 Beta 2 today for public download. You can find it at

  52. 8675309 says:

    about the little squares @ the bottom of the browser they already have pop up ballon notifaction within the 1st few uses of ie & if someone decides to disable them then they go away for good only in the current win user account

  53. Mena says:

    Firefox 3.0.1 is 2.47x faster than IE 8 beta 2 according to SunSpider.

    document.addEventListener is undefined.

  54. KeyLimeSoda says:

    What are the top 100 sites you use for benchmarking?

  55. alaazaoug says:

    good work ,for me the good  news are the perfect support fo css2.1 ,thanks for your work

  56. daaku says:

    This is great stuff!

    I think it is fully possible that the top 100 sites employ developers who understand the limitations of the existing browsers (especially the ones their customers use). And so they must work towards making their sites behave well under the known limitations.

    If JScript were to be faster, it is very much possible that it use might increase in the top 100. DOM manipulations are probably always going to remain the slowest part on the client side IMHO.

  57. ceasley says:

    You fixed 400 memory leaks?  AWESOME!  What I’d like to know is why you shipped a product (I assume you refer to IE7) with 400+ memory leaks in the first place…

    Dear God.

  58. says:

    Many folks have commented and written email about the topic of performance of Windows. The dialog has

  59. The next beta for Internet Explorer has been released for broad distribution to the public, according

  60. William says:

    So, 6 connections per-server?  Where did that come from, HTTP/1.1 tells you not to do that…Do you have any data to indicate that it is actually faster?  Because as long as you queue up the requests properly it shouldn’t be.

    HTTP 1.1 sec 8.1.4:

    "A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy"

  61. Josh says:

    "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."

    I think you are missing (or ignoring) the fact that you are SO far behind every other browser in this aspect that even 33% is significant.

  62. Fixing performance issues that have plagued previous versions of its Windows client OS and Internet Explorer

  63. Faramond says:

    Welcome news!

    But you left out the single two biggest performance drags I encounter in IE:

    1. Flash, which I cannot disable because some sites demand it, but most of the time it’s simply used for animation/video-intensive graphics that, although they do achieve their objective of catching the eye, transmogrify IE into a turtle in molasses.

    2. Memory leaks that grind the system to a halt as it attempts to enlarge the paging file (i.e., virtual memory) and thus prevent me from killing the application

    Suggested fixes:

    1. Give us an easy on-off button/toggle for Flash in every tab. Alternately, allow ActiveX controls to be disable for all websites except those on a whitelist (and make it easy to add sites to the whitelist.) It’s too much work to dig into Manage Add-Ons and have to restart the browser.

    2. Build in memory leak detection code, or impose a ceiling on memory allocation for each tab, beyond which the scripts, controls, etc. on the page will be frozen until the user clicks "yes" in response to a warning prompt. (This would be akin to how IE already prompts for scripts that are monopolizing the CPU.)

  64. bhavesh says:

    I installed IE8 Beta2 and was using it. I wrote a URL of a site which is full of images, and see what..??? IE8 hang for ever..I opened firefox3 in parallel and wrote same URL and see what..???? displayed page perfectly…

  65. Rob says:

    Scrolling in IE7 is too slow and IE8 beta 2 hasn’t fixed this problem. The only solution is turn off visual styles in internet options<advanced. It was very fast in IE6. Now there’s been a lot of noise about this issue, but I think it’s dying down. I submitted a bug to connect during the IE7 betas but the issue was never fixed because the IE team said it was unreproduceable. Well, I think that’s because their computers are too fast :P. Please try reproducing the bug on a much slower computer, like an AMD Athlon XP.

  66. Grow up says:

    To say what you’ve said is a clear indication that IE has already lost this war. You do realize that you are the ones who are holding back the top 100 sites from doing what they would really like to do with ECMAScript?

    If you’re just going to make up excuses and devote the bare minimum effort to bring IE up to code then why are you even trying anymore? The people you have on the IE team could be doing so much more by working on a product that isn’t a dead end.

  67. gOODiDEA says:


  68. gOODiDEA.NET says:

    .NET Garbage Collection Notifications in .NET 3.5 SP1 Testplan Checklist for Asp.Net .NET Framework 3

  69. honestly am impressed with the speed. IE8 beta2 start in no time. am using vista ultimate.

  70. s0rd3z says:

    Well, I been using the beta 2 for the better part of a day now.  And I have to tell yah, there is nothing new there.  Some added toolbars that just take up more real estate (and remind me of other browsers), tabs are still slow to open as mentioned.

    Web slices is a decent idea, but the rest just seems like uneeded fluff.  How about some security warning functionality for dot net framework and java?  Seems like a bit of a security flaw there, cause they can be utilized in a similar way to activeX plugins to infect end users with malware and other nasty stuff.

    Dunno maybe it’s just me, but it seems like the same basic direction most things are going with Microsoft.  Instead of streamlining and performance increases, we just get more addons and more features creating bloated software that has to many inconsistencies between the installed features.  Like say… oh I dunno… Vista? hehe.

  71. jerriho says:

    @ sord3z

    "How about some security warning functionality for dot net framework and java?  Seems like a bit of a security flaw there, cause they can be utilized in a similar way to activeX plugins to infect end users with malware and other nasty stuff."

    How about taking a look at the security option dialog to find out what you asked for are already there?

  72. I know it is off topic but there are a couple blogs posts of MSDN I found interesting. IE 8 Performance

  73. Frank says:

    Please implement proper support for CSS, I’m so tired of hacking my code and break the standard just to get IE to display a somwhat correct page. This really should be your main concern, no new features until IE can properly display pages using correct CSS.  

  74. DT blogi says:

    Microsoft hoidis kinni ajakavast, millest kirjutasime kandes Firefox 3 RC 2 väljas, IE8 Beta 2 tuleb augustis ning IE8 Beta on nüüdseks väljas. Käesolevalt annan ülevaate sellest, mida IE8 Beta 2 uut ja huvitavat pakub, kuid on lood jõudlusega j…

  75. caranthir says:

    I’m too an ardent MS supporter, and work only with Microsoft software.

    For many years I have defended MS, both in real-life debate and in

    innumerable blogs and forums. Give me a hint and I can provide my real name

    to prove it. My main reason for standing up for MS is that they always (always before)

    showed who that IN THE END ruled. Remember Exchange vs Lotus Notes anyone? Or how people belittled SQL Server?

    It is still possible that MS will do the trick again but this time it is taking too long! Doesn’t chief Software Architect Ray Ozzie understand that the whole credibility of Windows depends on IE8? When MS build its first browser it was done by a staff of 1000! So important was it. It is just as important today.

    The rendering is fast enough, but when the webpage is done, scrolling

    is slower, resizing the window is slower, working with the page is slower

    than any other browser. On many pages the CPU goes to 50% or more, and the mouse

    become unresponsive.

    As for instance at,, where IE8 b2 goes belly-up only because of a

    simple new sticker service that no other browser has problem with.

    The Javascript engine speed is depressing, just try the sunspider benchmark!

    Remember, MS much be best in everything!

    Please, double, triple the workforce.

  76. ge1doot says:

    Sure, static web pages load and render faster… until you try interacting with them.

    In particular, DOM-based javascript animations in IE8 beta 2 *standard mode* seem to run much much slower than ever (and than they should).

    I don’t care of the top 100 sites that have to be written for the lowest common denominator, but for what I can see at, most of the demo scripts actually run many times slower (or not at all) in IE8b2 standard mode than in compatibility mode or before with IE7.

    There is a lot of work still to be done… see you in Beta 3 !

  77. Jackyshen says:

    Tab performance is really a big problem.In my laptop (which is a lenovo T61) ,it takes me 2 or 3 seconds to open a new tab and this is the main reason that drive me  to shift to Firefox.

    Please solve this bug as soon as possible.

  78. Infamous Anonymous says:

    Pfft. I said this on my Stumble Review of this page: Internet explorer always was, always is, and always will be just a gaping security hole more than a web browser.

    I’ll never understand why Microsoft has been trying so damn hard to get a mediocre web browser out like IE since both Opera and Firefox are beginning to really crush it.

    All you Microsoft developers manage to do is tread water, copying features from the other more successful (Not to mention more secure and stable) browsers, and copying them badly.

    Microsoft, you suck.

  79. Adz says:

    A couple of days ago, starting out with a comment from Google on how your IE8 beta was X% faster made sense. Today I read it, and just thought "How enamored must Google be with IE at all if they’ve spent time writing there own browser, Google Chrome ?"

    The answer I suppose is that they think IE isn’t terribly good, and won’t get better any time soon.

    As a consumer, I welcome the new browser wars, it only stands to make browsers better for everyone. One just hopes MS and IE team realize how  quickly their market share may erode if they don’t deliver a fast, memory-efficient browser with standards-compliance by default and a good feature set.

    Good luck !

  80. Infamous Anonymous says:

    "A couple of days ago, starting out with a comment from Google on how your IE8 beta was X% faster made sense. Today I read it, and just thought "How enamored must Google be with IE at all if they’ve spent time writing there own browser, Google Chrome ?""

    It looks promising, although I’m not too thrilled with it being under the BSD license. I think that’ll make it too easy for Microsoft to steal code the way they did with the NT networking code. GPL would have been much smarter.

    "The answer I suppose is that they think IE isn’t terribly good, and won’t get better any time soon."

    In all honesty, most any group outside of the Microsoft reach all thing IE is probably the worst modern browser one could use: It leaks like a sieve, it’s not bloated, but it’s buggy, and it is slower than all the others.

    "As a consumer, I welcome the new browser wars, it only stands to make browsers better for everyone. One just hopes MS and IE team realize how  quickly their market share may erode if they don’t deliver a fast, memory-efficient browser with standards-compliance by default and a good feature set."

    Good luck with that: IE has yet to have any of those features. It was late with tabs, and the whole reason it even got them was because Firefox had tabs and was starting to gain on the market. Why do you think IE didn’t get an update for a long time? Because MS didn’t honestly think they needed to do anything more, because they were already dominant. Now it’s different. Most people I know on the Internet use the (MUCH SUPERIOR) Firefox web browser. Standards compliant is too good a dream to expect from any Microsoft product, wherein they only run with de fact Microsoft standards. (Try using some more advanced CSS even on IE7, and you’ll see how badly it even pretends to comply.)

  81. Anonymous Coward says:

    To me, the paradox is that IE is so pathetic after 10 years of solid market share, while Google Chrome is so thrillingly excellent from second 1.  I can’t understand why you guys are still working on IE, really..  You’ve lost the developers already and I think Google has the power to make you lose the users as well.  And then the OS doesn’t matter all that much anymore… pretty sad, huh.

  82. Duncan Macdonald who proudly and defiantly hates you, Microshit says:

    I personally can’t wait for Google Chrome to come out. If anything, the public will be made more aware of it than Firefox, and anything that disrupts Microshit’s dominance is OK by me.

    You’ve steadfastly refused to comply with standards, you’ve screwed over every web developer and designer in the world, and you deserve to go down.

    It comes down to this:

    Why should I have to spend weeks of non-billable time fixing clients sites because YOU (the IE team) refuse to make a good browser?

    The only plausible reason is that you think by forcing people to accept YOUR standards, you’ll retain dominance, and you’re wrong. I encourage anyone reading this to STOP FIXING FOR IE. Let them rot.

    You’re a joke.

  83. Anonymous Coward says:

    RE: "I personally can’t wait for Google Chrome to come out."

    It’s out already.  And IT ROCKS.

  84. Bruno says:

    Google Chrome is a big "meh".  Overhyped garbage from what I’ve used so far.

    IE team, you need to fix the tab performance.  It takes forever to make a new tab, sometimes takes forever just switching tabs.

  85. Non-Naive says:

    As a long time software developer, I have followed the arguments on which is the better browser, OS, etc.  It turns out that often the perceived best in a category is *not* the one that is most used (IE probably has greater than 85% of the market share).

    I’m sure I’m opening up a whole can of worms in saying this, but the most used software is typically open to more scrutiny, and more of its vulnerabilities, bugs, and performance issues will tend to be discovered because of the much larger user base.  So while many have complained about the large number of patches MS releases for their software, I’m thankful that they are committed to rectifying problems discovered in their software.  Show me a program with more than zero lines of code that doesn’t contain a single bug and I’ll nominate you for the Nobel prize.

    I’ve had my share of frustrations with IE, Firefox, Netscape, Opera, and Safari, all for different reasons.  But, at the end of the day, most (not all) of the websites I have developed work most reliably on IE.  We have had a number of browsers come along in the roughly 15 years that the internet has been readily accessible by the public, but since its inception around 13 years ago, there’s a reason why IE quickly rose to the top and has remained there.

    Okay – you MS haters go ahead and take some shots if you’d like. 🙂

  86. Non-Naive says:

    p.s.  Can someone please fix the script error on this page?!?!  It’s making me look bad for standing up for MS. 🙂

  87. "With IE8 we add support for RFC 2397’s Data URIs."

    If I am not wrong, IE8 implements data URIs only for images, and this is not specified anywhere in RFC 2397, which purpose is to make almost "everything embeddable".

    At the same time, data URIs could be cached without problems, but it is true that the client has to work harder because of base64 decode process.

    Now, in the "minimum 6 built in core CPU with 6Mb of L2 cache" era, I wonder if choose N files to download instead of a single one, loads of base64 encoded strings to transform, is really that big problem for clients.

    Anyway, I wonder if you are planning to add native JScript function to encode/decode base64 data (like atob, btoa, or similar stuff)

    Kind Regards and, in any case, good stuff, I am sure developers are appreciating your hard work.

    Thank you.

  88. Miko says:

    With IE8, when i access a page which requires Client certificate authentication, no certificates from my personal store are displayed.

  89. Bryan says:

    Great work.  We all look forward to an improved IE.  All the features and improvements are great.  But the best improvement of all would be the complete the removal of IE 6.  

  90. Megabyte says:

    Great work IE 8 Team!  The performance improvements are really appreciated and combined with the other changes, have made me switch back from FireFox to IE as my primary browser.  Would love to see similar performance improvements made to Vista. 😉

  91. IEBlog says:

    We’ve been sharing plenty about the work we’ve done in Internet Explorer 8 Beta 2 for browser users;

  92. IEBlog says:

    I’m Christian Stockwell, a Program Manager on the IE team focused on browser performance. Measuring the

  93. 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의

  94. IEBlog says:

    Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what

  95. &#160; &#160; 이 블로그에서&#160; 성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를

  96. &#160; &#160; 이 블로그에서&#160; 성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를

Comments are closed.

Skip to main content