Add-on Performance Part 1: Measuring Add-on Performance

In previous posts, we’ve written about the ways we’re making IE9 much faster, like the new script engine that uses multiple cores, and the new rendering subsystem that uses the dedicated graphics chip found on modern PCs. Another aspect of browser performance involves the external code that IE runs on behalf of users, or add-ons.

Add-ons introduce unique features that can enhance the browsing experience. However, they also decrease the browser’s performance in crucial activities like navigating to webpages and creating new tabs. In this way, add-ons affect key usage scenarios like startup and navigation.

Add-on performance is integral to an overall fast browsing experience. IE users expect the browser to be fast, with or without add-ons. We work towards several common goals with add-on developers: providing valuable features with the smallest performance and reliability impact possible (more on reliability in another post).

This blog post is the first in a series on how add-on developers can improve add-on performance. In this post, we’ll share data on the performance impact of add-ons today and how IE enables users to identify the performance impact of their add-ons and stay in control of their PCs. We’ll describe the user scenarios that are important for measuring performance and will walk through how to measure them.

We want add-on developers to have all the information they need to deliver fast, reliable add-ons that respect user choices. We want to make it clear how to test add-on performance. We ask add-on developers to start measuring add-on performance today and making their add-ons faster.

What is An Add-on?

Add-ons refer to Toolbars, Explorer Bars and Browser Helper Objects today. When add-ons are enabled in the browser, they can cause a performance impact for every tab opened and every webpage the user visits.

Another common type of extension is plug-ins, specifically ActiveX controls, like Adobe Flash, Apple QuickTime, and Microsoft Silverlight. Unlike add-ons that run in the browser across all web-pages, plug-ins run inside webpages and their performance impact is localized to the webpages that use them. The specifics of this post are about add-ons. Plug-in developers have similar opportunities to make the browsing experience faster and more reliable.

Accelerators, Webslices and Search Providers are a third class of extension. These are written in pure XML format, and were designed to not impact page or browser performance, reliability, or security.

Toolbar Buttons are another type of extension but they only impact IE’s performance when users press them and they’re mapped to an action that launches an add-on.

Understanding Add-on Performance Impact Several studies regarding website response time report that users notice any delay over 0.2 seconds. Actions that are faster than 0.2 seconds appear instantaneous.  Scenarios with response times slower than that threshold can feel “slow” to users.

Tab creation is one such scenario. IE initializes add-ons every time the user creates a new tab to make sure that the add-ons can interact with a webpage properly (like the Skype IE add-on, which identifies phone numbers and makes them “clickable”). When the user starts a new instance of IE, one of the first things IE does is create a new tab that, in turn, initializes all the user’s add-ons. The time it takes each add-on to initialize is its load time, and usually depends on the amount of code the add-on executes during its initialization routine.

According to our telemetry data, over 95% of IE8 users today have at least one add-on installed, and users have an average of 9 add-ons installed. If a user’s add-ons each take more than 20 milliseconds to load, his new tabs will take a noticeably longer time to create than usual.

The following chart shows the median load times for the newest versions of the 50 most used add-ons in IE today. Users who have many of these add-ons installed will definitely notice a performance impact when starting IE or creating a new tab:

These are just the 50 most popular add-ons. Many add-ons that aren’t listed above may also have a performance impact on tab creation. We recommend users to install the newest versions of add-ons as they generally have the best performance.

End-users and Add-on Load Times

What’s important to an individual user is his or her own experience, not the broad ecosystem data. In IE8, we introduced a feature to enable users to see for themselves how their add-ons affect their browser performance.

IE measures the load time for each enabled add-on every time IE initializes it. In the Manage Add-ons dialog, IE displays the average load time for each add-on based on the last 10 initializations. You can access the Manage Add-ons dialog via the Tools Menu.

With this information handy, users can choose the add-ons they want to keep enabled, and maintain control over their browsing performance:

Add-on Developers and Add-on Load Times

We collected telemetry data on the load times across the add-ons that IE users have installed to evaluate their performance characteristics. The following chart shows the distribution of all add-on load times experienced by all IE8 users:

Even though most of the time add-ons load in less than 100 milliseconds, add-ons take longer than 200 milliseconds to load over 25% of the time. Users will perceive a noticeable impact on performance in these situations, more so if several of their add-ons have long load times. Measuring your add-on’s performance allows you to identify how often these long load times occur.

Let’s look at some specific examples of slower add-ons from our measurements, and some of the reasons these add-ons have such a large effect on IE’s performance during tab creation. If you are an add-on developer and would like to receive the following load time data for your add-on, you can email us at ieaddonp@microsoft.com.

Sample Add-on #1

Users with this add-on enabled typically see noticeable delays during tab creation. The majority of load times for this add-on are greater than 200 milliseconds. The amplitude of the curve is higher than that of the previous chart. Further investigation revealed that this add-on is generally running more code than is minimally required during initialization.

Sample Add-on #2

This add-on also incurs an impact on the user’s tab creation performance as evidenced by the majority of load times that take over 200 milliseconds. We found that the add-on is performing operations that take a consistent amount of time to complete across all machines (600-1500 milliseconds). We recommend moving these operations off of the initialization routine to expedite tab creation.

Sample Add-on #3

Even though the distribution of load times for this add-on is different from the others, it also incurs an impact on tab creation performance. We investigated the cause behind the uniform distribution of load times beyond 100 milliseconds and found that the add-on is making network calls during initialization. Since network calls take a variable time to complete depending on the connection speed and locale, add-ons must refrain from making network calls during initialization. We recommend spinning off background threads to make these calls at a later time instead.

It’s clear that some IE8 users experience significant performance problems with add-ons during tab creation. Add-on developers who improve add-on load time take an important step towards improving IE performance for end-users. At the same time, we know that add-on performance extends beyond tab creation. Let’s look at the other scenarios in more detail.

Recommendations to Add-on Developers around Performance

In this post, we focus on understanding and measuring scenarios in terms of the elapsed time with the add-on enabled. There are additional metrics that are also important, such as CPU time (amount of time the CPU spent to complete the scenario) and working set (amount of memory required to run the scenario). We’ll cover these two metrics in a future post.

Tab creation and webpage navigation are two of the most relevant scenarios for IE performance. Add-ons have a large impact on the performance of these scenarios because they can block IE from completing the user task. Depending on how the developer wrote the add-on, IE may have to wait for the add-ons to finish running code before IE can finish creating the tab or navigating to the web page.

We recommend add-on developers start by measuring add-on performance in these two scenarios:

1. Tab Creation, Switching, and Closing
Some add-ons call across the network during tab create (which causes users to wait), or choose to save their state (with registry reads and writes) as the user is closing a tab, or to repaint their UI as the user is switching between tabs.

Because add-ons can interrupt IE as it handles the user’s request to create a tab, switch between tabs, or close a tab, add-ons can make these operations far from instantaneous.

2. Webpage Navigation
As the user navigates to a webpage, Internet Explorer fires a set of browser events. Add-ons can choose to run code in response to these events. Add-ons that handle one or more of these events can delay users from finishing the web page navigation. The impact is profound on webpages that users expect to open immediately, such as search results or stock market tickers. Some examples:

• BeforeNavigate: A security add-on inspects the destination URL before allowing the navigation to proceed.
• DocumentComplete: Once a webpage finishes loading, an add-on searches through the entirety of every webpage to add a button next to all the email addresses in order to launch a custom mail application
• NavigateError: If an error occurs during webpage navigation, theadd-on redirects the user to a custom error page.

Given how important performance is for users, transparency and control of add-ons will also be important to them.

We also recommend that add-on developers measure and optimize their add-on performance using the publicly available Windows Performance Tools.

Specifics about Measuring Add-on Performance with Windows Performance Tools

We’ve recently blogged about how to measure browser performance with the Windows Performance Tools. Add-on developers can use these tools to measure various performance characteristics of the browser with their add-on(s) enabled. Here are the steps you can take to measure the tab creation and tab close scenarios for an add-on with the Windows Performance Tools installed.

1. Start an elevated command prompt and execute the following command to start a performance trace and log the results to a file (such as AddonTrace.etl):
   xperf -start browselog -on Microsoft-IEFRAME -f AddonTrace.etl
2. Make sure that your add-on is enabled.
3. Launch Internet Explorer to your home page. Wait several seconds after the navigation completes, and then open several new tabs.
4. Close each tab in order until the browser window shuts down.
5. Stop the trace by executing:
   xperf -stop browselog
6. Convert the contents of the .etl file into a text file that you can parse and measure for:
   xperf -i AddonTrace.etl -o AddonTrace.txt

Next, inspect the text file to find the following pairs of ETW events that correspond to the scenarios. To find the elapsed time for the event, subtract the timestamp of the end event from that of the start event:

In addition, you can use the Windows Performance Tools to measure add-on performance in the other scenarios we described earlier. Here are the ETW events that correspond to the other scenarios:

We recommend running these tests on a fixed environment against a set of the most popular websites to realistically measure performance. Caching these sites on a proxy server helps minimize variance in the website content. We also recommend running these tests across multiple machine configurations.

Add-on Performance: We’re all in, together

Performance is important to end-users: they’re paying attention and will take action to get better performance.

We encourage users to look at the performance impact of the various add-ons installed on their machines using the IE8 Manage Add-ons dialog. This information helps users stay in control of their browsing performance while using the add-ons they want.

We also encourage add-on developers to make those decisions easier for end-users by writing faster add-ons. We recommend developers start by measuring add-on performance using the Windows Performance Tools and follow the guidance we’ve included with this post. Set up a performance lab infrastructure with a server of cached websites and multiple machine configurations. While the IE8 add-on load time measurements serve as a gauge for end users, we recommend measuring performance across all the tabbed browsing and webpage navigation scenarios as well.

Using these measurements and our guidance above, you can tune your add-on for the best performance. As you find optimizations or best practices, we encourage you to share them with the developer community blog post comments here or on Connect.

Improving add-on performance is critical to building a fast and highly compelling browsing experience and we’re all in it together. We want IE users to enjoy great add-on functionality and great performance.

Herman Ng
Program Manager

Comments

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  I really think that IE9 or the next version should create a new kind of add-on safer, faster and easier to manage and to develop.

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  Since the FIRST BETA of IE8 was released users/developers/bloggers reported that IE8 tab opening was pathetically slow. MSFT retorted with blame the addon developers. We retorted with ok, fine, tell us which addons are the poor-performing ones so that we can DELETE them. MSFT replied with go to this out of the way panel to view incomplete and notoriously wrong load times. We replied indicating this doesn't help, even with all addons disabled or better yet uninstalled (we can't do it through the un-handy dialog because the UNINSTALL button was deliberately disabled) MSFT kept replying with IE8 new tabs open just fine. We replied indicating that this was completely inaccurate, that we could regularly reproduce that IE8 new tab load times were slower than ANY OTHER BROWSER by ORDERS OF MAGNITUDE!!! MSFT indicated that their addon model did have issues as it loads ALL addons for every new tab including blank tabs and the "new tab" tab that will NEVER need the functionality of 99% of IE addons. yet still claimed that the only way to improve load time was to run IE8 in no-addons mode. We replied that that was absolutely ridiculous as no user is going to run their browser without addons - key features that make the browser an essential tool. ============================ THAT WAS ALL OVER A YEAR AGO ============================ Thanks for finally posting a list of at least SOME of the poor performing addons. I'm glad you are telling addon developers A YEAR LATER to FIX their ADDONS (better late than never) but is MSFT going to fix the issues with new tab load times by STOPPING the initializing of addons UNTIL AFTER the new tab is OPEN, and the address bar has the FOCUS? Tyler S

• Anonymous
  August 03, 2010
  Tyler, I hope you understand that the very tone of your post leads most not to read it, to cluck and say "Yup, the trolls still abound over at the IEBlog." Had you bothered to read any of the posts that you claim to cite, you'd know that the IE add-on model requires initialization on startup, and changing that would be a breaking change. It's fine to propose that maybe it's time for such a breaking change, but to imply that this discussion hasn't already occurred on every single post on this topic for the last two years is a juvenile lie.

• Anonymous
  August 03, 2010
  I knew AVG and Norton were culprits. I don't use Norton anymore and I disable AVG Safe Search at work.

• Anonymous
  August 03, 2010
  After startup, could IE have an empty new tab initialized and ready to go to hide the delay? More radically: should IE9, IE10, and so on continue to use this extension model?  (Exclusively?)  Seems like if Microsoft got to define the extension API again, a lot could be done to protect performance: load some extensions after tab initialization or navigation or maybe even force most extension code to run asynchronously and out-of-process.  In other words, I second what Juliano Nunes just said. :) Worth noting that the newest browser extension APIs (Chrome's, Safari's) limit developers a lot compared to the older ones (Firefox's, IE's).  Folks could argue a lot about API design (and Chrome's/Safari's APIs are certainly neither perfect nor final), but their example does show that that sort of model won't scare developers away. MS could even offer a new add-on API alongside the current one, and provide incentives for developers to use the new API.  Maybe current-generation binary add-ons would have a sterner confirmation screen during installation, and IE would tell the user in an infobar if an extension was slowing down tab loads/navigations and offer to uninstall.

