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:

50 Most Popular Add-ons in IE8

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:

Manage Add-ons Dialog showing performance information

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:

Distribution of all Add-on Load Times

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 #1 distribution of load times

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 #2 distribution of load times

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.

Sample Add-on #3 distribution of load times

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, the add-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:

Scenario

Start Event

End event

Tab Creation

(Load time)

CoCreateInstance():

Microsoft-IEFRAME/ExtensionCreate/Start

SetSite():

Microsoft-IEFRAME/ExtensionSetSite/Start

CoCreateInstance():

Microsoft-IEFRAME/ExtensionCreate/Stop

SetSite():

Microsoft-IEFRAME/ExtensionSetSite/Stop

Tab Close

SetSite(NULL):

Microsoft-IEFRAME/ExtensionSetSiteNull/Start

SetSite(NULL):

Microsoft-IEFRAME/ExtensionSetSiteNull/Stop

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:

Scenario

Start Event

End event

Tab Switch

Microsoft-IEFRAME/ LeftButtonAction/win:Info

The following sequence of events:

Microsoft-IEFRAME/Browseui_Tabs_SwitchTabs/win:Stop;

Microsoft-IE/MSHTML_CDOC_ONPAINT/win:Stop;

Microsoft-IEFrame/Browseui_Tabs_WaitMessage/win:Start

Webpage Navigation

Microsoft-IEFRAME/FRAME_URLENTERED/win:Info

The following sequence of events:

Microsoft-IE/MSHTML_CMARKUP_ONLOADSTATUSDONE/win:Info

Microsoft-IE/MSHTML_CDOC_ONPAINT/win:Stop

