Tracking Firefox UI Response Time
Posted: February 21, 2011 Filed under: firefox, mozilla | Tags: firefox, jetpack, mozilla, Performance 22 CommentsI wrote an add-on for Firefox 4 that tracks how long various parts of the browser’s user-interface take to load. It does not require a restart of the browser.
- It measures the duration between ‘popupshowing’ and ‘popupshown’ events. This covers menus, menu-like things, and those floating panels you’re starting to see everywhere.
- You can see your results at about:response. There won’t be anything there if you just installed the add-on. Browse around for a few days and then check it out.
- It doesn’t track popups without an id yet. It could also be nicer by showing the containing menu name if available.
- I’d like to add window load times. What else in the front-end could we be measuring? I was thinking about <command> execution, but there’s not a way to do that without modifying the core, afaict.
- Perhaps we could add a button for users to submit their anonymized data somewhere.
Try it out, let me know if you have any problems. The source code is available on Github.
dietrich.ayala 
RESOLVED HOT
I’d like to see the information go to some anonymous public repo, with which someone can hopefully fix UI responsiveness issues.
Very nice 🙂 Would love to make UI responsiveness info available on the new graph server (and also the regression finder), is anyone working on this already?
[…] Visit link: Tracking Firefox UI Response Time « dietrich.blog […]
Rob: Ted is working on this in bug 631571.
That’s really cool, Dietrich. It will come very handy for the FPS tests too 🙂
Another thing that would be nice to measure in the front-end is tab switching time.
Also, for sharing the data, mfinkle hinted at something yesterday:
I’m curious to see where that goes 🙂
Been running it for a few hours now..
[…] This post was mentioned on Twitter by Planet Mozilla, Paulo Freitas. Paulo Freitas said: about:response – Nova extensão do Fx 4 p/ vc mensurar a responsividade da UI nos mais variados eventos. 🙂 http://goo.gl/gTQcj #testers […]
Really nice add-on. I wonder however – how comes there is a standard deviation for pop-ups that only opened once? The way I remember it, the standard deviation for one measurement point is always zero.
I concede that you are right! Fixed in the next version.
Is there anything useful we can do with the data we collect? I’d be happy to send it to you for collection and whatnot.
If you see something that really stands out as slow, definitely file a bug and cc me. Or just email me.
Ideally we can find a way to let users submit their data somewhere, for identifying broader performance patterns.
Wouldn’t this be a perfect thing to push on Test Pilot?
Er…All I can think of is why didn’t you spent your time improving the load time instead of creating this addon that i’m sure all the Firefox maniacs will start asking why there browser is this slow…just another example of how wasteful Mozilla really is.
Hi Birdie.
1. We first need to know what’s slow, before we can fix it. Otherwise we really *would* be wasting time 🙂
2. This add-on took about an hour to build. Not overly wasteful, I think.
3. What have you done lately to help Firefox be faster? If you’d like to help, I can definitely show you how 🙂
#3 is where I always get the haters to stop talking. =)
What I have done is sending all the bug and request found to Bugzilla, what…that is that not good enough for Mozilla? And it looks like most user’s reports fall on Mozilla’s deaf ear because apparently Mozilla don’t really take their user’s request into consideration and start working on wasteful things like panorama and adding useless feature to the already inefficient XUL GUI. Panorama still lags like hell. That new tab animation slow down considerably for that last how many betas since it was added. I can go on forever all these common complaint over Bugzilla, but I don’t think Mozilla know any different…No wonder more staff starting to leaves Mozilla to work elsewhere.
Can you put this on AMO?
Të: Test Pilot runs short-term tests, where data isn’t necessarily available immediately to the user. This add-on is useful for allowing us to pinpoint immediately which the problem parts of the UI are, or to track over a long period of time (or both).
Dan: Sure, I’ll put it up on AMO asap.
Any progress on where we can share this data to? =)
[…] to some new Talos tests, I was thinking of adding some monitoring to Test Harness. Dietrich has an add-on to collect some UI responsiveness measures. I think we could add something like that to Zippity. […]
Y’know, I read about this some time ago via the planned features for FF6, but for some reason I only actually found this page now. And wouldn’t you know it, the addon doesn’t work with FF6. 😦
Are you going to update it? I was looking forward to finally getting to the root of my FF responsiveness problems, but it seems this is the closest thing I’m going to get to something vaugely user-accessible.