Earlier this year Mozilla shifted from releasing a new version every year or so, to once every six weeks.

So in the previous four years we had five major new builds of Firefox, but this year we’ve already had versions 4, 5 and 6.

Releasing often seems like a good idea; unless you’re in a controlled corporate environment or you develop extensions for a living.

While changing to this new model, Mozilla largely gave up on backwards compatibility to speed up their development process. In the past many interfaces were said to be ‘frozen’ meaning that script based and native binary extensions could rely on using them at any point in the future. That’s all changed so anything can be updated. There’s no guarantee that code in an extension will work with a new version of Firefox.

For native binary components like HttpWatch the picture is much worse. Binary components must be recompiled to work with each new release:

That means it’s impossible for us to ship a version of HttpWatch that will work with a future release of Firefox. Also, we have to add at least one new DLL to our install program for every new Firefox release. It’s not just developer centric tools like HttpWatch that are affected. Even consumer focussed add-ons like RoboForm need updating for every Firefox release.

Of course, Chrome has always been frequently updated but it has a much smaller extension ecosystem because it doesn’t have the range of APIs available in Firefox or Internet Explorer. Therefore, the frequent updates to Chrome don’t cause as many issues because there are less extensions and the extension API is less likely to change as it is so much more restricted.

In comparison, Microsoft has been the master of backwards compatibility across versions of Internet Explorer. For example, HttpWatch 3.2 was last compiled nearly 5 years ago but still works with IE 9 on Windows 7:

IE’s longer release cycles and excellent backwards compatibility really appeal to corporate users compared to Firefox’s new release model.

There was even some talk of increasing the frequency of the Firefox releases to once every five weeks or less. The resulting discussion on Slashdot gave rise to these negative comments about the change:

Have they totally lost it? It’s not like the browser world is making sudden great progress. It’s a mature technology. The big problem today is getting stuff fixed.

Sorry i have other things to do than repackage FF for deployment every 5 weeks.

What FF user actually wants this model? Most of them don’t. Releasing at the same speed as Chrome isn’t going to win over Chrome users, but it will chase FF users off. That’s what we’re seeing here.

If they keep this up, I will remove it from our labs. I am not going to deal with this s**t. Release bug fixes as often as you need to, but new features need to be something that doesn’t happen too often. I can’t go and test this s**t every few weeks, nor do I want to deal with things that are outdated. I like FF, but this policy they have is pushing me to dump it. I haven’t yet, but we’ll see.

Extensions stop working at random without any good reason and in record time. So many of us use Firefox over Chrome because of extensions. This plan is just terrible.

Of course, we are biased because short release cycles for Firefox create more work for us. What do you think?

[polldaddy poll=”5521932″]

Firefox 6 is almost ready for release and we have updated HttpWatch to work with the latest beta versions . While doing this we noticed some unexpected behavior in the way that it creates new connections.

Normally, in HttpWatch you can see when a browser uses a new TCP connection by looking for the yellow Connect block in each request. You can also confirm this by adding a Client Port column to the main grid. Here’s screenshot from HttpWatch showing new client ports being used as new connections are made to the web server:

In Firefox 6 we noticed that existing connections were sometimes re-used even though a request had a Connect phase:

On closer examination we found that Firefox 6 may reuse an existing connection even though it has already started to connect a new socket. The new actions on the Overview tab show exactly what is happening:

Initially, there was no idle connection available for the CSS file download because the first connection was still being used by the request for the page’s HTML. Firefox 6 therefore started to create a new TCP connection to the host. In older versions of Firefox it would simply have waited for the new connection to be completed and then would use that connection to dispatch the second request.

However, in this case Firefox 6 reused the initial connection (port 51384) when it became available even though it was still in the process of setting up a new connection. This new connection (port 51385) wasn’t wasted though. Its setup was completed in the background and the connection was reused by another request further down the water fall time chart.

Sometimes, you’ll even see a case where the new connection is correctly setup but Firefox 6 still reuses an existing connection:

So why does Firefox 6 aggressively reuse existing connections instead of new connections? There are two main reasons:

1. If an existing connection becomes available before the new connection is setup it means the HTTP request can be sent off sooner
2. Existing connections will usually have a larger TCP congestion window and allow greater throughput.

Things are happening fast at Mozilla. Although Firefox 4 was only released three months ago, Firefox 5 is only days away from final release. We can also expect to see versions 6 and 7 later this year.

One of the major performance related changes in Firefox 5 is an improvement in the way that keep-alive HTTP connections are re-used. Previously, there was a simple FIFO queue. So if Firefox ever tried to reuse a TCP connection it would simply use the connection that had been idle for the longest period of time.

However, not all connections are equal. Connections that have transmitted the most data are likely to be faster than those that have only received a small amount of data. This effect is caused by the congestion window mechanism in TCP.

To find out more please take a look at John Rauser’s excellent and entertaining talk at last year’s Velocity conference:

TCP and the Lower Bound of Web Performance – John Rauser

Slides for TCP and the Lower Bound of Web Performance

One of the major changes in Firefox 5 is that it now sorts the idle connections by congestion window size. Connections with the highest congestion window will be used first as described in the related bug report:

Right now the idle persistent connection pool is a FIFO.

What really distinguishes different connections to the same server is the size of the sending congestion window (CWND) on the server. If the window is large enough to support the next response document then it can all be transferred (by definition) in 1 RTT.

Connections with smaller windows are going to be limited by the RTT while they grow their windows.

All else being equal, which as far as I can tell it is, we want to use the big ones. We cannot directly tell what the server’s CWND is of course, but the history of the connection provides a clue – connections which have moved large flights of data (single responses, or aggregate pipelines of responses) will have given the server the best chance for opening that window in the past.

We’ve just updated HttpWatch to work with Firefox 5 beta 5 and decided to see if we could measure any performance gain from this change. Initially, we were disappointed to find no obvious improvement. This was probably because the use of up to six connections per host name allows a fair amount of averaging out of the congestion window. Also, even if a re-used connection is particularly fast its effect may be swamped by the other resources being downloaded at the same time.

The blog post that originally described the benefit of the ordering of connections by congestion window size used a particularly scenario:

Using an experiment designed to show the best case, the results are better than I expected for such a minor tweak. This was my process:

• construct a base page mixed with several small and several large images plus a link to a 25KB image. There are 6 objects on the base page.
• load the base page – FF4 will use six parallel connections to do it
• click on the link to the 25KB image – this will use an idle persistent connection. Measure the performance of this load.

Based on this we tried the same sort of process. First opening the HttpWatch Overview page and then clicking on a link to open a full resolution screen shot:

The performance benefit we measured in this scenario was substantial. We consistently found that the screenshot image loaded about twice as fast in Firefox 5 as it did in Firefox 4.

Here’s the screen shot image being loaded in Firefox 4:

and then in Firefox 5:

With HttpWatch it’s possible to track how the browser uses connections. You can do this by adding the Client Port column to the main grid. Each new TCP connection will use a different local TCP port and this is a handy way to see how connections have been used on a page.

In Firefox 4 you can see that the screen shot image was loaded on the first connection that became idle:

This connection hadn’t done much work so its congestion window would have been relatively small.

In Firefox 5, the screenshot image was downloaded using the connection that had loaded the largest amount of data on the previous page. It would have a much larger congestion window and would therefore be able to download the image much more quickly:

Although, this relatively simple change in Firefox 5 typically didn’t make much difference in certain scenarios the performance improvement can be dramatic.

So how does IE 9 compare? It appears to use the same FIFO algorithm as Firefox 4 with similar loading times: