Tall Mike

Stop memory hogging

The default way the Windows version of Firefox consumes memory can be alarming if you don’t know what’s really going on. People routinely report a memory “footprint” of 75MB to 100MB or more with only a few windows or tabs open, and they assume a memory leak is to blame. While earlier versions of Firefox did have memory leak bugs, they’re not the reason for this kind of memory consumption in Firefox 2.x.

Here’s what’s happening: Firefox caches recently used objects — Web pages, images — in memory so that they can be re-rendered on-screen quickly, which drives up memory usage. The following tweaks can make Firefox stake out memory less aggressively. (Note, however, that lightening the memory load might make your pages load a bit more slowly than you’re used to.)

Reduce graphics caching
When the Boolean preference browser.cache.memory.enable is enabled (the default), Firefox keeps copies of all graphical elements from the current browsing session in memory for faster rendering. You can set this to false to free up more memory, but pages in your history will reload less quickly when you revisit them.

Another option: Set the value to true and create a new integer preference called browser.cache.memory.capacity. Then specify, in kilobytes, how much memory to set aside for graphics caching. That way you get some of the speed benefits that graphics caching provides without taking a huge memory hit. If you use -1 as the memory value, Firefox will size the memory cache based on how much physical RAM is present.

Reduce Web page caching
Firefox caches several recently visited Web pages in memory so they don’t have to be regenerated when you press Back or Forward. The integer setting browser.sessionhistory.max_total_viewers determines how many individual Web pages to store in the back/forward cache; each page takes about 4MB (or 4,000KB) of RAM.

By default, however, this value is set to -1, which determines how many pages to cache from the amount of available physical memory; the maximum number of pages stored when you use -1 is 8. Set this value to 0 to disable page caching entirely. That will save some memory, but will also cause Back and Forward navigation to slow down a bit.

Note that this caching is not the same as browser.cache.memory.enable: That setting is for rendering elements on pages like graphics and buttons, and the contents of https-encoded pages, while this setting is for caching the text content of Web pages that have already been rendered or “tokenized.”

Swap out to disk memory when minimized (Windows only)
A little-known feature in Firefox allows the Windows memory manager to swap out some of Firefox’s physical memory space to disk when Firefox is minimized but not closed. This allows other programs to use the physical memory that Firefox was previously monopolizing.

By default, this feature is turned off, for two reasons: 1) PC memory is generally more plentiful than it used to be, so it makes sense to use it if it’s available, and 2) swapping Firefox’s memory out to disk will slow the program down when it’s restored.

That said, if you run Firefox side by side with other memory-hungry applications, it might help keep them from competing with each other. To enable this feature, create a new Boolean preference called config.trim_on_minimize and set its value to true.

Hack network connections

The very first batch of Firefox hacks I learned about was how to override its network defaults. Some of Firefox’s out-of-the-box settings for how it deals with network connections are fairly conservative, probably because Firefox has no way of knowing what kind of network it’s using (dial-up vs. broadband, etc.). If you have a network that readily supports multiple simultaneous connections, you can make a number of changes to Firefox to take advantage of that.

But proceed with caution. If Firefox’s network settings are set too aggressively, they can lead you to being blacklisted for a short time by a given remote server. And you should certainly get permission from the IT department before attempting this kind of hack in a corporate environment. Regardless, moderation is the key. For the most part, I find that setting the network settings to absurdly high numbers does not accomplish much of anything; it helps to ramp them up a bit, but generally not much more than that.

Maximize connections to multiple servers
The integer preference network.http.max-connections controls how many simultaneous network connections Firefox will make at any one time to any number of Web servers. One typical way this pays off is if you have Firefox set to load multiple home pages in different tabs at once, or if you access pages that aggregate contents from several different servers (for instance, multiple advertising systems).

By default, this is set to 24, which should work well for most network connections, but you can raise it to 32 and see if that has any effect. (I’ve seen people raise this as high as 64, but anything above 32 doesn’t seem to provide much discernible payoff.)

Maximize connections to the same server
The integer preference network.http.max-connections-per-server controls how many separate connections Firefox makes to the same server, which allows multiple elements in a page to be downloaded in parallel. Normally, this is set to 8, but some people choose to set it as high as 16.

Note, however, that some Web servers will block you if you try to establish more than 8 inbound connections, typically as a bandwidth-protection or antileeching measure — this is the kind of behavior also exhibited by download managers that try to use as many “slots” as possible to speed things up, and many server admins hate that sort of thing. Also, if you’re on a connection that’s not fast to begin with (e.g., slow ISDN or dial-up), changing this setting will have no discernible effect, and may in fact slow things down.

Bump up persistent connections per server
Firefox keeps persistent connections to a server “alive” to improve performance: Instead of simply sending the results of one request and then closing, they’re held open so that multiple requests can pass back and forth. This means a little less network traffic overall, since a connection to a given server has to be set up only once, instead of once for each separate piece of content; it also means successive connections to the same server go through faster.

The integer preference network.http.max-persistent-connections-per-server controls the number of persistent connections allowed per server. By default, this is set to 2, although some servers will honor a higher number of persistent connections (for instance, if there’s a lot of content from their site that loads in parallel, like images or the contents of frames). You probably only want to go as high as 8 with this; more than that may cause a server to temporarily blacklist your IP address depending on how it’s configured. (If you’re going through a proxy defined by Firefox, use network.http.max-persistent-connections-per-proxy instead of this setting.)

Reduce the interval between persistent connections
If you’ve already used up all the persistent server connections described in the above setting and Firefox needs to make more connections, the integer setting network.http.request.max-start-delay governs how long to wait before attempting to open new connections. This helps if Firefox’s persistent-connection limit has been used up by a number of long downloads, and the browser needs to queue a shorter download on top of that.

Most people set this to 0 (in seconds), with the default being 10. Note that this does not override connection limits imposed by remote hosts, so its usefulness is limited by the whim of the server you’re connecting to.

Turn on pipelining
The Boolean preference network.http.pipelining enables an experimental acceleration technique called “pipelining,” which speeds up the loading of most Web pages. A browser normally waits for some acknowledgment of a given request from a server before attempting to send another one to that server; pipelining sends multiple requests at once without waiting for responses one at a time.

If you turn this on (that is, set its value to true), also be sure to create or edit the integer preference network.http.pipelining.maxrequests, which controls the maximum number of requests that can be pipelined at once. 16 should do it; some people go as high as 128 but there’s not much evidence it’ll help. (If you use a proxy, set network.http.proxy.pipelining to true as well.)

Note that not every Web server honors pipelining requests correctly, which is why this feature is turned off by default and still considered experimental. Some sites may behave strangely if you submit pipelined requests.