• Anonymous
  August 03, 2010
  You mean there are add-ons that are actually slower than the Java SSV Helper? I thought for sure that had to be the single biggest degrader of IE8's performance...

• Anonymous
  August 03, 2010
  I find it shameful that the top "add-ons" are toolbars that are often installed without permision, without intent, or as part of a larger program.

• Anonymous
  August 03, 2010
  So, IE9 should give extensions 100ms (or maybe 200ms) to load before they're liable for auto-disabling? Sounds fair.

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  I think nobody in the IETeam still ignores that a new add-on model is needed or, at least, I hope it. The main problem is that the IETeam need to make choices. Building a new add-on system may be delayed until a later version, but I would like to hear from Microsoft something like "We're considering that for a later version, but be sure it's coming!" than the current "There's already an add-on system we could improve" which doesn't indicate they have got the main issue in their add-on system : It's unintuitive to build one, and it must be done in a programming language (C++) that many web developpers are not masterizing.

• Anonymous
  August 03, 2010
  @tyler I don't know how you got such times,but I know that debate is not over as reported times are not reproducible without bad addons. At worst I see times around 300ms and only if I switch from non-empty tab. From empty to empty it is about 100ms. The only unknown times are for Atom based netbooks. So if such reports are to be taken seriously you need to say what are specs of PCs,what is installed SW(often big difference) and addons and what is the measured scneario. (empty tab to empty tab/full tab to empty tab/...) BTW´,there was ticket at Connect where was published by reporter basic measurment tool and I put there my own numbers (incl. spec of PC I used)

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  I don't use any addons, and IE8 is still slower than Firefox (which does have addons installed). Stop making excuses Microsoft!

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  I was very pleased to find this site.I wanted to thank you for this great read!! I definitely enjoying every little bit of it and I have you bookmarked to check out new stuff you post. <a href="www.ozrot.co.il/">%D7%A2%D7%95%D7%96%D7%A8%D7%AA בית</a>.  

• Anonymous
  August 03, 2010
  @ieblog Please fix the blog software, too. You have to send comments twice.

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  'We encourage users to look at the performance impact of the various add-ons installed on their machines using the IE8 Manage Add-ons dialog.' What planet are you on? What percentage of ordinary users do this? An almost unmeasurable fraction I would guess. What proportion of professional developers do this? An almost unmeasurable fraction I would guess. Just don't make it block whole starting a tab. Not to do otherwise is just plain stupid. When I open a tab to go to a standard web page I just want it to start straight away. Not wait to load add-ins I don't want or care about, and probably don't even know are there. Fix the problem. The mere fact you have to write a blog article about it and provide all these tools shows your underlying implementation is broken.

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 03, 2010
  The comment has been removed

• Anonymous
  August 04, 2010
  To respond in place of the IETeam : The add-ons are loaded per-tab for many reasons. The primary one is that the add-on system was made at at time (IE5) where no tab were existing, and an add-on has only one "window" to handle. The second reason (why they didn't change this after IE7) is that the tabs now runs in different processes to allow a tab to crash and the browser to be kept alive. So, you should instanciate the add-on every time you get a new process, and there's a process per tab (or almost). This is why we need another type of add-on API, that would require no initialisation (or at least an initialization entirely controlled by the IE application). The old system could be kept alive for compatibility or complexer add-ons that requires a in-depht access to the IE events.

• Anonymous
  August 04, 2010
  @EricLaw : Sorry for the double posting. Your post was not visible when I started writing mine (I used hibernation and posted if after, I didn't check for new messages before).

• Anonymous
  August 04, 2010
  No problem; additional details are always nice. :-)

• Anonymous
  August 04, 2010
  @EricLaw[MSFT] - you missed the most important, and totally obvious option (4) 4.) When opening a new blank tab. e.g. "about:blank" or "about:tabs" do not instanciate ANY ADDONS whatsoever until the page has fully rendered and the location bar is ready for keyboard entry.  Then, spawn a thread that instanciates any addons. Point blank simplicity.  This is the 95% scenario - user opens a new blank tab... they don't need mouse gestures, they don't need adblockers, they don't need skype phone # link replacing or any of that garbage. Its so painfully obvious that the fact that it hasn't been addressed indicates a lack of interest in fixing the problem and continuing to blame addon developers for a flawed addon implementation model. MSFT can't ask addon developers to fix their code if they don't first indicate that they are planning to fix the code on their end too! Oh, and this blogging commenting software is HORRIBLE!!!! plz fix it!!!!

