Updates to Add-on Performance Advisor

Add-on Performance Advisor
helps you stay in control of your browsing experience
with add-ons. Since we introduced this feature in IE9 Beta, the
feedback you provided enabled us to adjust the functionality
while maintaining its original goals. You can experience these changes in action
with the final release of IE9.

In this post, we review the issues users face today with add-on performance and
the benefits offered with this feature. We describe the rationale behind the key
changes we made and show how they improve the user experience and more accurately
measure add-on performance. Along the way, we address some frequently asked questions
on the feature’s functionality.

Recap: Add-ons and Performance

Add-ons can have a material
on browsing performance, most notably in the following activities:

  • Opening a New Tab
    Every time you open a new tab or browsing window, IE initializes your add-ons. The
    time it takes each add-on to initialize is its load time.
  • Navigating to Web pages
    Every time you visit a Web page, your add-ons can perform operations on the page,
    such as adding icons next to search results or scanning links to identify phishing
    sites. The time it takes an add-on to perform these operations for each navigate
    is its navigation time.

Many users have multiple add-ons installed and running in their browsers. The cumulative
performance impact of all these add-ons affects the overall experience of browsing
and viewing a Web site.

While we
work with add-on developers
to improve add-on performance, it’s important
for you to understand add-ons’ performance impact and how to manage them. The href="http://blogs.msdn.com/b/ie/archive/2010/09/17/add-ons-staying-in-control-of-your-browsing-experience.aspx">
Add-on Performance Advisor monitors add-on performance and notifies you
only when your add-ons are
slowing down your browsing experience. You can choose to use
only the add-ons you want while maintaining browsing performance.

Accurately Measuring Add-on Performance

We made two changes to our add-on performance measurement algorithms since IE9 Beta:

  • IE no longer records the first load time for all add-ons after upgrading to IE9
  • IE no longer records an add-on’s first load time after it is installed and enabled
    for use in IE9

Here’s a brief explanation of the change. While analyzing the load times for 15
of the most
popular add-ons in IE8
we found that the average add-on load time in the
above two scenarios were notably higher than the average load time during regular

Load Time Measurement Scenario Average Load Time (milliseconds)
Launch IE9 regularly 37
IE9 first run after upgrade 399
Add-on first run after it is enabled in IE9 300

This difference in load time exists because add-ons typically perform more operations
when launched for the first time. Additionally, since IE takes longer to launch
for the first time, it shares system resources with add-ons and will increase add-on
load times.

It’s important that we measure an add-on’s load time accurately and consistently
so that you can make the right decisions on your add-ons. We decided not to record
load times in the above two scenarios with this goal in mind.

For example, in IE9 Beta you may prematurely disable an add-on that you like because
its first load time is notably higher and triggers the Add-on Performance notification.
With the current functionality, we will show the Add-on Performance notification
only if we continue to measure high load times for that add-on.

Evolving Notifications

We received lots of
good feedback
regarding the design of the Add-on Performance notification
since Beta. We’ve since refined the design for the final IE9 release:

Screen shot of notification bar asking to speed up browsing by disabling add-ons

We updated the notification message and added an option in the dropdown menu for
the “Ask me later” button:

Screen shot of "Ask me later" options in notification bar asking to speed up browsing by disabling add-ons

If you are satisfied with your add-on performance even though it is above your desired
threshold, you can select the “Don’t disable” option to turn off the Add-on Performance
notification for 30 days. If you prefer not to make a decision on your add-ons yet,
you can select the “Ask me later” option which only turns off the notification for
1 day.

Once you install and enable a new add-on, IE will turn the Add-on Performance notification
back on since the new add-on may impact browsing performance beyond your previously
desired levels.

When multiple new add-ons are installed, we made it
to users that they can choose which ones to enable:

Screen shot of notification bar indicating there are new add-ons ready for use

Choose Add-ons Dialog

You can launch the Choose Add-ons dialog via both the above notifications. When
it’s launched from the Add-on Performance notification, we show the following variation
of the dialog:

Screen shot of the Choose Add-ons to disable dialog box

Some of you asked how IE decides which color is used to display the bars in the
above dialog. Our intention is to use the colors to indicate the minimum number
of add-ons that need to be disabled so that you can stay below the threshold. In
the above dialog, disabling the Contoso and Litware toolbars, which have red bars,
leaves you with 0.04 seconds of total load time.

