Improving Add-on Performance

88 responses

Firefox performance is extremely important to our users, especially how quickly it starts up and loads websites. Customization is also extremely important, and while most add-ons cause only a tiny performance impact, others can significantly slow down Firefox. Many users don’t realize add-ons can cause these delays, and that’s why we’re committed to improving performance in a big way.

How slow are we talking about?

On average, each add-on you install adds about 10% to Firefox start-up time. For some users that’s mere milliseconds, and for others it may be half a second; it all depends on the hardware and software of each individual. Many add-ons add less than 10%, and unfortunately, there are quite a few add-ons that add more. But based on our real-world performance data, installing 10 add-ons will double Firefox’s start-up time.

What is Mozilla doing about it?

We’re excited to announce a number of initiatives we’re working on to reduce the performance impact of add-ons through developer tools, documention, and user education.

  • Automated performance testing — Every week, we perform automated performance tests of the top 100 add-ons hosted in our gallery and display the results. Soon, we will automatically scan new versions of all add-ons as they are submitted. In the coming months, we will expand this to include other measures, such as page load time.
  • Slow performance warnings — In the next two weeks, we’ll begin displaying warnings in our gallery for any add-on that slows Firefox start-up time by 25% or more. We think users deserve to know when an add-on will impact them and want them to make an informed decision to install the add-on. In an upcoming version of Firefox, these warnings will be displayed in the Add-ons Manager as well.
  • Performance documentation and outreach — We’ve updated our Performance Best Practices and have begun reaching out to developers of slow add-ons and asking them to work on performance. This isn’t limited to add-ons hosted in our gallery; it includes all slow add-ons we can find.
  • On-demand performance testing — In the coming months, we’ll provide tools for developers to upload an add-on and receive a performance report to test the effectiveness of their fixes on the same machines that officially rate their performance.
  • Required opt-in for installation — It’s an all-too-common practice of third-party software to install toolbars and other bundled add-ons in your browser without permission. We know that these add-ons account for many of the performance problems reported to us, and users often don’t know how the add-on got there or how to remove it. In an upcoming version of Firefox, third party add-ons will not be installed unless the user explicitly allows the installation in Firefox. We expect this to have a huge impact on Firefox performance, as well as giving users back the control they should have over their add-ons.

What should add-on developers do?

  1. Test in all the possible configurations a user might encounter.
  2. Learn the Performance Best Practices and use them when developing your add-ons.
  3. Optimize your add-ons, aiming for 5% start-up impact or less.

If you need help or have questions, ask us. We’ll soon be providing additional documentation, tools, and advice on improving performance.

What can Firefox users do?

The best way to combat slow add-ons is to disable add-ons you no longer use. Disabling an add-on will prevent it from loading and slowing down Firefox, yet keeps it in your Add-ons Manager so that you can re-enable it anytime you’d like.

Firefox users shouldn’t have to choose between customization and performance, and with the help of add-on developers and the Mozilla community, they can have both.