• Anonymous
  August 04, 2010
  @Walter: You've simply restated proposal #3, and hence your proposal is subject to exactly the same limitations I've described previously.

• Anonymous
  August 04, 2010
  is the load time completely CPU bound?  If not, can you tell if there are any network timeouts included in the load time (e.g. TrollBar attempts to contact TrollBar.com on load)

• Anonymous
  August 04, 2010
  Why does Microsoft not create a few sample addons heaviliy loaded with comments that programmers can use as a basis for creating their own addon.

• Anonymous
  August 04, 2010
  The comment has been removed

• Anonymous
  August 04, 2010
  @EricLaw I think you mis-read @Walter's comment - His suggestion was only to modify the behavior for 2 URL's that users will encounter most of the time (thus provide maximum benefit to end users and cause no issues for addon developers) in pseudo code: openNewTab(url){  if(!url){    url = getDefaultNewTabURLFromRegistry();  }  if(url.toLowerCase() == "about:blank" || url.toLowerCase() == "about:tabs"){    queueInitAddonsAfterLoad();  } else {    initAddons();  }  loadURL(); } This does not therefore have issues with your #3 option. The above code is obviously over simplified but there you have it - a 5min code fix that would make MILLIONS of IE8 users happier about their IE experience each and every day (several times a day no less!) That said - if you are not willing to put in a quick fix like this - that's fine too.  Indicate here on the IEBlog how you intend to fix the IE addon model so that IE doesn't suffer from laaaaaaaaag during new tab loading.  Preferably indicate that it will be in IE9, but if not - tell addon developers that it is changing in IE10 so that they can prepare (code and time) to adjust their addons to suit the new model. Telling addon developers to try to optimize their code - without addressing the underlying issue is a no-win situation and does not impress the development community - nor give them faith that you are working on the core eco-system to improve it.

