Faster Firefox Performance Tweaks Myth and Legend

Firefox configuration changes to make it faster may actually be making it slower, or doing nothing at all.

I’ve just finished doing some extensive research on the various Firefox performance tweaks floating around the internet and their dependence upon the tweaks found in Fasterfox as their starting point.

The interesting piece of the puzzle is that many so-called experts actually do not know what they are talking about and have instead erroneously taken some Fasterfox tweaks and then increased them without knowing what they are doing.  The result is a browser experience that is not any faster, and in many cases may actually be slower.

(Note: I have not used Fasterfox. It might work fine. I’m guessing that some of these clowns advocating these kinds of changes have taken the tweaks made by Fasterfox and then increased them thinking that it make it even faster. It does not.)

Make Firefox Faster With These About:Config Changes – NOT!

Most of the configuration changes suggested to make Firefox faster revolve around the network.http series of parameters in the About:Config file.

To access the configuration file in Firefox just type about:config where you would normally type in a web address like www.arcticllama.com.

The problem with most of these changes is that they ignore two critical truths that are inviolable by any browser.

1. Your browser can only do what the server it is requesting data from will allow it to do.
2. These settings act in concert with each other and other settings.

So, setting your network.http.max-connections-per-server to 200 will do nothing if the server on the other end of your connection only allows 10 or 20 connections per user.  This is not uncommon.  In fact, some servers consider this rude, or worse, a potential hacking attempt and will actually “stuff” your connection.  Jacking this setting up more than just 5 or maybe 10 not only will not make your browsing any faster, it might make it slower thanks to server behavior.

It is also worth nothing that the network.http.max-connections-per-server setting interacts with the network.http.max-connections setting, with the latter being the total limit on ALL FIREFOX CONNECTIONS.

In other words, if you open several tabs at a time, jacking up the max-connections-per-server can make your browsing way slower.  Here is how.

A chucklehead with his max-connections-per-server set to 200, connects to 3 different servers through 3 tabs.  The first page starts loading, and the other two tabs sit blank with the little revolving icon spinning, but no data coming.  Hmm, our bozo thinks, those sites must be slow.

Actually, the first tab used 200 connections to that server, just like it is supposed to do.  However, our user’s network.http.max-connections is set to 256.  Since the first tab has used up 200 of the total of 256 connections available just for that one server, there are only 56 connections left which are used up by the second tab, leaving the third tab to wait for a connection. 

If one of the servers in question decides to queue all of those incoming requests instead of answering them all at once, which it is certainly likely to do, then maybe 90 of the first 200 are not being answered.  They sit there waiting for an answer which they won’t get until the first 10 connections are finished.

A non-savvy Firefox user would respond here by increasing the max-connections.  That would solve one part of the issue.

But, there is another problem lurking.  The parameter network.http.max-persistent-connections-per-server sets how many of the connections to each server should be persistent, that is not released immediately after completion of the data transfer.

Having read somewhere that, “keep-alive connections improves performance” our ding-dong has jacked up that number too.  Let’s say he set it to 64.

That means that the browser attempts to establish 200 connections to the first server and then tries to keep 64 of them open via keep-alive.  But, the server is only responding to 10 connections at once, so the first 10 are answered (and then kept alive), then the second ten (and then kept alive), and so on.  All of this leaves precious few connections for our other tabs, and 64 of them waiting for a 10 second timeout.  With even three tabs, this will result in a slower browser. 

Now, you might be asking, why do people say these settings are faster if they aren’t.  The answer lies in the difference between testing and using.  As you can see above just three tabs might not suffer a lot in a mismatched configuration.  After all, connections can be established and brought down pretty fast (except the persistent ones) when looked at in the human world where things are measured in seconds.

But, a user can run 20 tabs without breaking a sweat and these tweaks will actually result in a seriously degraded experience with the user waiting for the last tabs to load for several seconds, or even a minutes.

Faster Firefox Settings Reality

Unless you actually understand each setting AND how it relates to the other settings, changing the configuration file in Firefox is nothing more than speed bingo.  Make some changes and hope they come up a winner.

If you want to make your Firefox browser faster, then make sure your network.http.max-connections is set much higher than your network.http.max-connections-per-server setting unless you only use a few tabs at a time.  Do not jack up your persistent connections by big amounts.  Servers won’t let you keep 64 persistent connections open anyway, so there is no value in taking the number up that high.

Get used to the idea that the average server won’t let you have anything remotely close to 100 connections open at a time.  Even 64 is probably pushing it. 

Pipelining

A word about pipelining.  Almost all of these “faster Firefox” dummies recommend enabling pipelining.  Pipelining is indeed faster, IF AND ONLY IF, the server supports it.  Most don’t have it enabled yet because no one really understands just what that does to server and network load if a site really gets hit with some major traffic, so they aren’t sized for it, which means that admins who know what they are doing have it turned off.  Set it to true if you want to, but it won’t work on all but a few sites.

If the information you are reading tells you to set your network.http.pipelining.maxrequests to anything higher than 8, then you automatically know that they do not know what they are talking about and are just repeating what they heard somewhere else, or drawing false conclusions based on their limited knowledge.  The valid values for pipelining.maxrequests is from 1 to 8.  The program does not recognize higher values and just treats them as an 8.

So, someone who says to set it to 32 or 64, or even 12, just doesn’t know what the heck they are doing.  Stop reading immediately, and hit the back button or close the tab, you have ran into a charlatan.  Find a more reliable source.

Conclusion

The Firefox developers make a conscious choice between net-etiquette or netiquette and performance.  You can see the debates about what the default settings should be at the Mozilla site.  They may not have set them at maximum to avoid Internet community backlash, but they didn’t exactly s
et them at “slow” either. 

Small increases to these values may result in a little more performance but probably not enough for you to notice unless you are working on a very fast connection with a LOT of tabs running at once.  Even then, it might not get you anywhere since your operating system, your router, and your broadband provider all have various limits on the number and types of connections you can make too.