Unshackling IE8 Performance

Artikkeli
07/20/2009

In general, IE8 is a significantly faster browser than prior versions. We made a number of major investments throughout the browser’s code to help ensure that IE users will have a great real-world experience on the web.

However, it is definitely the case that some users are experiencing abnormal and suboptimal performance when browsing. This post aims to demystify some of the problems we’ve seen that lead to poor performance, and help you resolve those problems. If your browser is lagging, please read on.

Note: This post primarily covers IE8, although some of the advice will work for IE7 as well. I strongly encourage all users to upgrade to IE8, and install all patches from WindowsUpdate.

Performance Measurement

First, let’s have a look at how to get more insight into where the time goes when IE is performing common operations like starting up or opening a new tab. For comparison’s sake, each of these operations takes well under 1 second on each of my computers.

A lightweight way to get more insight into your browser’s performance is to use the Process Monitor tool. Process Monitor allows you to view all registry, filesystem, and process activity on your computer, and includes a powerful set of filtering features to enable you to narrow down your view to just one process.

One caveat: It’s important to understand that Process Monitor is not the most in-depth profiling tool available, and understanding its results requires some skill-- I’m far from an expert myself. Christian’s blog post explains some of the perils of trying to perform accurate performance comparisons. However, with patience, even regular users can use Process Monitor to catch some performance bottlenecks.

When monitoring Internet Explorer, I take the following steps:

Close all IE windows.
Check Task Manager to be sure all iexplore.exe instances have shutdown.
Start Process Monitor.
Inside Process Monitor, click the menu item Filter > Filter… and add a rule ProcessName is iexplore.exe then Include to filter out events from other processes.
Start IE.

At this point, you will see new events in the Process Monitor log. You can clear the list at any time (say, to begin tracking a new scenario) by hitting CTRL+X. You can save the filtered events list to a log file using the File > Save menu.

With Process Monitor at the ready, let’s dig in.

Common Problems> Software Interactions

Internet Explorer exposes a powerful extensibility model and respects Windows’ system settings. While this power can be very useful, it also unfortunately means that other misbehaving software can greatly impact your browsing performance when using IE. In this section, I’ll cover some common performance issues caused by other software.

Common Problems> Software Interactions> Browser Add-ons

Browser add-ons are a top cause of slowness when IE starts, when new tabs open, and as you surf the web. They’re also a top source of crashes and security vulnerabilities. Unfortunately, many users have unwanted and unneeded add-ons installed and don’t even realize it. You can see the list of installed and enabled browser add-ons using the Tools > Manage Add-ons menu item inside IE. You can individually enable and disable add-ons; changes will take effect when the browser is restarted.

I strongly recommend that users who are experiencing performance problems try disabling browser add-ons: if performance significantly improves, then the bottleneck is likely one or more add-ons. For troubleshooting purposes, you can easily start IE without add-ons using the Internet Explorer (No Add-ons) item in the Start Menu, or use the command line iexplore.exe -extoff.

Now, it’s important to understand that not all browser extensions have the same impact on performance.

Toolbars and Browser Helper Objects (BHOs) load every time you start IE, and on every new tab you create. These are the most important add-ons from a performance perspective.
ActiveX controls run only when requested by the current website. Popular ActiveX controls used on many sites can cause performance problems.
Explorer Bars only run when they are made visible using the View > Explorer Bars menu.

Pluggable Transfer Protocols can have a major impact on performance and reliability, but unfortunately they are not listed inside Manage Addons. Transfer Protocol wrappers are often installed by download managers or offline frameworks like Google Gears.

The following types of extensions only run when you actively use them, so they usually have little impact on performance:

On the far-right side of the Manage Add-ons list, you’ll see a “Load Time” column. This column shows how long the toolbar or BHO add-on took to load. You can disable slow-to-load add-ons if you aren’t willing to make the performance tradeoff for whatever functionality they provide. For any add-ons you decide to keep, you should periodically check the add-on provider’s website for any updated versions.

Note: If the extension indicates that it's " Disabled " and you didn't disable it during this browsing session, then it's not actually loaded. The text "Currently loaded" in the dropdown is a bad choice of words, but " Add-ons that are or would be currently loaded *if* they were not previously disabled " isn't a great piece of UI text either. In the same list, " Run without permission " is another bad choice of words-- " Addons for which permission has been perpetually granted " is more accurate but wouldn't neatly fit.

By disabling unwanted add-ons, you can help ensure that IE is only spending time loading content and add-ons you care about.