• Anonymous
  August 04, 2010
  @Amir: On the contrary, exactly the same issues exist-- namely, addons that the user may want to have available (e.g. those related to navigation) will not be present. For instance, I have mouse-gestures hooked up that take me to my favorite pages, and these gestures would no longer work in the proposed system. (I'm fully willing to admit that users with navigation add-ons are likely in the minority, but to imply that no one will have a problem with the change is a mistake). And again, when the user does navigate the window, the performance penalty is paid and the UI will be reorganized as toolbars, etc, are moved into place. I don't think you have any data that backs up your assertion that this scenario is the one that users hit "most of the time", and I can assure you that this proposal isn't "a 5min code fix." Lest you confuse anyone, let me be perfectly clear: The "underlying issue" here is poorly performing add-on code. I use a handful of chosen add-ons with IE8 on machines that are several years old, and my new tabs still appear and are ready in under 200ms.

• Anonymous
  August 04, 2010
  I agree with EricLaw here. Add-ons are not only made of BHO (Browser Object Helper), they also can show toolbars. In such case, having to redraw the entire browser window quicly after the new tab load could be worse than the time we wanted to save before. (I said could, I don't have any data about that). Then, you could say "Load only the toolbars, not the BHOs". But a toolbar may rely on a BHO to init and so causing a bug. We can't solve the problem with the old system, it's simply not possible. They can help add-on builder to make their add-on better and build a new system and promote it, but changing completetly the current system is not a good deal.

• Anonymous
  August 04, 2010
  I run XP on various machines, with various ammounts of addons from zero to 10.  All experience 1,000ms or greater load times for a new BLANK tab on a regular - but un-repeatable basis. On the same XP machines Chrome and Firefox (both with 5-15 addons) load new tabs in less than the blink of an eye and they are ready to interact with. You can blame bad addons all you want - but I KNOW that IE8's new tab opening is SLOWER than ANY OTHER browser (addons enabled or not) suggesting otherwise is like trying to tell kids not to like McDonalds - you are wasting your time.

• Anonymous
  August 04, 2010
  And what are your proxy settings? And what AV/anti-malware software is installed?

• Anonymous
  August 04, 2010
  @tab speed Lucklily experienced IE8 users know that IE8 tab can easily open in les than 200 ms. I have speeded up quite a few IE8 users by reconfiguring their addons setup and replacing their security software (replacing it with MSE) several of them claiming they were not even using add-ons.

• Anonymous
  August 04, 2010
  Addon performance will not improve by itself. The IE team has to take charge of what addons are running at all and penalizing them.

• Anonymous
  August 04, 2010
  @And - I've seen this on all kinds of setups... running AVG, Kaspersky, Norton, Mcafee, or NONE at all. (ditto for anti-spyware) but in most cases none. (for the record in any of the AVG tests the link checker was obviously turned off (I won't go into details of how much of a waste of resources that "feature" is). @hAl - I consider myself an "experienced" user - running computers since my Vic 20.  Even on a fresh install of XP, with NO addons, NO antivirus, NO anti-spyware... IE8 will still occasionally load new tabs in the second-plus time frame. (note that this is with MS Office installed, but with that !@#$ing waste of time "MS Research" extension uninstalled - proven to be one of the worst offenders for IE8 new tab load time) As noted - I have no interest in debating whether this happens or not - nor does everyone else experiencing it - we just want MSFT to FIX the addon model so that opening a 100% completely blank tab does not take more than a fraction of a second.  Anything more than a fraction of a second is simply not acceptable... no matter how many addons you have installed. OK - and what is the deal with this blog commenting system? - How is it that the Blog used by the makers of the worlds most used browser doesn't actually work properly? - Every attempt to comment fails the first time (with no error message!) and you have to scroll down and re-submit?!?!? Please fix the blog!

• Anonymous
  August 05, 2010
  The "MS Research" add-on is an Explorer bar. It doesn't actually do anything unless you make it visible while loading. (Having said that, I agree that it's a pretty worthless add-on and that's one reason it was removed in later versions of Office).

• Anonymous
  August 05, 2010
  We are taking a look at the commenting issues you are seeing with the IE Blog. Hang tight while we do some investigations here.

• Anonymous
  August 05, 2010
  Eric, has the IE team done any analysis of IE tab performance when it's run with Windows Defender or Windows Security Essentials?  Either of these is in many IE installations, and since they are MS products, you have a good opportunity for analysis. I say this because I have been fighting slow tab opens for quite some time and I've been digging deep into Windows internals to find a cause.  I haven't found a good theory for this that hasn't been hashed over already. I have slow performance with just a few tabs, and I have slow performance with many tabs.  Sometimes, IE will become non-responsive for several minutes. This has even carried over into my "new" system--this Windows 7 Ultimate installation was transferred from my dead motherboard to a newer, faster  motherboard with a quad-core CPU.  IE is still slow. :) I have few plugins;  the only one enabled is the MS Antimalware Script Scanner which shows 0.01s load. I'm looking forward to trying the xperf tracing, which I have used for general performance diagnostics.  There's a blog post in it for me if I can just find out what's going on...

• Anonymous
  August 05, 2010
  @dmoisan: Thanks, we'll take a look at any add-ons that Windows Defender and Windows Security Essentials provide and work with those teams as needed.

• Anonymous
  August 06, 2010
  @IE Team: Please make it so that add-ons are more useful even without toolbars. I use both IE and Firefox, and I always avoid toolbars -- they take up vertical space, and they slow down the experience.

• Can you please add a Quick Access Toolbar (QAT) at the top (but don't use the Ribbon!!! You know it's now a fit). Quick Access Toolbar is dedicated to all Toolbar Button Addons.
• Please make the Toolbar Button Addons in this QAT behave like the Windows 7 Notification Tray icons. Single-clicking opens a window, right-clicking gives more options. I saw a lot of Firefox addons that have been useful but they have inconsistent UI.
• Can you standardize the UI for toggling toolbars easily? For example, a Web Developer toolbar is great if it has a toggle button on the toolbar.
• And lastly -- can you at least allow programming addons using JavaScript just like Firefox? And add special security restrictions to JavaScript-based addons to avoid security issues.

• Anonymous
  August 09, 2010
  We've updated the post button on comments to indicate it's publishing the comment. The button is also disabled while that's happening to help with the confusion...

• Anonymous
  August 10, 2010
  @dmoisan: I've never used any other Browser than IE, even though IE7/8 used much time while creating new tabs. I think that the internal JavaScript engine is the cause as slow loading times of new tabs with no AddOns occured more often when I had Tabs with heavy JavaScripts. This is only an Idea and may be completely wrong... Well, I hope I'm right as the JS-issues should be gone in IE9+.

• Anonymous
  August 10, 2010
  The comment has been removed