Updates to Add-on Performance Advisor
The
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
positive and
constructive 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
impact 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
Add-on Performance Advisor monitors add-on performance and notifies you
only when your add-ons are
noticeably 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
browsing:
| 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:
We updated the notification message and added an option in the dropdown menu for
the “Ask me later” button:
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
clearer to users that they can choose which ones to enable:
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:
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:
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
Anonymous
March 23, 2011
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!Anonymous
March 23, 2011
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.Anonymous
March 23, 2011
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?Anonymous
March 23, 2011
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: vadikom.com/.../ie9-rtm-font-rendering-related-bug.html Hope someone will take care of it. Cheers!Anonymous
March 23, 2011
@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)Anonymous
March 23, 2011
@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.Anonymous
March 23, 2011
@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.Anonymous
March 23, 2011
Why is ClearType selectively/partially enabled in the 2nd and 2nd last screenshots?Anonymous
March 23, 2011
The comment has been removedAnonymous
March 23, 2011
@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 www.w3.org/.../cssom-view) though internal calculations are done in higher precision units.Anonymous
March 23, 2011
I am using IE9 and I must say its marvelous Easy to use and friendlyAnonymous
March 23, 2011
Great job.Anonymous
March 23, 2011
The summer is coming,there are so many kinds of sunglasses.Anonymous
March 23, 2011
Some points:
- 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.
- 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.
- Invest in a copy of Window Clippings :) Better yet, integrate a screenshot tool into Windows that captures transparency.
Anonymous
March 23, 2011
The comment has been removedAnonymous
March 23, 2011
@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.Anonymous
March 23, 2011
Will the Internet Explorer development cycle will be shorter? Any word on when Internet Explorer 10 will be available?Anonymous
March 23, 2011
Our Outlook 2007 shop could really use something like this on that platform!Anonymous
March 24, 2011
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.Anonymous
March 24, 2011
@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.Anonymous
March 24, 2011
@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?Anonymous
March 24, 2011
@Vasil 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?Anonymous
March 25, 2011
The comment has been removedAnonymous
March 25, 2011
And to prove the point: img9.imageshack.us/.../testxnx.png A result of zooming in on Firefox 4.Anonymous
March 25, 2011
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.Anonymous
March 25, 2011
@AndyC 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). @DT > 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.Anonymous
March 25, 2011
@Vasil 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.Anonymous
March 27, 2011
@AndyC 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: vadikom.com/.../ie9-rtm-font-rendering-related-bug-proposed-fix.html 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...Anonymous
March 29, 2011
Bad news for plugins, mainly for to 'uninformed' users. Pay attention!Anonymous
April 03, 2011
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.Anonymous
April 04, 2011
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!! http://www.binaryrepublik.com