You may decide to only use the Contoso Toolbar. If you disable all the other add-ons,
we’ll display a grey bar for the Contoso Toolbar indicating that you’re now below
the threshold. Similarly, you can change the default threshold to 0.50 seconds and
all the above add-ons will have grey bars displayed.

Notice that we lengthened the default height of the above dialog to accommodate
6 add-ons before requiring you to scroll. This helps you make the most informed
decision on which add-ons to use since you can view the performance impact of more
add-ons at one glance. We also added a confirmation dialog when you press “Disable
All” so that you don’t accidentally disable all your add-ons:

Screen shot of confirmation alert shown when disabling all add-ons

Thanks for Your Feedback

The feedback you’ve given us on the Add-on Performance Advisor since IE9 Beta allowed
us to improve the overall user experience and add-on performance measurement accuracy.

In a future post, we’ll blog more about add-on performance and how the ecosystem
has evolved since we
started the conversation
around measuring and improving performance. We’ll
continue to engage with add-on developers on improving add-on performance through
blog posts and other efforts. The ideal experience is one where you can use as many
add-ons as you want without compromising browsing performance (and reliability,
security, and privacy).

—Herman Ng, Program Manager, Internet Explorer

Comments (31)
  1. Parrotlover77 says:

    IE Team – I may not understand the purpose of some of the new IE9 features (pinned sites, for example), but this feature is hands down one of my favorites.  It gives me immediate actionable feedback when an addon is misbehaving.  Also, I love the new prompt to enable new addons after they are installed as a double check that I actually want the darn thing.

    Kudos to you on this feature.  Finally people will see that if their browsing experience is slow, it's not always IE's fault!

  2. MacGyver says:

    Indeed, probably one of the least useful new features to 'informed' users but invaluable, and probably one of the most important, to 'uninformed' users. You're providing a clean and concise answer to a question everyone will pose: "why is my browser (suddenly) so slow?".

    The only thing I would change is the design of the notification, it feels very utalitarian; it should integrate more with the browser chrome.

    Add the same to Windows concerning programs that cause a slow startup. I know something similar is already available but it's not as visible as this at all.

  3. Dan says:

    I'd rather have a direct link to this to view it WHEN I WANT!  – for now, I have to set it to show on ZERO seconds so that it always shows up and then I have to dismiss it on every re-start. (Very Annoying!)

    I agree for most users they won't care, but I care and want to be able to check whenever I want.

    Is there an about:addonperformance type magic URL that will display it?

  4. Vasil Dinkov says:

    Sorry for the complete off-topic but for some reason I am not able to join the Internet Explorer Feedback Program using my main browser Opera so I decided to post this sweet little IE9 RTM bug (font rendering related?) here:


    Hope someone will take care of it.


  5. Richard says:

    @Dan – Hey there Mr Anger Management, you can see the timings whenever you like by going to Tools :: Manage add-ons and scrolling to the right (it's the last two columns)

  6. @Vasil Dinkov: You're correct in that the behavior you see is sub-pixel font related but it's more subtle that than. When you get the offsetWidth of the span, you get an integer value. However, the internal calculations are done in fractional units and the actual width of the span is fractionally wider than the integer returned. If the code in TriggerBug() is changed to

    div.style.width = (span.offsetWidth + 0.5).toString() + 'px';

    the example works. Given the current DOM implementation where properties such as offsetWidth are rounded to the nearest int, you should probably add half a pixel (or a whole pixel) when doing these kind of calculations.

  7. @Vasil Dinkov: Let me amend my advice. Adding 0.49 is better than adding 0.5 because 0.49 will round down to the same integer meaning that repeated calculations won't grow. Also, the pixel-aligned boundaries of the span and div elements will still align.

  8. Snowknight26 says:

    Why is ClearType selectively/partially enabled in the 2nd and 2nd last screenshots?

  9. Neville says:

    @Ted Johnson [MSFT] – do we understand you correctly that because IE decided to change font rendering (and completely mess it up and ignore user preferences by the way) that when we now use the available DOM API's to measure components to the nearest pixel we will now have to account for the fact that IE has messed up font rendering in order to make our Standards based code work in IE9?!?!

    Can we get official word from Microsoft that:

    a.) In a soon-to-be-released patch, the ClearType anti-alias setting in IE will be a USER-SET-PREFERENCE and DEFAULT to the user's Windows setting.

    b.) In a soon-to-be-released patch, that getting a width or height property like offsetWidth will return the CORRECT integer value for a CONTAINER that CONTAINS the OBJECT since that is what we are asking for in the first place with the well defined official API SPECIFICATIONS.

    If we wanted to have approximate getters we would request a full API like this:

    var width = someObject.almostKindaTheFullWidth;

    var height = someObject.almostKindaTheFullHeight;

    Its not our fault that the new IE9 anti-aliasing wasn't ready for prime time when SXSW rolled into Austin.  Please fix the settings (a, b) above ASAP or roll back the anti-aliasing of text in IE9 until it is actually ready for the Web.


  10. @Neville: Actually, the behavior I describe is present in IE8 at zoom factors other than 100%. The root problem is not anti-aliased fonts but the CSSOM View specification that defines these properties as long integers (see http://www.w3.org/…/cssom-view) though internal calculations are done in higher precision units.

  11. Silvio America says:

    I am using IE9 and I must say its marvelous Easy to use and friendly

  12. JoeH says:

    Great job.

  13. oakley sunglasses outlet says:

    The summer is coming,there are so many kinds of sunglasses.

  14. Quppa says:

    Some points:

    1. That's quite a low load time for the Java Plug-In 2 SSV Helper. Has Sun improved it since the IE8 timeframe? I can't imagine how many people's IE experiences must have been ruined by that add-on.

    2. What on earth is going on with the fonts in the screenshots? There is no anti-aliasing in most of the 'Choose Add-ons' window and in the 'Ask me later' menu, even though ClearType is present everywhere else.

    3. Invest in a copy of Window Clippings 🙂 Better yet, integrate a screenshot tool into Windows that captures transparency.

  15. Ooh says:

    @Ted Johnson [MSFT]: Yep, in the end the problem is related to being more precise than what the spec says. Totally agreed and understood. (People in WPF land face this all the time: calculations are done in doubles though the screen is in whole pixels.) What would happen if instead of Round() you would use Floor() and Ceiling() to transform the higher precision values to integers? Have you tried that? Did it cause other more serious compatibility problems? As a software engineer I'm eager to find out more about how you approached the problem.

    @Neville: To be fair, as strange as it sounds but a 14px box can indeed contain a 14.2px text thanks to layout rounding. Since the spec does nowhere say anything about how to handle such things it is not even a spec violation by IE! It's the classical problem we software engineers have faced for plenty of time: "correct" (read appropriate) rounding [1].

    [1] en.wikipedia.org/…/Rounding

  16. Frank says:

    @Ooh- while I agree this is a classical software problem I most certainly Do Not agree that microsofts implementation is correct.

    When asking for the width of an element to the nearest pixel… If internally it measures 14.2px then I MUST ROUND UP in order to get the Correct full pixel width!

    @Neville- although I agree it is a bug I expect that MSFT will push this fix silently as part of a security update for IE because it has been my experience that MSFT has a very hard time admitting they've made a mistake.

    I too hope that Microsoft shapes up and releases a patch that allows users to turn off the horrific blurry font rendering in IE9 as a user setting.  I have no plans to use IE9 until it is fixed – I value my eyesight thanks very much.

  17. Eduardo Valencia says:

    Will the Internet Explorer development cycle will be shorter?

    Any word on when Internet Explorer 10 will be available?

  18. mark.dowling@gmail.com says:

    Our Outlook 2007 shop could really use something like this on that platform!

  19. hdmi says:

    Nice try in blocking FF 4 with that trusted site trick.  Didn't work on me but I'm sure it will stop quite a few people.

  20. Ooh says:

    @Frank: I did intentionally NOT use the word bug, I merely pointed out that from my point of view it's no spec violation. However I can totally relate to your and Neville's opinion that IE should use Floor() and Ceiling() for its calculations to return comprehensible values. Nevertheless, they might have tried that and came to the conclusion that it is a bad idea — therefore I asked Ted to clarify this issue a bit. So at this time I don't wanna judge whether it's a bug (i.e. unintentionally wrong) or has been implemented that way intentionally.

  21. Vasil Dinkov says:

    @Ted Johnson [MSFT]

    Hmm, so you suggest modifying scripts that have worked for years without any problem in older IE versions and continue work correctly in ALL other modern browsers just because you decided to change slightly font rendering in IE9?

    And to cite @Ooh:

    > Since the spec does nowhere say anything about how to handle such things it is not even a spec violation by IE!

    OK, I agree it's not a spec violation but WHY do it now in IE9 and break thousands of scripts out there when no other browser is doing it this way?

  22. DT says:


    Do you believe that the other browsers aren't going to transition to working this way?

    If you do think that the other browsers are going to start doing this at some point, when exactly would you have preferred it being done in IE?

  23. AndyC says:


    As Ted mentions, scripts will already break at different zoom levels and consequently on any IE8 machine that has a high dpi display (which a lot of laptops do). I expect you'll probably see similar breakages on other browsers with zoomed content too. If there is a flaw anywhere, it's in the spec rather than the implementation.

  24. AndyC says:

    And to prove the point:


    A result of zooming in on Firefox 4.

  25. Pedro says:

    Is there any way for a webpage to know that a given add-on has been disabled by the user? My company needs to detect this situation and instruct users to re-enable them. I've tried using try { new ActiveXObject() } catch( e ) {} but the error code returned (0x800A01AD) is the same as if the user hadn't even installed the BHO in the first place.

    Right now, we don't have any way to either 1) reinstall the add-on, because IE9 will block the install request if it's been disabled 2) detect that it has been disabled so we can instruct our users.

  26. Vasil Dinkov says:


    No-one expects perfect results when zooming in/out, it's obvious there would be issues with custom percentages. But the situation at the moment is that all browsers get it right at 100% zoom except IE9 (in certain cases).


    > Do you believe that the other browsers aren't going to transition to working this way?

    To be honest, I have no idea. If someone at MS has any information on the subject, please share it with us. If other browser vendors have plans to go this way, then, of course, no-one is going to complain.

  27. AndyC says:


    If you follow Ted's suggestion of adding 4.9 it should work regardless of zoom level or font size and it's a pretty common practice when wanting to round off floating point values (which are inherently innaccurate) to integer values. As far as other browsers go, Firefox 4 definitely already uses sub-pixel positioning (and so could hit this 'bug' at a 100% zoom level) and I believe Safari does too. Scripts which already exist but assume this isn't an issue are already broken, it would make far more sense to fix those than to tweak IE9 in this case.

  28. Vasil Dinkov says:


    It's admirable to be so sure in your assumptions but sometimes you should really check the facts first.

    > If you follow Ted's suggestion of adding 4.9 it should work regardless of zoom level or font size…

    Not true. The fix only seems to work fine at 100% zoom in IE9. At other zoom levels sometimes additional unneeded pixels are added.

    > As far as other browsers go, Firefox 4 definitely already uses sub-pixel positioning (and so could hit this 'bug' at a 100% zoom level) and I believe Safari does too.

    Not true (for any of the mentioned browsers or any other browser). Here's a more thorough test case – feel free to test it with whatever browser you like. It works correctly in all but IE9 at the default 100% zoom level:


    So to recap the situation again – only IE9 requires this fix at the moment to work correctly at the default zoom level and unless MS has any information about other browsers possibly planning to switch to this model, then it would be really a shame if this isn't fixed in IE in the future.

    > Scripts which already exist but assume this isn't an issue are already broken, it would make far more sense to fix those than to tweak IE9 in this case.

    I am not sure you are aware of it, but this feature has worked the same way since the first time it was implemented in IE4 (was it 1997?). And now IE9 is the first ever browser to require additional "fixes". And you say scripts are already broken, hmm…

  29. Danilo - Bradesco Bank says:

    Bad news for plugins, mainly for to 'uninformed' users. Pay attention!

  30. Peter Bright says:

    FYI, it's not an IE9 "issue", it's a DirectWrite "issue". Using Firefox 4 with hardware acceleration (including DirectWrite), and dl.dropbox.com/…/floating-point-issues.html shows the same floating point rounding behaviour.

    It's actually quite frustrating (it's interfering with some scripting I am attempting, where I assume that text widths add up exactly), and in my view there needs to be a way to access the exact dimensions.

  31. SharePoint Consulting says:

    I like this concept. I visited your blog for the first time and just been your fan. Keep posting as I am gonna come to read it everyday!!


Comments are closed.

Skip to main content