88 responses

  1. Wladimir Palant wrote on :

    Glad to see that Adblock Plus didn’t make the list of top 50 slow add-ons 🙂
    Unfortunately, that’s most likely only because you were testing Adblock Plus without any filters. Even with all the caching done in the current Adblock Plus version, loading up EasyList with its 11 thousand filters is taking its time. Most of that time is taken up by Gecko’s parsing of the CSS file generated by Adblock Plus (200ms on my laptop in Minefield, it’s more than 700kB). So, will an extension that requires user action on first run always score better or do you intend to do something about it? Is it realistic to deduce real-world impact of individual extensions from the ping data you are getting?

    1. Justin Scott (fligtar) wrote on :

      Yes, we definitely realize that some add-ons don’t have start-up impact until after you’re logged into an account, add filters, open a sidebar, etc. That’s where the real-world data comes in: we can look at add-ons that are correlated with slow start-ups and investigate further, and even set those prefs as part of our automated testing to automatically add filters and otherwise trigger what users actually experience. As we ramp up our performance initiatives we’ll be doing a lot more of that.

      1. Tom wrote on :

        I understand the benefits of publicly shaming the add-on developers, though I would probably argue that saying the purpose is to inform the user base is a bit disingenuous. I think that the larger intent is to spur addon developers to improve the performance of their startup time. This makes sense, since poorly-performing addons can negatively impact the overall experience of Firefox itself.

        I think this will definitely aid in that goal, and I agree that improving performance should be a high priority. I would just prefer a little more collaboration with addon developers (and it sounds like the on-demand performance testing is a great step).

        From an addon-developer perspective, when we were given the chance to help Mozilla by providing real-world performance metric (which I voluntarily did not opt-out of for this reason), I bet many did not realize at the time that we were volunteering ourselves to “out” our addons for poor performance.

        But we’ll get over it. And we’ll improve our addons. And Firefox will bet better for it. All of which is good. I guess it could have just been handled with a bit more grace.

    2. Ed wrote on :

      Wladimir, I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=647561 for covering adding ABP prefs to the config used for the Talos testing.

      On a related note: Does anyone else know if any of the other top100 addons similarly need prefs setting so that the config being tested is representative of real world usage?

    3. vinny86 wrote on :

      Wladimir !!! ABP is 12th 🙁

      1. Wladimir Palant wrote on :

        Yes, now it is. It wasn’t on the list when I posted this comment.

        1. Alex wrote on :

          Still best add-on available, MOST useful, as it speeds up browsing a lot. Compared to my company browser, without Adblock, it is like a different universe, without all that flashy ads.

          BTW, i do not care about start-up time, even on my very old IBM T41 Laptop it is still absolutely acceptable. Getting a WLAN connection is taking much longer 😉

  2. KWierso wrote on :

    “In an upcoming version of Firefox, third party add-ons will not be installed unless the user explicitly allows the installation in Firefox.”

    \o/

  3. mucinch wrote on :

    Thank you!!! Thank you!!! Thank you!!! But please give the developers ample time to rectify the problems before publishing the data publicly. They are an important part of the community and there is no need to embarrass them. Besides users may start spamming their mail accounts for a faster fix which might only end up irritating them. Thanks again.

    1. Justin Scott (fligtar) wrote on :

      Our primary concern with launching this initiative is the hundreds of millions of Firefox users who deserve to know when installing an add-on will slow down Firefox. While developers may see it as us embarrassing them, we see it as giving users the information we’d want to have before installing an add-on. However, we are giving developers several weeks before turning on these warnings so that any that do want to avoid these warnings entirely can make improvements.

  4. Tom wrote on :

    I look forward to the On-demand Performance Testing. I think that will be a big help to addon developers to help streamline their addons.

    Though I might have liked to see that made available to the addon developers a bit before Mozilla went to the Public Shaming Strategy 🙂

  5. Jivko wrote on :

    As a theme developer I want to know if themes can slow down the performance.One more thing-why did the folks from Mozilla remove the themes from the most popular add-ons list? https://addons.mozilla.org/en-US/firefox/extensions/?sort=popular&page=1 Themes were in this list before but now there are no themes in it.Themes are add-ons as well you know.I think they should be in the list too. 🙂

    1. Wladimir Palant wrote on :

      Themes should have little to no impact on startup performance. However, efficient CSS rules (https://developer.mozilla.org/en/CSS/Writing_Efficient_CSS) apply to themes as well – in a worst case scenario a theme could make the browser window unusably slow with inefficient CSS rules only.

  6. Mook wrote on :

    Yay! That should help figuring out the impact (since running Ts is decidedly non-trivial locally).

    I don’t suppose there’s ever going to be a chance one of the bullet points will turn into “devote resources to write new APIs Firefox doesn’t need but will let the extensions do things faster”? In particular, I’m thinking about things like the DOM mutation events that are apparently to slow to actually use… A good alternative that actually worked would be awesome.

  7. Jigar Shah wrote on :

    I agree, I think first they should provide developer tools like on demand testing and give some time. Cos even developer has some ego. And we shd not forget large users base for firefox has a lot to do with addons ecosystem.

  8. asymmetric wrote on :

    thanks!! this is definitely a welcome effort!

    but would it be possible to add other metrics to the analysis, like overall responsiveness, or “new tab” opening time?

    because i feel that some addons sometimes negatively impact the overall performance of firefox, not just start-up times.

    thanks!
    asy

  9. johnjbarton wrote on :

    Firebug has 4000+ bug reports and 20,000+ newsgroup postings: without any doubt our user community is active in reporting issues. How many of those users complain about start up time?

    Zero.

    How much time to I plan to invest in improving Firebug startup time?

    Zero.

    Focus on things users care about. Start with memory footprint, a problem we have lots and lots of complaints about and zero platform support to fix it.

    1. Ian Nartowicz wrote on :

      Startup time is a constant gripe from real users. Maybe they aren’t raising bugs about it and maybe they aren’t geek enough to be hitting the newsgroups but in everyday forums it is an issue and one where people constantly compare Firefox to Chrome unfavourably. So much so that it has become more fashionable than actual fact, but an issue nonetheless.

      Maybe less of an issue with the new release? Let’s hope so and let’s hope that improving addons will get rid of it as a major gripe. FF4 on a clean profile is fast enough now that anyone complaining about startup time (excluding now fairly rare bugs) is almost certainly having an addon problem.

      I’ve already made a couple of tweaks based on this article and look forward to the new tools.

      1. Tim McCormack wrote on :

        It is quite rare for me to restart Firefox — and the only time I do is when it starts using too much memory. Now, maybe I’m just a power user, and most of your userbase doesn’t have 30 extensions and 60 tabs, but power users are a big part of your marketing base.

    2. FFAR wrote on :

      quote: “How much time to I plan to invest in improving Firebug startup time? Zero.”

      Note to self: Do not use anything this guy writes ever. Granted start up time isn’t as important for a debugging plugin than it is for a general use one (a web developer is likely to have the browser permanently open) but that attitude really makes me want use a different product.

      1. johnjbarton wrote on :

        You lost me here. You say startup time isn’t important for debugging, but we should stop working on something that *is* important to fix start up time? If I don’t then I have a bad attitude?

    3. Wladimir Palant wrote on :

      John, the problem is that the startup impact of any single extension usually isn’t noticeable – but users with many extensions will have problems and blame Firefox because no single extension can be blamed. Though I must say that my main incentive to improve startup time was Firefox Mobile (which isn’t a relevant target platform for Firebug of course).

      1. johnjbarton wrote on :

        Actually we are working very hard on Firefox Mobile! That is certainly something important to our users. Should we stop working on Mobile and improve startup time? I don’t think so!

    4. Michael Curry wrote on :

      @johnjbarton

      I agree with you: start-up time seems far less problematic than memory footprint and CPU use.

      How many users close and restart FireFox repeatedly, compared to those who keep it running for days or weeks on end? The only time I restart FireFox is because it (or one of the installed add-ons) is eating all of my system’s memory, causing serious performance degradation. (I don’t reboot my systems unless absolutely necessary, so I keep FireFox running all the time, memory use notwithstanding.)

      I like FireFox, it’s been my default browser for years, but I’m slowly moving away from FireFox, towards Chrome, because of the memory consumption and CPU use problems I’ve experienced over the years.

      I’d prefer an ability to inspect each FireFox add-in’s memory and CPU use (as I do with Chrome’s task manager via shift-ESC) so I can determine which add-on is causing the trouble, and disable it. Without this facility, I’m left with a tedious task of disabling each add-on and restarting FireFox to try to identify the culprit.

      1. Ed wrote on :

        I think you forget that leaving your browser open 24/7 isn’t how most people use Firefox, and in fact more how developers/advanced users use Firefox (a minority subgroup of Fx’s 400 million users).

        1. johnjbarton wrote on :

          Yes, exactly my point!

        2. Leolas wrote on :

          Exactly!

          Almost no user, if he isn’t a geek or a developer & so no, leaves the pc on for days!
          Almost every user in the world often shuts down pc or the browser…

          It would be a waste of energy to leave always everything on; at least I, as an ALMOST casual user (if I were a real casual user, I wouldn’t be here on the blog reading the post and commenting it..), don’t have any need to let a PC on for many hours or even days or week..

          I’m happy of this new initiative

          1. Eddie wrote on :

            You forget that many people don’t turn their PC off at all. Some have desktop PC’s at work which are left turned on all the time and many users with laptops simply put them to sleep at the end of the day (with the browser open).

            I believe the facility to monitor/test performance of individual plug-ins is very important, even more so that the time added to FF start-ups.

      2. joana wrote on :

        I’d estimate that I restart Firefox 20+ times a day. Almost every day of the year.

    5. Isaac wrote on :

      That’s a pity that that’s your attitude. Your hosting environment is Firefox, and Firebug has an adverse impact on FF startup time. Imagine an application that you installed that slowed Windows startup time by a similar percentage. Wouldn’t you want to improve that then – or would you blame it on Windows?

      1. johnjbarton wrote on :

        My attitude is that Firebug team should work on things that are important for Firebug users. What’s wrong with that?

        1. pip25 wrote on :

          John, the problem you do not seem to realize is that most people don’t even know that Firebug is responsible for their startup issues. I also use Firebug regularly, but would have never thought that it would cause such a thing.
          Startup time for Firefox 3.6 was abysmal. Version 4 improved things somewhat, but unless add-on developers like you help out, the browser will continue to appear sluggish.
          You don’t see tickets for that? Imagine then that every complaint you saw about Firefox’s speed coming from web developers was a bug report, as their problems were likely caused (in part) by Firebug. Suddenly, you will notice quite a few people mentioning the issue.

    6. Gerald wrote on :

      i think, john is right. firebug may increase startup time, but it also adds a whole lot of functionality. and its easy to deactivate, when i don’t do development work.

      still it’s good to know, what effects addon have on performance, to judge the tradeoff.

    7. Tobu wrote on :

      I do care, I noticed that firebug tends to slow down page load, and I now install it to a separate profile for web development.

      I remember the firebug team made efforts to have lower impact when firebug is disabled, but I don’t objectively know how successful this has been, so I find Mozilla’s automated testing a very welcome move.

    8. Mxx wrote on :

      But is startup performance that much of a separate and isolated issue?
      Wouldn’t looking on a startup time can also benefit addon’s performance elsewhere/overall (and other way around, overall performance can/will(?) improve startup time)?

  10. fan wrote on :

    Great idea. Please also measure events/s from powertop, to save power, increase battery time and decrease heat output on laptops.

  11. neuroxik wrote on :

    I was wondering if some add-ons listed on the performance page (a great initiative by the way!) could get better results (less load time) if some of these add-ons’ features are disabled. For example, StumbleUpon is ranked #14 with 19% slowing up, but I disabled prefetching within that add-on, does that count in the scoring, or are the benchmarks done with all options on?

    It would be great, if that were the case, to have a downloadable app (to avoid putting it online and spare Mozilla’s servers’ CPU) to do these tests ourselves, then we can uncheck some options in particular options that we “don’t mind leaving aside but would if it were for a speedier Fox”, re-run the test, and check for ourselves.

    Anyhow, props to the Mozilla team once again!

    1. Mandy wrote on :

      I think you mean, anyhow, props to the IE9 team? – http://www.mostiwant.com/blog/speed-up-internet-explorer-9-by-disabling-unusefull-add-ons/

  12. john york wrote on :

    let me start off saying I love Mozilla firefox, I love it so much that the only thing left for Internet explorer is hate.
    Anyway, I have wanted to download the add on video downloader, I don’t recall which one I wanted to try first because it didn’t matter.
    It didn’t matter because the new firefox 4.0 will not allow me to watch videos from the sites I normally watch videos from such as megavideo, zshare, loombo, etc.
    I can watch youtube videos probably can download them if I include an add on, but I want to be able to use the add on for the other websites also.
    Is there something we can do to do this?

  13. Anon wrote on :

    like asymmetric above said, in my opinion it’s much more of a priority to be able to measure the extent to which a certain extension leaks memory or affects overall performance or responsiveness during actual use, boot time was never really a problem for me and in FF4 is perfectly acceptable already. the definitive step would be some method to determine when certain combinations of extensions recursively affect each other to have an adverse effect, troubleshooting that now it’s too much of a shot in the dark.

  14. Mora wrote on :

    As mostly an end user, I applaud any policy changes that improves user experience. Cold startup was /is a big problem for Firefox, so this is very welcome. Firefox 4 improved startup a lot, but it could get better especially on older/lower powered machines.

    Also I am loving the seemingly new found assertiveness in Mozilla’s vision and implementation since Firefox 4 was announced. Old timers like me don’t agree with everything like how the status bar got killed, but I haven’t been this excited about Firefox since version 1.

    Mozilla is becoming like Charlie Sheen in a good way, you guys only have one gear which is to go.

  15. Shrijit wrote on :

    Superb initiative, can there be a similar initiative to check the memory leaks done by an add-on?

  16. Ed wrote on :

    This is awesome – hopefully now users will at least stop blaming Firefox for slow startup times after they’ve chosen to install 50+ addons.

    I’m presuming that eventually this performance data will be surfaced in all/most of the following?
    – AMO on each addon page (in addition to the general performance overview page)
    – Addons manager -> Get addons
    – Addons manager -> [Already installed] Extensions

    Are there bugs filed for each of these on bugzilla, so that we can follow progress?

    Also, do you know if the following ideas are being considered?

    – Listing performance figures on the new UIs being created in https://bugzilla.mozilla.org/show_bug.cgi?id=596343 and https://bugzilla.mozilla.org/show_bug.cgi?id=476430 – ie: warning a user that:
    (a) Do they still want third party addons XYZ enabled (after doing a major update)
    (b) Every time a new third party is detected, asking if they really want to enable it.
    (The proposed UI mockups don’t mention that addons can slow Firefox at all; let alone include figures from the Talos addons testing)

    – Pro-actively warning users (using an in-app popup) if addons are slowing down Fx startup by more than X percent – like IE9 does http://i.imgur.com/TC3Rb.jpg . This may appear only subtly different from passively informing the user in the AOM; but given that many users won’t frequent the AOM regularly (or may not even know what it is; if the addons in question were installed by third party software/another user) – it will actually make a huge difference to whether users even know about the performance figures.

  17. Kenne wrote on :

    Fast performance is very important to me. I don’t want only those add-on’s that slowdown Firefox by 25% or more to be explicitly displayed in my browser. I want all of their speeds; at least the top 100 list that you are creating.
    Even if an add-on only slowed down my browser by 10% or 5%, it may not be worth it to me to keep it running. I think I deserve to know the exact speed of all of my add-on’s that are on your top 100 list. (and preferably, the top 250 list)

  18. AdBan wrote on :

    Nice initiative.
    It would be great if both addons.mozilla.org and add-ons manager could suggest alternative add-ons with similar functionality but with less negative impact on performance 🙂

  19. ConceptJunkie wrote on :

    I think this is a great idea, but I can count the number of times I start Firefox in a week on one hand. Besides, I usually have a couple dozen tabs being restored so it isn’t responsive for a minute or two regardless. In other words, start-up time is largely irrelevant to me. That doesn’t mean it’s not important, but improving start-up time will improve my Firefox experience (which is mostly great) negligibly.

    On the other hand, Firefox had become so slow on my Netbook (3.6.x and 4.0 nightlies), I abandoned it months ago for Chrome. I still use it on faster hardware, because I prefer it, but decided the only way to ever be able to use it again on the Netbook would be to install a completely fresh copy, no add-ons, no nothin’, and slowly and laboriously figure out which add-on is causing the problems. Or I could just keep using Chrome and not worry about it, which is a compromise I shouldn’t have to make. The thing is, I don’t even use a lot of extensions and add-ons, although I’m always suspicious of anything involving Flash or Java.

    So I appreciate the effort. It’s a good sign that there’s recognition that the primary performance issues with Firefox are often (perhaps usually?) not Firefox itself. Anything that help developers and users determine what is making Firefox run (as opposed to start up) slowly will be a big win.

    Thanks for all you do with this great browser.

    1. Ed wrote on :

      Out of interest, what’s the difference between using Chrome (with no addons) and Firefox with no addons. Surely if you are starting from fresh then it would have been no less hassle to just start with a new profile in Firefox – in fact even less hassle, since you could have used Firefox syn to backback history, passwords and bookmarks – and restored these straight into a nice clean (and addon free) fast Firefox 4 profile…

      1. Ed wrote on :

        s/syn/sync

        s/backback/backup

        Typotastic!

        1. ConceptJunkie wrote on :

          Simply because I didn’t think of it. I completely forgot that I could just make a new profile without having to clear everything out. Thanks!

  20. Gingerbread Man wrote on :

    I need precisely 12 extensions to fix features that you’ve either botched, removed or copied poorly from other browsers, or bugs that have persisted for ages. Add-on authors are not they problem; they’re the sole reason I’ve stuck with Firefox despite its myriad of flaws.

    1. Paul [sabret00the] wrote on :

      What add-ons are these saving the day for you?

  21. JanW wrote on :

    “What can Firefox users do?

    The best way to combat slow add-ons is to disable add-ons you no longer use. Disabling an add-on will prevent it from loading and slowing down Firefox, yet keeps it in your Add-ons Manager so that you can re-enable it anytime you’d like.”

    Good point.
    As a user, I would like to (be able to) disable:
    – personas
    – sync
    – panorama

    I (will) never use them. Gimme some easy buttons or options to disable them. Right now, it’s becoming more and more a PITA to disable these built-in add-ons (if it’s even possible to disable them completely).

    Oh, same goes for other future ‘features’ I will never use, but that goes without saying…

    1. Jigar Shah wrote on :

      Yeh…Why those are integral part of FF ?

  22. Aldi wrote on :

    The add-ons are the main reason I chose Firefox over the others, especially Firebug. Thus asking users to disable add-ons is really not a wise advice nor it is the solution I’m hoping to hear. I also use Google Chrome besides Firefox and have quite a number of add-ons installed on it too, but they don’t seem to have much impact on the browser’s performance (start-up, RAM, etc.). So what’s Chrome doing right that Firefox isn’t?

    By the way, I get 700-1.2+gb of memory usage within 2-4 hours of browsing before it finally crashes and 300-500mb in Safe Mode. This was no difference in version 3. I hope Firefox will look into this issue.

  23. Kohei Yoshino wrote on :

    A Japanese translation goes here:
    https://dev.mozilla.jp/2011/04/improving-add-on-performance/

  24. Mora wrote on :

    @johnbolton,

    Nobody is forcing your hand. Firebug is a developer tools used exclusively by developers. I think you should trust them to make the judgement call on whether to continue use Firebug, despite its horrendous impact on startup.

    Instead these addon policy changes will have a greater impact on the the vast majority of Firefox users who aren’t aware of how addon may impact their performance. There is nothing wrong about educating, and empowering Firefox users to informed decision concerning their user experience.

    1. johnjbarton wrote on :

      There is something wrong with misinforming users.

      The page https://addons.mozilla.org/performance has data about % increase in startup time. But everything else about the page, including the title and introductory paragraph gives the impression that the addons listed “slow Firefox to a crawl and make it difficult to use for regular web browsing”. The page gives no data on regular web browsing.

      Moreover, what you call “horrendous” is on the order of one second of overhead when you start Firefox. If you start Firefox twice a day for a month it’s all of one minute. Not horrendous, just a minor problem to fix some day.

      1. joana wrote on :

        50 million users * 1 seconds extra wait per day * 200 use days = 318 life years wasted on startup wait per year

      2. Joe wrote on :

        Thanks for saying what I’m thinking.

  25. Savageman wrote on :

    I’m not a extension developer, but something else to consider is to defer the loading of some components.

    For example, you don’t need Firebug right after Firefox has started, the loading could just be done when we activate it. Once it’s loaded, it’s ok.

    I feel it makes a lot of sense to wait 2 sec for Firebug to load the first time we need it than to delay 2sec the startup time of Firefox.

    It has to be built in the extension API, and I don’t know if it’s currently possible.

    What do you think?

  26. Zizounnette wrote on :

    Nice.
    would have been great to see the category of each plugins. Btw, mostly are for developpers and not used by std::Users 🙂

  27. mark wrote on :

    what about adding an easy access button which will turn on/off all installed addons?
    for example, when i’m doing some development work i will turn on all necessary addons, but when i’m just browsing – i click one button – and all my addons are disabled. it would be really conviniet.

  28. Sami Mikhail wrote on :

    Frankly, startup time is not a concern for me. Firefox comes up and stays up. All the time.

    I am more concerned with performance degradation over time.

    If testing can show that Add-Ons are culprits, then by all means identify and fix.

    But if the core engine is at the root of the degradation, then some framework level testing/debugging/fixing needs to happen ASAP.

  29. André wrote on :

    Can you add ETW to Firefox so that we can use xperf to trace such addon issues?

  30. DMcCunney wrote on :

    While I’m all in favor of increasing performance, I think this may target the wrong problem. Additional load time is the *least* of the issues an addon might present.

    Yes, installing addons may increase start up time. So *what*? I have about 40 extensions installed in FF 4.0. Startup time in my installation for a barebones FF instance with no extensions installed is about 4 seconds. Startup time in my production profile with 40+ extensions installed is about 6 seconds. Oh, my! The sky is falling! I’m going to grow old and grey waiting for FF to load!

    Yeah, right.

    The *far* longer time taken on startup is when FF reloads tabs I had active when I closed it, as it must establish connection with each site and restore the pages. I’m at the mercy of the other end, and there isn’t a lot FF can do about it.

    The problem isn’t that start up time is longer, it’s that users have bad habits inherited from IE. Using IE, which is really part of Windows, you see quick startup time because IE *is* part of Windows, and a good bit of it as already loaded and active as part of Windows. So users are accustomed to hopping in and out, opening IE to view something, and then closing it again. That’s fine for IE, but a problem on a layered product like FF. A couple of extra seconds on startup when you load FF once per session is negligible. A couple of extra seconds when you are constantly hopping in and out is not.

    It’s like the old old joke: “Doctor, it hurts when I do this!” “So don’t *do* that!”

    I’ve had a number of conversations with folks complaining about FF load time when I say “Instead of hopping in and out like you do with IE, do what I do: start FF *once* and *leave it running!*. When you need to look at a web page, the running instance will be used and your load time issues will go away.” The response is usually “Gee! Thanks! I never thought of that!”

    Want to make using FF a happier experience for the user base?

    First, encourage good usage habits in the first place, like *not* hopping in and out of FF like they are using IE. Start FF when you sit down and just leave it up.

    Second, work further on reducing memory footprint.

    Third, implement monitoring facilities in FF that make it easier to tell the impact of particular addons in memory and CPU usage. On my production profile, FF 4.0 loaded with no open tabs uses about 200MB of RAM according to Process Explorer. Barebones FF with no add-ons uses about 50MB. I don’t mind the memory usage, but I’d be happier if it was easier to tell which add-ons were adding what to the load. See the Task Manager in Google Chrome for the direction I wish FF would take: a box listing each installed extension, and the memory and CPU Chrome thinks each is taking. If Firefox knows this, it should have a UI to make it visible to the user. If Firefox *doesn’t* know this, it needs monitoring code added so that it *does* know it.

    As an additional part of one, two and three above, better memory usage monitoring with more ability to see what is using memory. If I start FF 4 and simply leave it running, I see a gradual but small but sure memory usage increase, even if the browser is doing nothing at all with no pages open. Some addon is leaking memory, but which? I have no good way to find out, save tediously disabling one at a time, restarting FF, and leaving it running for hours to see what happens. Since I have the RAM, and the increase is small, I can’t be bothered to go through the trouble – easier to just restart FF if things get problematic. But I *should* be *able* to simply leave FF running, and expect it not to continually use *more* RAM when there is no active usage occurring. If something *is* leaking memory, it should be much easier to find out what.

    Focusing on startup time is potential misleading. You have to look not only at how long the addon takes to start, but what it does when active. I use perhaps ten of the addons in your startup time list. Firebug is in your top ten. But Firebug is a critical tool for developers. I don’t begrudge the fact that it ads ~< 1 second to start time – I'd cheerfully tolerate twice that, given what it does once up, especially since I see the impact perhaps once a day.
    ______
    Dennis

  31. Kai Liu wrote on :

    While I do welcome and applaud the effort, this execution was horrible.

    1) Startup time is one metric, but not the most important metric. Furthermore, cold startup time is dominated mostly by disk activity. Just because an addon is slow does not mean that it is slow because of bad code.

    2) Not everyone cares about startup time. I rarely restart my browser, so I care much more about in-browser performance than about how many extra seconds it takes to start up Firefox once every few weeks (and my startup time is VERY long because I normally have literally hundreds of tabs that I’m restoring). For me, what matters is in-browser performance.

    3) Percentages don’t mean much, esp. if it is based against a clean profile with no extensions. A person who has a dozen extensions installed and dozens of tabs to restore on startup could have a startup time that takes several seconds. So would installing a 50% extension add several more seconds? Or just a fraction of a second? You have concrete numbers. Use them. “On a typical desktop system from 2008, XYZ addon will add 100ms to your startup time”. This is far more informative and less alarming. And it lets users make a better decision regarding cost-vs-benefit.

    I know you don’t have in-browser test suites yet. And that’s fine. That’s why you should wait until you have better metrics before you put up a list that, as John Barton puts it, is misleading.

  32. joana wrote on :

    Putting a spotlight on add-on optimization is good. But isn’t that just a symptom of a more basic fault: couldn’t Firefox be designed to first load only the functionality needed for basic webaccess and a few seconds later let the add-ons load? If there are technical barriers then solve them. When the user starts the browser he/she most often have a specific use task in mind. Start whatever most users need on start first and only thereafter everything else.

  33. Will wrote on :

    So now who is copying who? :p

    You guessed it. Firefox copying IE.

    Good, about damn time. lol

    Win, Win for both user groups. So I’m happy.

  34. HaWo wrote on :

    What’s about FireFox Preloader ?
    I’m running W7x64 w. FF4

    Not one prob with that old (2005) prog

  35. PepGuardiol wrote on :

    Mozilla copying IE9… curious

  36. drugoime wrote on :

    Is only start-up affected, or the overall performance? And what about some kind of task manager, like the one in Chrome, which shows ram-memory usage?

  37. Neal G wrote on :

    I noticed with Google Chrome, with each addon that I enable, it creates another process in my activity monitor (on my Mac). Because of this I can monitor individual addons to determine which ones are leaking memory. With Firefox, these are all apparently under the main firefox.exe process. I do appreciate you guys separating out the plugins (flash etc.) from the main process but perhaps the addons should also be broken out. Either that or providing us with a tool that monitors memory usage of addons.

    Like so many other users have mentioned (over and over again), our real issue with Firefox or Firefox+addons is it’s memory usage and less with the startup time. It regularly consumes over 1gb of memory and usually when it gets to this point, it starts affecting the performance of simple actions in the browser like opening new tabs.

  38. David Illsley wrote on :

    Can someone comment with more details of what the automated testing is doing? Is there a session restore? Would extension first-run pages be triggered? en-US only? etc etc…

  39. Ken Saunders wrote on :

    I have, and probably will never understand the complaints about startup time. I just don’t get the big deal. It has never bothered me probably because I understand that adding anything to anything adds weight and is bound to slow things down, so it should be common sense that adding add-ons would slow down Firefox in one way or another, plus the media has done a modest job of mentioning that. Last year a number of sites were posting articles about how removing locale files -manually- from xpi’s (if you can imagine that) can improve startup time.
    I am a power user. I’ve at times had 90+ add-ons enabled and (cold) startup was never more than 30 seconds which I felt was reasonable under the circumstances, and that wasn’t on the most powerful machine. I’ve argued time and time again on blogs and sites around the web that Firefox out of the box only took a few seconds to startup, and that it’s add-ons that slows down startup. People just don’t get it because who the hell am I. I don’t use my primary profile for development of any kind because i know better.

    So, I also agree that a good campaign to inform and educate users that add-ons can affect startup time is a better idea than pissing off and chasing away developers. We lost a lot of good and veteran themers recently and I’d hate to start seeing that happen to extension developers who feel pushed out like those themers did.

    Add-ons are what kept Firefox strong against Chrome pre 4.0. Are they no longer the big draw and a deciding factor?

    “Add-ons provide many useful features and functions, but they can also cause Firefox to become slower. Some add-ons can even slow Firefox to a crawl and make it difficult to use for regular web browsing”

    I think that it would be fair to provide a breakdown of exactly what types of performance issues add-ons may create/affect. If it’s being reported that an add-on makes Firefox 74% slower, is that overall, or that it just slows down startup by 74%? If it’s just startup, then it isn’t really an accurate or truthful report.

  40. roland wrote on :

    Wouldn’t it make more sense to look at performance impact (CPU & RAM usage) while using the browser with an add-on installed, configured and enabled? I don’t care about having to wait another second or two to start my browser if it means I won’t have to worry about it hogging all resources due to a leaking add-on.

  41. Sz wrote on :

    What about high profile addons that are not on AMO, for example Zotero? Often when Firefox is starting up while my computer is under load, I get “unresponsive script” dialogues. Every time is a script that’s part of Zotero.

  42. Jed wrote on :

    Excellent job as always guys, very clever initiative…
    Keep it going & make it even more sophisticated/integrated going forward!

  43. George wrote on :

    Is it possible to script a page so it knows if a required add-on/plugin is disabled? Currently my page that uses a particular add-on/plugin cannot distinguish the difference between a disabled one and one that has not yet been installed. Thanks.

  44. Piotr wrote on :

    Way 2 go!

  45. Jim wrote on :

    I agree with the many comments above stating that startup time is not the primary issue I face as a Firefox user. By far, the biggest problem is memory leak/excessive memory/CPU usage, which is a problem that impacts me daily. Excessive CPU/memory usage breaks Firefox; slow startup does not, and I have not noticed it as a problem anyway. This CPU/RAM memory usage issue is a WIDELY known problem, but not one that I have ever seen Mozilla/Firefox team publicly address. Consequently, i too find the prioritization of Firefox startup time over Firefox memory leaks/excess memory usage to be quite strange indeed.

  46. Alex wrote on :

    I think the general idea of this initiative is good, but it is nonsense to use start-up time as a measure for the quality of an add-on. Of course it needs time to load, but maybe browsing performance will be improved, e.g. when using Adblock Plus.
    So only the performance and memory used during usage of the browser is a valid indicator for me, not start-up time!

  47. Alex wrote on :

    Forgot to mention “Ghostery” as another example why this start-up thing is nearly useless.
    This add-on is not in your list, but during use it slows browser down, e.g. on Google maps it was awful, even getting script not responsive errors.
    Uninstalled because of performance, and it seems to be redundant when using Noscript and Adblock “EasyPrivacy” list.

  48. Mike Ratcliffe wrote on :

    I want to point out that this drive is driving some people *away* from Firefox in some situations.

    At one company I used to work for the management have told them to do all of their web development using Chrome because of these statistics. This means that a lot of them no longer even have Firefox installed on their PCs!

    Ironic especially because the 75% figure for Firebug is only actually a few milliseconds. Maybe putting up the actual time rather than a percentage would be a good idea?

    Incidentally, we would defer Firebug’s startup but it really isn’t an option because we need to hook in to the debugger etc. but maybe in the future we can bring the number down a little … bear in mind we are only talking milliseconds here though and we will be waiting on internal changes in Firefox in order to spead things up in a lot of cases.

  49. Sylvia wrote on :

    My Firefox either takes for ever to start or just doesn’t open at all.

    syy

  50. Shaun wrote on :

    Why do “add-ons” become “extensions”? You search for add-ons, research add-ons, download add-ons, set them up as add-ons, and think you are using add-ons. The you want to turn one off or something and you cant find them, Until you discover this little grammatical clusterfuck. Why does EVERYTHING need to be so fucking stupid? Why is the add-on manger an advertizement for more add ons, and the actual add on manger called extensions? for fucks sake.

    1. Jorge Villalobos wrote on :

      “Add-on” is a term that includes extensions, themes, dictionaries, language packs, personas and search engine providers. We know it can be confusing, but there are so many add-on types that we need to make the distinction. It doesn’t help that other browsers only talk about extensions or add-ins.

More comments:1 2