Common Problems> Software Interactions> Security Software

Over the years, we’ve made huge investments in browser security and we’ve worked hard to make sure all of these new features have a minimal impact on browser performance. Unfortunately, the same cannot be said of all 3rd-party security software, some of which has a severe impact on IE Performance. Problematic characteristics of such software include:

Hooks – Some security software attempts to scan content as it flows through IE using either undocumented interfaces, or the Pluggable Transfer Protocols mechanism mentioned earlier. Unfortunately, this type of hooking incurs a significant performance cost, and often results in reliability problems as well. Sometimes, such hooks are implemented by modifying Internet Explorer’s private registry keys, leading to myriad, hard-to-diagnose problems.
Compression Stripping – As documented in Steve Souders' new book Even Faster Web Sites, some security products will strip off the Accept-Encoding request header that is used to signal to servers that they should send back compressed HTTP content if possible. By stripping the header, such products prevent servers from sending your browser compressed content, meaning that page downloads might take up to 500% longer. You can check if your browser is sending an Accept-Encoding header by looking in the Headers section here.
Security Zones Spamming – Some security products place a huge number of sites in the Restricted Sites zone. This can be useful because it prevents such sites from delivering file downloads or executing script, but the Zones system was not designed to accommodate thousands of manually specified sites and performance will suffer when Zones are configured in this way. From a security point-of-view, static blocklists like this aren’t a very good security mechanism, as they’re too easy to circumvent.

I recently took a deeper look at the “Security Zones Spamming” problem using a registry file provided by a user of one of the security products. The feature in question was named “Inoculate” or “Immunize” or similar, and it resulted in the addition of 40,000 registry entries within IE’s Zones keys. The customer sent me a registry export script (.reg) to analyze on my machine.

My machine is a pretty fast one: a Lenovo X200 with an Intel Core 2 Duo P8600 @ 2.4ghz, Intel X25-M SSD, 3gb of system memory, running 32bit Win7. Before I imported the 11MB (!!!) registry script, I took the following measurements using the the Tools > Registry Summary menu in Process Monitor:

Registry time on IE boot to about:blank took 0.1426863 seconds, with 12,387 total events.
Registry time on IE new tab to about:tabs took 0.0872716 seconds, with 7586 total events.

After I was done importing the scripts, I closed IE, cleared the Process Monitor log, and retook the measurements:

Registry time on IE boot to about:blank increased to 1.305558 seconds (915% ), with 222,481 total events.
Registry time on IE new tab to about:tabs increased to 0.6903690 seconds (791% ), with 112,602 total events.

The registry time captured by Process Monitor does not include any time spent on the IE side setting up the data structures into which the data is read and organized, so the registry time alone does not account for the full impact of having the Zones-Spamming feature enabled. Note: The CPU time was much greater before the June IE Cumulative Update, due to a bug in the algorithm used to populate the Zones in-memory cache.

Unfortunately, some security software will make these types of system changes without fully explaining their impact to the user, and troubleshooting such problems often requires careful examination with tools like Process Monitor. Users should be on the lookout for performance degradations after security software is installed.

Common Problems> Proxy Detection

Internet Explorer supports a mechanism called Automatic Proxy Detection which implements the WPAD algorithm. This allows the browser to find a proxy server on the local network without any fixed configuration information on the client. Unfortunately, WPAD can be a very slow process, because it involves multiple network lookups, which may take a long time depending on the network configuration.

You can see whether or not Internet Explorer is configured to Automatically Detect Settings by clicking Tools > Internet Options > Connections > LAN Settings. If you uncheck the checkbox, the WPAD feature is disabled. Internet Explorer includes an optimization such that, if the very first time WPAD runs, a proxy isn’t found, WPAD is auto-disabled, but this is mostly only useful for machines that are only used at home. If you move your computer between networks (e.g. a laptop) you may have WPAD enabled.

Corporate users should keep in mind that disabling WPAD can have some surprising side-effects, so it may be useful to quickly enable or disable the Automatically Detect feature. The IE Proxy Pick add-on (a command-bar button, so it doesn’t hurt performance :-) allows you to quickly switch between proxies. Command line junkies may prefer the command-line version.

Also, keep in mind that some corporate proxies will be configured with security software that performs compression stripping.

Conclusion

The IE team remains hard at work tracking down performance bottlenecks and working with 3rd parties to help reduce the performance impact of other software on your browsing experience. If you’re experiencing any IE8 performance problems, hopefully the tips above will help you isolate them.

