First! (before you get distracted) Try server builds! and the extension! (Firefox 3.5+)

The Idea In Summary

An idea that’s likely been tossed around before has been brought to the forefront more recently by Firefox’s newest designer Alexander Limi, the idea of per tab network prioritization. The premise of the idea is that what you’re doing right now is more important that what you were doing 5 minutes ago. So to account for the relative importance, we should make what you’re looking at right now load faster. This is really part of a grander scheme to improve perceived performance, but has been reduced to try to make some improvement achievable for Firefox 3.6.

In More Detail

For this pass, we divided tabs into level of importance (shown in descending order):

  • Selected Tab in a Focused Window
  • Background Tab in a Focused Window & Selected Tab in a Background Window
  • Background Tab in a Background Window
  • Any Tab in a Minimized Window

For the most part that makes sense, except for maybe one thing: the 2^(nd) level of importance has 2 items. We decided that (at least in general terms) background tabs in your current window and the focused tab in a background window should get the same level of network priority.

I then used this ranking to assign relative priorities. You can read more in the implementation section, but otherwise you can skip down to the progress report.

Implementation

My original plan was to do this all in browser/base/content (browser.js, tabbrowser.xml), but I ran into a roadblock of some sort. So I wrote it as an extension. After fixing an observer topic, I could do this with relative ease. I set my JS up much like the SessionStore component, observed a number of topics, and listened for a number of events. I was using an observer topic (xul-window-visible) which I was told I shouldn’t use. When a tab was selected it’s network priority gets bumped up and the previously selected tab gets dropped down. Same concept for windows.

I had to create some new events so that I could accurately know which window was focused. Then I brought it into our actual tree instead of living externally as an extension. I cleaned it up a bit, made sure I wasn’t doing to too much, and then finally got around to filing the bug. I would go into further detail, but it’s not super interesting. However, if you are interested, take a look at the code.

While there are some implementation details to improve upon (or just straight up change), it’s doing what it was supposed to be doing. At this point I could move this back into browser/base/content but since it’s working, there’s no value in it (until we decide the project is a final go).

Progress Report

Initial results showed some improvement when loading large groups of tabs. It was most noticeable when loading many tabs from the same site (e.g. the default BBC livemarks). It was somewhat noticeable during a typical (for me) session restore. There was no difference during normal browsing.

But I’m just one person. I know this is all the way at the bottom of this article, but PLEASE PLEASE PLEASE use a try server build (or the extension) for a little bit and see if there’s any noticeable difference. Even if it’s just to load up that 500 tab session you’ve been building up over the years.

Next Steps: Get Feedback! If people use it and the results are positive, this will get more attention (tests, better implementation, checked in). If it turns out that we didn’t quite achieve what we were hoping, then this will get shelved or used as part of another project.

So again: try server builds and the extension!

Updated September 4^(th) with links to the extension