IE8 Performance

Artigo
08/26/2008

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):

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

Comments

Anonymous
August 26, 2008
PingBack from http://hoursfunnywallpaper.cn/?p=3191
Anonymous
August 26, 2008
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. Cheers,

Bill

Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
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! :-)
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
Great! Now add the download manager with pause/resume capability!!!!!!
Anonymous
August 26, 2008
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?
Anonymous
August 26, 2008
Gotta say I love it. Haven't been this excited about a browser release for a long time. Keep up the good work
Anonymous
August 26, 2008
Looking forward to using IE8! Awesome IE I think,fast as you can ,dude ,I am waitting for!
Anonymous
August 26, 2008
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).
Anonymous
August 26, 2008
@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).
Anonymous
August 26, 2008
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? ;)
Anonymous
August 26, 2008
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 slashdot.org recently but they've now removed the offending code. The site was nearly unusable for few days on IE.
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
great! today i could open my college web(LAN),but somedays before it can not open this address:http://campus.sztc.edu.cn/newweb/index.htm
Anonymous
August 26, 2008
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?
Anonymous
August 26, 2008
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!
Anonymous
August 26, 2008
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 http://blogs.msdn.com/ie/archive/2008/08/25/ie8-and-privacy.aspx Another post is rushed out immediately!!!
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
The comment has been removed
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
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!
Anonymous
August 26, 2008
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.
Anonymous
August 26, 2008
Frustrated: get IETester, it's the best and most simple solution to have multiple IE versions on the same PC.
Anonymous
August 26, 2008
@SamY, 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.
Anonymous
August 26, 2008
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?
Anonymous
August 27, 2008
" 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 ?
Anonymous
August 27, 2008
Hmm... it looks like one of my comments didn't get through. Please make IE not hang when visiting http://www.crashie.com/. Not sure if it's a performance issue, but it's definitely a major robustness failure. Right now it completely locks IE 8 up.
Anonymous
August 27, 2008
That sounds like a good improvement. Congrats.
Anonymous
August 27, 2008
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.
Anonymous
August 27, 2008
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.
Anonymous
August 27, 2008
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:

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

Anonymous
August 27, 2008
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. Chilá!@!
Anonymous
August 27, 2008
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.
Anonymous
August 27, 2008
Great news! And to think, all this thanks to the original Firefox team. Boy, we owe them more than we will ever understand.
Anonymous
August 27, 2008
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. Why? 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.
Anonymous
August 27, 2008
hey, i'm from Firefox team we are missing your cakes when you will send another? keep trying to be Firefox, IE , good work
Anonymous
August 27, 2008
@Brian, "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. :(
Anonymous
August 27, 2008
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 http://css-class.com/test/bugs/ie/8/overflow-hidden-p-r-child.htm 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 run..like 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.
Anonymous
August 27, 2008
The comment has been removed
Anonymous
August 27, 2008
The comment has been removed
Anonymous
August 27, 2008
The comment has been removed
Anonymous
August 27, 2008
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.
Anonymous
August 27, 2008
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.
Anonymous
August 27, 2008
We’re excited to release IE8 Beta 2 today for public download. You can find it at http://www.microsoft.com/ie8
Anonymous
August 27, 2008
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
Anonymous
August 27, 2008
Firefox 3.0.1 is 2.47x faster than IE 8 beta 2 according to SunSpider. document.addEventListener is undefined.
Anonymous
August 27, 2008
What are the top 100 sites you use for benchmarking?
Anonymous
August 27, 2008
good work ,for me the good news are the perfect support fo css2.1 ,thanks for your work
Anonymous
August 27, 2008
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.
Anonymous
August 28, 2008
The comment has been removed
Anonymous
August 28, 2008
Many folks have commented and written email about the topic of performance of Windows. The dialog has
Anonymous
August 28, 2008
The next beta for Internet Explorer has been released for broad distribution to the public, according
Anonymous
August 28, 2008
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"
Anonymous
August 28, 2008
"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.
Anonymous
August 28, 2008
Fixing performance issues that have plagued previous versions of its Windows client OS and Internet Explorer
Anonymous
August 28, 2008
The comment has been removed
Anonymous
August 28, 2008
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..???? lol..it displayed page perfectly...
Anonymous
August 28, 2008
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.
Anonymous
August 29, 2008
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.
Anonymous
August 29, 2008
.NETGarbageCollectionNotificationsin.NET3.5SP1TestplanChecklistforAsp.Net.NETFramewo...
Anonymous
August 29, 2008
.NET Garbage Collection Notifications in .NET 3.5 SP1 Testplan Checklist for Asp.Net .NET Framework 3
Anonymous
August 29, 2008
honestly am impressed with the speed. IE8 beta2 start in no time. am using vista ultimate.
Anonymous
August 29, 2008
The comment has been removed
Anonymous
August 29, 2008
The comment has been removed
Anonymous
August 30, 2008
I know it is off topic but there are a couple blogs posts of MSDN I found interesting. IE 8 Performance
Anonymous
August 30, 2008
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.
Anonymous
August 31, 2008
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...
Anonymous
August 31, 2008
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, http://www.softpedia.com, 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.
Anonymous
September 01, 2008
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 www.dhteumeuleu.com, 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 !
Anonymous
September 01, 2008
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.
Anonymous
September 02, 2008
The comment has been removed
Anonymous
September 02, 2008
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 !
Anonymous
September 02, 2008
"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.)
Anonymous
September 03, 2008
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.
Anonymous
September 03, 2008
The comment has been removed
Anonymous
September 03, 2008
RE: "I personally can't wait for Google Chrome to come out." It's out already. And IT ROCKS.
Anonymous
September 03, 2008
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.
Anonymous
September 04, 2008
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. :-)
Anonymous
September 04, 2008
p.s. Can someone please fix the script error on this page?!?! It's making me look bad for standing up for MS. :-)
Anonymous
September 04, 2008
"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.
Anonymous
September 05, 2008
With IE8, when i access a page which requires Client certificate authentication, no certificates from my personal store are displayed.
Anonymous
September 05, 2008
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.
Anonymous
September 06, 2008
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. ;-)
Anonymous
September 08, 2008
We’ve been sharing plenty about the work we’ve done in Internet Explorer 8 Beta 2 for browser users;
Anonymous
January 23, 2009
I’m Christian Stockwell, a Program Manager on the IE team focused on browser performance. Measuring the
Anonymous
February 19, 2009
이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의
Anonymous
March 19, 2009
Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what
Anonymous
May 21, 2009
    이 블로그에서  성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를
Anonymous
May 28, 2009
    이 블로그에서  성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를

Partilhar via