Microsoft-IEFrame/Browseui_Tabs_WaitMessage/win:Start

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 (48)

  1. jabcreations says:

    IE8 opens tabs really slowly…I'd say a full second is painfully slow.

    Will IE9 have a customizable GUI or will we be stuck with woke-up-in-a-cold-sweat-and-went-straight-to-destroying-IE's-design layout?

    Also don't hide the file menu by default!

    "Okay sir, please click on the tools menu."

    "I don't see the tools menu."

    "What do you see?"

    "Nothing."

    "Just press any key."

    "I see Esk, Catarl, and Pig Up. There doesn't seem to be any 'any' key!"

    In all seriousness the GUI is the #1 reason for slowing power users down and the second for regular users. The #1 reason for regular folks is because of all the junk on their computers, the usage of page files, lack of RAM, and SuperFetch combined.

    You guys have mentioned you do user tests right? You want the browser to be user friendly right? Then why is Microsoft hiding all the text-labels on everything? When the average user sees a button that is not labeled they don't push it because in their mind they could screw up their computer and lose a day's worth of work. 99% of the time wasted in IE is by users trying to figure out how to achieve a goal when interacting with the GUI and it's the same thing with Firefox's default GUI with no text labels, no bookmarks, downloads, history, new tab, or print buttons visible. Stick to friendly icons with text labels, don't hide the file menu, keep the file menu at the top because consistency sort of kind of counts (think going to work and having to remember which side of the road to drive on), and for goodness sakes let us drag ALL the toolbars BOTH horizontally and vertically around. Also don't "stuck" buttons together like stop/refresh and the back/forward buttons.

    If you guys want to one-up both Firefox and Opera allow the ability to have icons off, on top, or on the side of text labels as screen real estate varies and some people's screens are vertically longer and may desire their GUI to adopt. Really the inflexibility of software these days is because developers don't test things out like power users would.

    Lastly please PLEASE realize this is 2010, not 1998, most people have resolutions and we don't need thousand pixel long address bars. In example in Firefox I have the bookmarks toolbar folder to the right of the address bar and because I don't NEED text labels use only the favicons for bookmarks; the two toolbars take up roughly 50% of the width each. If Firefox had a text label on side option I could reduce the vertical height by about 25px. Owning a 24 inch screen and a netbook with a 1024×600 screen also helps when you're trying to make effective use…can you merge most of everything on to two vertical toolbars on the netbook merging even with the file menu? Do the toolbars horizontally adopt so two toolbar sets can co-exist on the same horizontal toolbar such as IE's address bar and the favorite links toolbar?

    …and if you want to top it all off introduce profiles with the ability to guest mode in with a single profile that contains favorites, toolbar settings, last opened tab settings, etc so you can migrate from one PC to another with minimal interruption.

  2. Really...again? says:

    >IE8 opens tabs really slowly…

    >I'd say a full second is painfully slow.

    A full-second *is* painfully slow. But someone willing to type his entire "I want a pony" christmas list in this tiny little box should be willing to spend the 30 seconds it takes to turn off his junk addons to make IE open new tabs instantly.

  3. Juliano Nunes says:

    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.

  4. Dave says:

    Thank you, thank you, thank you for naming names! So often in the past, Microsoft has complained about add-ons in a general way without trying to identify specific troublemakers and get them to fix code. This blog entry is a refreshing change in strategy. Please continue that approach. I would like to get names and distributions from some real add-ons, and see who is in those four- and five-second tails.

    P.S. Please head over to the Windows Live Toolbar group and tell them to set a better example.

  5. tyler says:

    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

  6. TimeOutForTyler says:

    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.

  7. David says:

    I knew AVG and Norton were culprits. I don't use Norton anymore and I disable AVG Safe Search at work.

  8. Randall says:

    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.

  9. Jawed says:

    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…

  10. FieryKitsune says:

    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.

  11. davis says:

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

  12. tyler says:

    @TimeOut… yes my tone was determined and pointed – that was the intent!

    The point was simple – we've had this debate for over a year and except for the msfanboys, we all know that IE tabs are slow, we all know why they are slow, we just wish that MSFT would have stepped up to the TRANSPARENCY plate a year ago, admitted that IE had a problem rather than put the blame purely on anonymous addon developers, trying to deflect the criticism.

    Since IE9 is still in development, MSFT *still* has a chance to FIX this issue.  As @davis suggests, maybe IE needs to be more proactive about what addons it allows to run?

    In addition, MSFT needs to publish the top 25 offenders for load time (even if they are not ranked, nor actual times identified!) so that the addon developers that need to work on their addons at least know they have issues.  At the same time, users can disable addons in this list until they are rectified.

    I have read all the posts on the IE blog so please don't tell me I should have "bothered" to read them.  The "*requires* initialization on startup" – good point! when developers find bugs in another API or how it is implemented they should be **encouraged** to speak up and explain the issue so that it can be fixed and everyone can benefit.  Its obviously a very poor instantiation model that may have been okay when IE6 didn't have tabs, but when they were hacked into IE in order for IE7 to be an acceptable browser there was a penalty paid… the piper has been calling since IE7/IE8 and its time to pay up!

    As for me "implying" that said conversations have not occurred for the past 2 years – I'm not sure where you extracted that idea.  That said I'm sure that several commenters have suggested that MSFT fix their addon model, several times no less! – What would be refreshing is MSFT openly discussing the idea of changing it for the better so that developers can help shape the final solution, and then code to it.

    I'm sure that addon developers would love their addons to run in a high performance browser – help them get there.  Otherwise Chrome and Firefox will continue to be the preferred browsers for end users because they are so fast and full of useful, speedy addons.

    As for the final comment… I never lied about anything in my comment above (juvenile or otherwise) – if you would like sources for anything just ask – most of it can be found by Googling the IE Blog itself.

  13. FremyCompany says:

    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.

  14. Klimax says:

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

  15. hAl says:

    A lot of junk add-ons trying to influence peoples in their surfing (like toolbars) and also a lot of irritating security add-ons.

    I would have thought the IE7pro addon would have been more popular (at least reaching the top 50).  

  16. Andrew says:

    I don't use any addons, and IE8 is still slower than Firefox (which does have addons installed).

    Stop making excuses Microsoft!

  17. Dominik says:

    @ieblog

    Stop blaming the Add-on developers. Even Microsoft releases crappy Add-ons.

    The real problem is this: "IE initializes add-ons every time the user creates a new tab". That's a waste of time, isn't it? What are the technical reasons for this? You have to live with users complaining about tab-performance or fix the problem on your side.

  18. ozrot says:

    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="http://www.ozrot.co.il/">%D7%A2%D7%95%D7%96%D7%A8%D7%AA ื‘ื™ืช</a>.  

  19. Dominik says:

    @ieblog

    Please fix the blog software, too. You have to send comments twice.

  20. @Dominik says:

    OK, say IE doesn't initialize add-ons when the user creates a new tab. Then, the add-ons aren't there to interact with the page. No initialize skype, then skype no can make phone number have clicky things on them.

    Crazy idea — what if when IE tells the add-on that there's a new tab, the add-on actually responds quickly?

  21. Matt Phillips says:

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

  22. Saitir says:

    While there are undoubtedly issues involved, what about the classic old goto for UI performance and spool add-on initialisation into a different thread?  Certainly for cases when its a blank tab, more problematic when you're creating a clone tab – but even then, you need only wait for add-ons actually in use on the original tab to be initialised and not all of them.

    It strikes me that some simple problem solving of the initialisation process could iron out at least 80% of the issues.

    However, I do find that the usual culprit for slow tab opening (in my own eco-system at least) is the java app helper add-on.  Remove that and 90% of the delay goes away.  Most of the rest seems to be flash player.  Of course if you're the kind of person who has it installed at all, disabling it is not likely to be useful.  However, I can't quite see the justification of most of these add-ons being initialised until they're actually needed.  

    The java add-on for example, how many web sites still use java applets?  Typically I see them on university teaching pages, and simple simulation type things.  Rarely anything on the general web.

  23. EricLaw [MSFT] says:

    > IE initializes add-ons every time the user creates a new tab.

    > What are the technical reasons for this

    The technical reasons for this are that this is how the add-on model works. IE loads each specified COM object and calls the SetSite method of the IObjectWithSite interface to allow the add-on to "connect" to the IE instance.

    Now, there are a few obvious "fixes", each with some downsides:

    1> Disable the loading of add-ons. Yup, this works (and there are several easy ways to do this) but it's not a popular option due to the loss of functionality.

    2> Change the loading of add-ons so that they only load once per window rather than once per-tab. This would be extremely difficult to accomplish because it would break backward compatibility of most add-ons, requiring each be  rewritten. Even then, it would be challenging to make this work because the LCIE process-isolation architecture means that the interfaces between the extension and the tab processes would likely need to be completely redesigned, making rewrite of add-ons more challenging.

    3> Change the loading of add-ons so that they only load after new tabs have completely finished being creation and loading of content. A simple implementation of this works but has the following downsides: a> The extensions aren't available for immediate use (e.g. I love the Mouse Gestures add-on, and for me, a tab isn't useful until that is loaded. Similarly, an ad-blocker addon won't function until loaded). b> It can result in a jarring user-experience, because if the add-on makes UI changes like adding a toolbar, that will happen at a later, likely more visible time, shifting the page around. c> This only delays the performance impact, it doesn't eliminate it. If add-ons are slow to load, then that penalty is still paid. While it's tempting to think these can load "in the background", many extensions manipulate the UI, so this price is paid on the UI thread unless the extension is properly developed to use multiple threads.

    Ultimately, the best way to build high-performance add-ons is to follow the best practices above, and test, test, test. From the end-user perspective, install only the add-ons you want or need, and remove those that slow down your browser. Keep add-ons up to date, and let makers of add-ons know when you're uninstalling them due to performance or reliability problems.

    From our side, we're working with major add-on vendors (including other teams) to help ensure that they're measuring and improving their performance, and exploring some interesting ideas to help ensure that users will have a great, high-performance experience with IE9. We don't want our hard work on performance to be ruined by poorly-coded add-ons!

    -Eric

  24. EricLaw [MSFT] says:

    @Saitir: Flash isn't loaded or initialized until you actually visit a page that uses Flash. The Java versioning add-on is used to speed the loading of pages that use Java and ensure that pages cannot perform an "engine downgrade attack". If you don't visit pages that use Java, you might consider removing or disabling Java altogether.

    For folks who think slow add-ons only impact IE, I encourage you to check out this article: blog.mozilla.com/…/improve-extension-startup-performance

  25. FremyCompany says:

    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.

  26. FremyCompany says:

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

  27. EricLaw [MSFT] says:

    No problem; additional details are always nice. ๐Ÿ™‚

  28. Walter says:

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

  29. EricLaw [MSFT] says:

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

  30. elBarto says:

    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)

  31. hAl says:

    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.

  32. Randall says:

    @EricLaw: I'm guessing your post means, more or less, that there won't be a "new IE extension model" alongside the old for version 9, either in the sense of a tweaked API for .dlls or a heavily sandboxed alternative like what Chrome or Safari have?  

    (Before someone says it, I know you can make extensions slow down the browser in any model, including Chrome's — I'm just curious if Microsoft has any interest in changing the model to mitigate the problem.)

    I like the sound of "exploring some interesting ideas to help ensure that users will have a great, high-performance experience with IE9," anyway.

  33. Amir says:

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

  34. EricLaw [MSFT] says:

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

  35. FremyCompany says:

    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.

  36. tab speed says:

    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.

  37. And says:

    And what are your proxy settings? And what AV/anti-malware software is installed?

  38. hAl says:

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

  39. tobi says:

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

  40. tab speed says:

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

  41. EricLaw [MSFT] says:

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

  42. SeanJenkin says:

    We are taking a look at the commenting issues you are seeing with the IE Blog. Hang tight while we do some investigations here.

  43. dmoisan says:

    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…

  44. Herman [MSFT] says:

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

  45. thenonhacker says:

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

  46. SeanJenkin says:

    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…

  47. Jones111 says:

    @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+.

  48. Jones111 says:

    @EricLaw [MSFT]:

    – Yes, it's true that dumping the current AddOn model would cause many problems. So if you develop a new one, and I think you should at least for IE9 Sp1 or IE10, you can't just drop your old api.

    – There are many things that should be done right in a new AddOn model, so I'll just list some ideas I have:

    1) Don't wait for AddOns:

       Design your API to continue loading of a page at maximum speed while the installed AddOns are catching up.

       – If ToolBars are installed, save their height and width and display a grey loading sign (in the size of the ToolBar at its last location) while the surface initializes.

       – Mouse gestures or Touches normally don't have anything to do with the page that's displayed. So don't wait for them.

       – Menu Items in the right click menu could be inserted later (a user won't right click on a page he/she doesn't see)

       – If an AddOn changes the displayed HTML, use the DOM-JavaScript functions to rebuild a single part instead of the whole page.

       – If an AddOn wants to work with displayed texts (like Skype), the browser should not wait. Any loaded item could have a HashId when it is loaded and could be sent to AddOns via an Event. If that AddOn chooses to do something with it, it should send the Data back with the HashId when it is finished.

    2) Inform the users about slow AddOns:

      – If you're seriously trying to help users, you could ask them if they'd like to disable AddOns that occasionly take more than 500ms to finish loading (like 'The AddOn 'XYZ' slows down your browsing experience, would you like to disable it? {YES,NO} {0 DON'T SHOW AGAIN FOR 'XYZ'}').

      – Make it eaysier to enable and disable AddOns (new AddOn dropdown-menu to enable and disable AddOns via two clicks)

      -> Remember settings for AddOns: If a user decides that he/she needs an AddOn on a few specific or all but a few specific pages, the browser should remember that setting (this could help with AddOns that are considered a bit unsecure like Flash that could be only enabled on YouTube).

    3) Have example and empty AddOns for common languages (at least C,C++,C# and VB) that can be imported in Visual Studio as Projects.

    4) Build an update system and a publishing service for AddOns so that they don't have to be updated manually.

Skip to main content