IEInternals

A look at Internet Explorer from the inside out. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent (http://useragents.ie) in '14

Unshackling IE8 Performance

Unshackling IE8 Performance

Rate This
  • Comments 37

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:

  1. Close all IE windows.
  2. Check Task Manager to be sure all iexplore.exe instances have shutdown.
  3. Start Process Monitor.
  4. 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.
  5. 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

  • Btw, it seems to happen mo often on the Vista home basic laptop.

    Mayby some limit that is set low on home basic ?

  • 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?

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

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

  • 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

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

  • @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).

  • 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?

  • I noticed my system will come to a crawl playing Mafia Wars on Facebook, as well as other pages, which typically use Flash content, such as embeded video.

    It seems to be related to virtual memory. I keep a fairly clean system with a recent reformat and no unnecessary add-ons running in the background since I'm using an old system: Windows XP, 1.8 GHz CPU, 768 MB RDRAM (400x2 MHz), 100 MHz system bus, 512 KB system cache, 9800 Radeon Pro at 4x AGP (I get 20-30 fps when I should get 40-60 fps) with 256MB and 1280x1014x32 resolution, 2 80GB WD drives with the newest one with a larger cache as the system drive.

    The iexplore.exe memory use gets up to around 150,000 - 300,000 KB when it starts to crawl.

    I do have a couple of pieces of software that I'm not sure if they're eating resources (virtual cd/dvd rom and the Catalyst drivers) though nothing shows up on the Task Manager. I still shouldn't be digging into a page file that is over 1GB.

    I don't run a virus scanner, using Windows firewall, and don't use any system tray tools. Most everything is disabled from 3rd party background services. I do use Tortoise SVN and CVS, with CVS NT installed but disabled and the SVN cache disabled.

    Upgrading my system to the Best Buy eMachine would be cheaper than upgrading the RDRAM though I'd rather avoid spending the money on a Windows Vista system where I have a lot of licensed XP software that might not work on Vista.

  • 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?

  • @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_ROOT\PROTOCOLS\Name-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.

  • There appears to be an import of existing add-ons from IE7 which becomes a problem when attempting to clean a machine which has had problematical ones installed; you can disable them but you can't kill them.  If someone knows of a solution, including a third or fourth re-install, please let me know.

  • @cracker: There's no "import" per-se; all versions of IE use the same registration mechanism, so by-default, extensions installed in IE6 will be installed in IE8 unless explicitly blocked by the Upgrade Advisor.  You should use the Manage Add-ons UI to disable add-ons you don't want.

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

  • @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

Page 2 of 3 (37 items) 123
Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post