If you have a performance tip (or find an add-on or product that hurts performance) please leave a comment below.

Thanks!

-Eric

Comments

Anonymous
July 20, 2009
I think it would be good for Microsoft to produce more information on specific security software versions and/or features that causes significant performance issues when using IE8. Else provide users with some easier and better means to detect such causes for the slow performance. Looking around on many sites, performance is one of the often mentioned issues of IE8 even though its speed increase compared to IE7 is very significant. The detection of many 'new' performance issues in new tab creating seem related to the tab isolation feature. A great feature but it seems to highlight the poor performance in IE new process starts caused by solutions provided by addon and security software builders which before were only visible at slower IE startup. The article example of putting in 40,000 registry entries to scan trough at a new process startup hightlight this problem.
Anonymous
July 21, 2009
Yes, the LCIE architecture certainly does bring increased attention to process startup time, and the impact that add-ons or unusual configurations (e.g. Zones-spamming) has on that time.
Anonymous
July 21, 2009
Part of the issue with performance is the "visual" perception. In addition to fixing the above mentioned items I feel that the "Connecting..." string in and of itself causes user frustration. When opening a new tab there is nothing to even connect to! thus users already get a sense that things are taking longer than needed. "Loading..." is a much, much more appropriate message. As for the removal of the spammed sites into the registry... I'm not sure how to explain this but it seems like they are cached for a while. I removed all that were in my list but I didn't see any improvement until days later. I'm using a laptop so I'm wondering if it wasn't until after a good reboot that they took effect? vs. hybernating? thanks for the info!
Anonymous
July 21, 2009
@marshal: The point on the misleading string is certainly valid. Registry updates will be effective as soon as all IE instances are closed and restarted. You need to make sure to remove both the HKCU and HKLM domains.
Anonymous
July 21, 2009
The comment has been removed
Anonymous
July 22, 2009
The comment has been removed
Anonymous
July 22, 2009
The Skype team reports that they've released an updated plugin with a lower performance impact. http://www.skype.com/go/download @FremyCompany: Great suggestions, thanks. :-)
Anonymous
July 27, 2009
My IE8 was extremely slow since a couple of weeks, sometimes just hanging. It was extremely fast when I started it without the add ons. After disabling the Skype add on it is back to its normal self. Thanks man, this helped!
Anonymous
July 31, 2009
The comment has been removed
Anonymous
July 31, 2009
@jj-- That's a fine configuration, although putting sites into the Intranet zone has some minor side-effects that aren't shown in the UI; generally, I'd recommend not using the Intranet zone in this way and simply use the Internet, Trusted, and restricted zones. In terms of import/export, while it's technically unsupported to do so, all of these settings are maintained in the registry, so you could copy them from machine to machine in a .REG script.
Anonymous
August 01, 2009
The comment has been removed
Anonymous
August 08, 2009
The comment has been removed
Anonymous
August 09, 2009
The comment has been removed
Anonymous
August 09, 2009
The comment has been removed
Anonymous
August 09, 2009
The comment has been removed
Anonymous
August 09, 2009
Btw, it seems to happen mo often on the Vista home basic laptop. Mayby some limit that is set low on home basic ?
Anonymous
August 09, 2009
To be clear: If you hit STOP and type a different URL on a different server, the tab still spins without making progress, right? Does Fiddler show any network traffic? Connection limits are the same across SKUs. You could test if it's a limit problem by kicking the connection limit up. Run http://www.enhanceie.com/dl/fixHTTPMax.reg (or see http://www.enhanceie.com/ie/tweaks.asp) Your IE proxy settings are all unchecked inside Tools / Internet Options / Connections / LAN Settings, right?
Anonymous
August 10, 2009
Yep, If I hit stop and type a different URL on a different server the tab still spins without making progress. I wil try to use fiddler the next time this issue happens because it is fairly unpredictable behaviour happening to me about once a week.
Anonymous
August 10, 2009
I have found that quite a few people have this issue. The only possible solution I have seen was that the AVG linkscanner might be responsible. A few people that have switched of this feature from AVG reported that their problems disappeared and a lot of the people reporting this kind of issues seem to have AVG installed. I'll keep this feature on to reproduce the issue for now.
Anonymous
August 10, 2009
I also just now found this bug report on the AVG forums http://forums.avg.com/ww.avg-free-forum?sec=thread&act=show&id=11615
Anonymous
August 13, 2009
I got this message in the browser using fiddler [Fiddler] Connection to www.google.com failed. Exception Text: Een verbindingspoging is mislukt omdat de verbonden party niet correct heeft geantwoord na een bepaalde tijd, of de gemaakte verbinding is mislukt omdat de verbonden host niet heeft geantwoord 74.125.79.105:80 It states something like that the connection has failed because the connected party has not responded after a certain amount of time, or the existing connection has failed because the connected host has not answered. I used Google as an example as it seem unlikeky this was unavailalbe but I had the same result on multiple destinations.
Anonymous
August 13, 2009
@hAl: Sounds like you have a dodgy network connection. Please post up at the Fiddler discussion group for further help on this issue. (Fiddler is written against .NET sockets, btw).
Anonymous
August 16, 2009
Eric, great comments on this and other forums. Thanks for sticking with it despite some of the criticisms. I too have found a problem with slow opening of new tabs. MS definitely must make the interface avaiable to the user ASAP and continue with its "processing" work in the background. And be sure to switch focus to the new tab ASAP as well. If a person presses "Ctl T", I think it is safe to assume they want to get on with something (and not wait). . . I'll try some of these suggestions. If there is a solution, will there be an update via Windows Update? Or will it have to wait for a new rev?
Anonymous
September 20, 2009
The comment has been removed
Anonymous
September 28, 2009
In your text, you state that "Pluggable Transfer Protocols can have a major impact on performance and reliability, but unfortunately they are not listed inside Manage Addons." How could we determine if any such protocols are active on our systems?
Anonymous
September 29, 2009
@Jeff: Unfortunately, it's not trivial, because protocol handlers can be either statically registered, or dynamically registered. Statically registered protocols are comparatively easy to spot; just look to see if "FTP", "HTTP", or "HTTPS" keys exist inside the registry key: [HKEY_CLASSES_ROOTPROTOCOLSName-Space Handler] For dynamically-registered protocol handlers, I'm afraid there's no good way to tell short of running a debugger. Of course, only a DLL running in-process to IE (e.g. Google Gears) can dynamically register a protocol handler for that process, so if you minimize the number of browser add-ons you have installed, you can help reduce the possibility of having an unstable or slow protocol handler installed.
Anonymous
November 12, 2009
The comment has been removed
Anonymous
November 12, 2009
The comment has been removed
Anonymous
February 14, 2010
I'm looking for a way to troubleshoot IE8 on vista32 crashing at startup (access violation). This behavior disappear if IE is started with admin privileges. Tried disabling extension but the crash still there. There's some way to do some logging of operations to understand what's the offending part? Tried also debugging with vs, but it seems that no symbols loads for the stack so almost impossible for me to understand what's going on...
Anonymous
February 25, 2010
@Carlo: If you send me the .DMP file, I can debug this for you. Further discussion over here: http://blogs.msdn.com/ieinternals/archive/2009/10/12/Collecting-Internet-Explorer-Crash-Dumps.aspx
Anonymous
April 16, 2010
Ielowutil.exe runs whenever I run IE8 and really drags the system down. Reading the MS white-paper on the subject I disabled all; addons and it helped but only temporarily. My wife's 32 bit machine didnt have the problem. I ran the 64 bit version on my machine and the problem went away.
Anonymous
April 16, 2010
@Bert: IELowUtil is a part of IE itself (used by Protected Mode). I'm not sure why you believe it's "dragging" the system down?
Anonymous
May 05, 2010
Look at mshta performance! After I upgraded to IE8 on W2K3 SP2, my mshta performance degraded a lot, especially on text and windows rendering and scrolling it. IE8 is a step backward imho.
Anonymous
May 05, 2010
@Svyat: We've observed no regression in performance with MSHTA. MSHTA does almost nothing beyond host a Trident instance, just like IE does.
Anonymous
January 27, 2011
To me, the most important performance metric is how fast a web browser can shut itself down, closing 30+ tabs in the process. I generally open web pages in new tabs, one at a time, and I can live with that taking a second or few. But I routinely have multiple tabs open, and if I need to shut down in a hurry, it's maddening waiting for the browser to close them all down! Also, here's a usability feature that would also improve perceived (functional) performance; the ability to multi-select arbitrary tabs to operate on (e.g. close, add as Favorites group) as one action.
Anonymous
January 27, 2011
@Chris: You'll be happy to know that we've invested a bunch of time in making tab shutdown faster in IE9.
Anonymous
November 06, 2012
In my case Automatic proxy detection was the problem. Once I've disabled the feature - the browser returned to it's normal startup times.

Jaa