Learning from Tech Luminaries F**k That; Love The Tool You’re With
Dec 22

Using the crowd to tell us about browser responsiveness

Google, Mozila, Tech Add comments


A lot of people are talking about the interview with John Lilly that discusses the relationship between Mozilla and Google.

People like to paint think black and white. Either Mozilla is Google’s poodle (Mozilla is to Google as Tony Blair was to George Bush) or there is a falling out and they hate each other.

Of course, the answer is grey as John points out. From my standpoint, focusing on the Open Web, I see more areas to collaborate on than to fight over. When I was at Google I knew that the Open Web was very important to the long term future. Now I am at Mozilla, the same is true. At the micro level there will be differences, but at the macro-level there is alignment.

Switching gears a little, I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.

Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.

Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.

Now, this is a lot of engineering away, so can we use the crowd to help out?

What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.

What do you think?

12 Responses to “Using the crowd to tell us about browser responsiveness”

  1. Evren Kiefer Says:

    It would be great ! This would create incentive for the add-on developers to include performance in their decisions and benefit all their projects. I’m all in favour of this one.

  2. Vladimir Dzhuvinov Says:

    What do I think? ;)

    My gut feeling is that Firefox will evolve into a Godzillean OS-like monster with typical OS features like protected memory spaces, tab scheduling, antivirus addons and whatnot :)

  3. dion Says:


    Yes, and we could of course give them feedback through the system. I am sure there are situations where multiple plugins can affect each other etc. We need to give our addon developers more tools!

  4. dion Says:


    Hahaha nice. I guess as the client of the Web platform, as developers build richer apps, we need to give them more :)

  5. Wladimir Palant Says:

    I don’t think it would be that hard. The JavaScript debugging interface gives you access to that kind of information, you can get the execution times for each script and cross-check that with the origin of the script. Problem is, profiling needs to be turned on explicitly – and when it runs it slows JavaScript down a lot, it also changes execution times somewhat. Finally, JavaScript execution time isn’t everything, sometimes JavaScript will trigger native code and that won’t be as easy to attribute to a particular extension.

  6. Pseudonymous Coward Says:

    It’s certainly a developer’s feature, not a typical user’s feature. I also think that it is not worth the time competing with Google for the sake of it. Should everyone adopt the multi-process model simply because Google did it? If so, why not go a step further and dump XUL and all that jazz and take up Erlang instead? Fads are one thing; sound computer science quite another.

  7. Ran Says:

    I like to paint think. :)

  8. Phones Says:

    Yes, it’s really ‘complicated’ between Mozilla and Google~

  9. James Says:

    I think that would be BRILLIANT!

    Right now I’m suffering from a sluggish browser with new windows taking up to 10 seconds to display (not new tabs).

    A debugger to help diagnose would be cool.

  10. Albert Says:

    @Wladimir: if profiling hurts performance too much, it’s probably not the way to go. But why not do some simple sampling of timers on highly visible performance areas? For instance: opening a tab, a new window, etc.

    The problem with profiling an addon is: you don’t know what the addon is meant to do. For instance, lets say someone builds an addon that does some image blur filtering before page load. The load time of a page increases, but wasn’t this to be expected? Blaming an addon for being ‘badly’ programmed in such a case doesn’t seem right.

    Perhaps the statistics should be added to the AMO site, so that people can decide if the performance impact is worth installing extra functionality.

  11. Albert Says:

    Duh, that last part should read: if installing extra functionality is worth the performance impact.

  12. vila Says:

    i like Mozilla,use it ,i have more choice,but Chrome don’t have any show for me.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)