Hacking Firefox: Speed Up Your Browser

[Prodigy]

Hack it, tweak it, and make it scream down the information highway. This chapter covers several of the much-touted hacks that you will find on the Internet, as well as some other less popular but very useful hacks. You will get the skinny on the what, how, and why of them. More important, you'll see how to customize them to fit your current setup and situation. The primary method of hacking for this section is adjusting key hidden preferences.

Deviating from RFC Specs

Warning: The following hacks may make your browser download faster than your eyes can handle. Okay, kidding aside, the following hacks have generated a lot of controversy because they break away from industry standards. Based on RFC specification numbers 2068, 2616, and others, the defined and recommended maximum number of simultaneous connections using HTTP/1.0 Internet protocol is four. For HTTP/1.1, the defined and recommended number is two.

These hacks bump this number up. They also increase the number of connections per server. If you are using dial-up access, these hacks will be marginally beneficial; they're really geared more for DSL, cable, and corporate networks; customizing these settings is covered in the "Bandwidth and Processor-Specific Optimizations" section later in this chapter.

Note: RFC stands for Request for Comment. These specifications are published to create technology standards for communication protocols and other application implementations.

These RFC standards are in place to balance a web server's performance under heavy traffic by providing a certain level of quality of service for all users. However, as many users have realized, leeching and improved download performance are necessary when cruising through the net or downloading large files. This, coupled with the fact that the RFC was originally published in 1997, really begs for some radical changes to be taken. So you deal with the problem directly by increasing the number of concurrent connections made to a server for a page request.

Note: A request is any communication from Firefox to a web server. Such requests include the call to download the page and each element that the page refers to (for example, graphics, JavaScript files, Cascading Style Sheets, and so on).

[Prodigy]

Hacking Simultaneous Connections

To edit these settings, you can use the built-in about:config utility, add the entries to the bottom of your prefs.js, or add them to the user.js file. My preference is the latter because it makes it easier to update and manage all my tweaks and hacks without having to weed through all the other settings or screens. Figure 1-1 displays the defaults for the four settings that we hack in this section.

Figure 1-1

While performance is genuinely good for single-page browsing with default settings, loading multiple pages or loading pages with tons of supporting content, such as thumbnail images, may take some time to queue up and download. Moreover, if you have created a multipage bookmark or homepage or, like me, have JavaScript-triggered buttons to blast open 4 to 12 sites in tabs simultaneously, you know the importance of downloading all pages and page elements as fast as possible.

Here is the code you can add to the user.js file:

user_pref("network.http.max-connections", 96);
user_pref("network.http.max-connections-per-server", 32);
user_pref("network.http.max-persistent-connections-per-proxy", 24);
user_pref("network.http.max-persistent-connections-per-server", 12);

Tip: The faint of heart can modify these settings with the Tweak Network Settings extension. The network.http.max-connections hack increases the number of total connections that the browser will make at one time. The network.http.max-connections-per-server hack breaks this down to the maximum number of connections per server.

Tip: For additional networking preferences, default values, and notes, visit this page at mozilla.org. Persistent connections are implemented with HTTP web protocols and allow fewer TCP/IP calls to be initiated to a web server when making multiple requests. This is also known as keep-alive, because it reuses the active connection to communicate additional requests. The network.http.max-persistent-connections settings bump the number of simultaneous requests that can be made, in effect forcing the download of as many of the page elements at the same time as possible.

Note: For more information on HTTP/1.1 Persistent Connections standards, visit this W3C page. For HTTP/1.1 performance information, visit this W3C page.

[Prodigy]

Pipelining Hacking

A key feature, called pipelining, was incorporated into the HTPP 1.1 standard. While this feature does give a boost to communication between the browser and server, there are some web servers and proxy servers that may not fully support its use. Pipelining takes several requests and submits them to the server back to back without waiting for a response, with the expectation of receiving the requested objects back in the order submitted. The benefit is gained in the fact that there is less chatter and delay between the browser and server, because the browser is not waiting for a response from the server for the first request before making the next, and so on.

// Enable Improve Pipelining
user_pref("network.http.pipelining", true);
user_pref("network.http.proxy.pipelining", true);
user_pref("network.http.pipelining.firstrequest", true);
user_pref("network.http.pipelining.maxrequests", 8);

Note: network.http.pipelining.maxrequests is capped at eight, and setting this value to anything higher will be ignored. The default is four. Though it is not recommended, I have suffered no ill effects from using network.http.pipelining.firstrequest. It is not recommended, because Firefox has yet to determine if the server can handle pipelined requests.

Tip: For more information on HTTP pipelining, visit this page at Mozilla.

[Prodigy]

Other Hacks

The following tweaks increase the amount of time and number of entries for which the browser remembers the Domain Name Server (DNS) resolution information. DNS servers are the bridge between a website's named address and the TCP/IP address assigned to it. Increasing the DNS expiration and the number of entries reduces the number of times Firefox needs to poll to gather this information.

The FTP idle and keep-alive settings use a default of 300. Lowering these shortens the amount of time that the browser waits before giving up and timing out for FTP connections and keep-alive callbacks.

user_pref("network.dnsCacheExpiration", 86400);  
user_pref("network.dnsCacheEntries", 256);
user_pref("network.ftp.idleConnectionTimeout", 60);
user_pref("network.http.keep-alive.timeout", 30);

Note: These hacks help with browser responsiveness but may have some side effects, including premature timeouts. Use these hacks with this understanding and modify or remove them if you experience any issues with website name resolution, FTP idle connections, and so on.

[Prodigy]

Optimizing Page Rendering

Page rendering is handled by the internal core technology, called NGLayout, or by Mozilla's layout engine. By tweaking the NGLayout paint delay setting, you reduce the amount of time that the browser waits before it begins rendering a page while downloading, which achieves some marvelous visual performance. I like this a lot because it enables me to know exactly what is downloading and to enjoy its rendering in real time without having to wait for all the content to load. This does take its toll on central processing unit (CPU) utilization, but with today's high-end processors and systems, this is less of a factor.

Tip: Using tab browsing usually requires less CPU time and memory. Pages load faster because Firefox does not have to render a whole new window.

[Prodigy]

Hacking Page Rendering

Most of these hacks are scattered all over the Internet, but most take snippets from several key sources, including the Firefox Tuning information posted in the Firefox Features forum on MozillaZine.org forums.

The TweakFactor.com site summarizes these hacks in a nice clean page. However, in my experience, the following tweaks are really the core tweaks that help in rendering and page timing for display:

user_pref("nglayout.initialpaint.delay", 0);
user_pref("content.notify.ontimer", true);
user_pref("content.interrupt.parsing", true);
user_pref("content.notify.interval", 100);
user_pref("content.notify.threshold", 100000);
user_pref("content.notify.backoffcount", 200);
user_pref("content.max.tokenizing.time", 3000000); 
user_pref("content.maxtextrun", 8191);

The nglayout.initialpaint.delay tweak shown in the preceding code modifies the amount of time Firefox waits before it begins rendering a page, where the default is 250 (milliseconds). The rest of the content hacks alter the timing for internal reflow and page generation.

The "content.notify.ontimer" is on by default, but I always like to include it just in case. This turns on the timer-based reflow management used for rendering. Users upgrading from pre-1.0 releases may have this preference disabled; setting it to true should rectify this.

The "content.notify.interval" preference sets the amount of time allowed between reflows and is measured in microseconds, where the default is 250000. Some have balked at setting this to such a low number, but I have yet to suffer from doing so.

The "content.notify.backoffcount" sets the number of reflows to do before waiting for the rest of the page to arrive.

The "content.max.tokenizing.time" was implemented to give the user interface responsiveness while parsing a page. The default for this setting is three times the "content.notify.interval". This is the amount of thread processing time to use before releasing controls to the user interface.

The "content.maxtextrun" preference by default is 8191, but in builds prior to 0.9.5, it was 8192, and the one-digit difference, based on the notes in the Bugzilla posting, made a huge difference in rendering due to buffer thrashing and overallocations. This hack is included just in case you are still on an old build or this setting has not been properly updated. For more information on this fix, visit bugzilla.mozilla.org.

The combination of these hacks should yield a very nice experience when downloading larger pages or pages with complicated table structures.

[Prodigy]

Unblocking Error Dialogs

One annoying feature that really is not a rendering-specific issue is the browser's popping up a modal dialog warning that there is an error while connecting to a site. A typical modal dialog blocks background activity until you respond to its question, usually in the form of an Are-you-sure-you-want-to-exit? type of dialog. What this tweak does is replace a failed URL's modal dialog prompt with an error page.

Having used this hack for a long time now, I have found it to be most useful if you are loading several pages at the same time. In this instance, the error dialog actually holds up the whole browser from downloading other background content. Using this tweak allows the other pages and page elements to load without the lockup.

user_pref("browser.xul.error_pages.enabled", true)

One side-effect of using this hack is that the displayed URL in the location bar is a pointer to the internal XUL page that is used to generate and display the error. To rectify this situation, you can install the Show Failed URL extension, which does as it says: It shows the URL in question in the location bar. This extension can be downloaded from www.pikey.me.uk.

Tip: For more information on why this preference is not enabled by default, visit the Bugzilla site.

[Prodigy]

Disabling Smooth Scrolling

Smooth scrolling may be a nice feature, but I can never tell the difference when it is enabled. However, I have noted a slight performance hit on older computers that have it enabled.

user_pref("general.smoothScroll", false);

My preference is to tweak as much power and performance as possible out of the browser and forgo most of the frills, so this feature ends up getting disabled on my systems.

[Prodigy]

Bandwidth and Processor-Specific Optimizations

When originally learning these connection, rendering, and pipelining hacks for the Mozilla Suite and Firefox, I did my own performance testing. I did this at probably just around the same time other sites had been doing it, but my findings were a little different. My original approach was to bump up each of the settings by some factor, starting with a factor of 10, and then work my way down from there. I monitored the following key issues:

• CPU utilization
• Browser responsiveness
• Failed sites
• Broken images

While in the end they do not share the same factor, my findings were that the max-connections settings worked well at four times their default and the persistent-connections worked well at six times their default. After some testing, 96, 32, 24, and 12 were the magic numbers for me, and so far they've proven to be accepted by many users. Table 1-1 shows the test systems used.

Table 1-1: Test Systems

Based on these system configurations, you can see that the connection hacks suggested work with a wide range of speed and memory amounts. Despite the fact that newer computers can render content much faster, I am amazed by the incredible performance of Firefox using the same settings as older systems. However, you may experience some hiccups and may need to modify these settings. So here are some suggestions.

As mentioned earlier, there are several sites and forums with recommended values and settings based on your computer and connection speed. At just about every one of these cyberplaces, you find a mixed bag of results and recommendations. Because of the many variables that can affect how you connect and how your system performs, I steer clear of recommending all the tweaks mentioned on those sites. Instead, I rely on the settings that I have used successfully and modify those accordingly for my recommendations.

The key to testing is to gauge how your system and connection react based on the changes you make. In keeping with the factor testing methodology, modem users and others can test the suggested tweaks and conduct some initial testing to pinpoint what works best. One page that I use for testing contains a form submit button that is tied to a JavaScript function to blast open four to eight pages at a time, preferably into tabs.

This page helps you gauge how your system and connection handle downloading of multiple pages and graphics. Again, key factors to monitor are broken pages or images, timeouts, and CPU utilization. For example, a modem user on a fast computer may want to try a factor of 1.5 or 2 times the default values for simultaneous connections.

user_pref("network.http.max-connections", 48);
user_pref("network.http.max-connections-per-server", 16);
user_pref("network.http.max-persistent-connections-per-proxy", 8);
user_pref("network.http.max-persistent-connections-per-server", 4);

Additionally, for users on a slow computer, modifying the content rendering should help with CPU utilization:

user_pref("nglayout.initialpaint.delay", 125);
user_pref("content.notify.ontimer", true);
user_pref("content.interrupt.parsing", true);
user_pref("content.notify.interval", 300000);
user_pref("content.notify.threshold", 300000);
user_pref("content.notify.backoffcount", 10);
user_pref("content.max.tokenizing.time", 2000000); 
user_pref("content.maxtextrun", 8191);

There really is no smoking gun when it comes to calculating the best fit for all the PC and connection speed permutations, but playing around with these settings will help you pinpoint what works best for you.

Tip: Visit www.tweakfactor.com for some examples of settings and tweaks based on computer and connection speeds.

To conduct some nonscientific performance testing, take the following steps:

1. Apply the tweaks that fit your system best.
2. Clear the browser's cache.
3. Exit and restart the browser.
4. Make sure you have JavaScript links set to open into tabs.
5. Open the blaster page at http://www.hackingfirefox.com/blaster.html.
6. Select one of the tests provided—four, six, or eight pages.
7. Monitor CPU utilization, page rendering, broken images, and so on.

Additionally, you can test for browser responsiveness by switching tabs while the pages are loading. To further stress-test these settings, try scrolling the foreground page with your mouse wheel while the content is downloading.

Tip: You can add a Clear Cache toolbar button, as well as other useful buttons, by installing the Toolbar Enhancements extension from clav.mozdev.org.

[Prodigy]

Optimizing Disk and Memory Cache

The following hacks are targeted to help you decide where and how much disk and memory to allocate for Firefox to use. While changing these settings may seem mundane and trivial on some systems, they can really make a difference on others. Cache, whether disk or memory, is a local buffering zone that holds a copy of content that has been downloaded and viewed.

Disk Cache is persistent between browsing sessions and stored on the hard drive, which assists the browser in not having to download content each time it is accessed. Memory Cache is session-based—that is, once you close Firefox, the memory cache or local buffer is cleared.

Note: If Firefox happens to crash, the entire disk cache is cleared out automatically.

Changing Disk Cache Location

Modifying the location of the disk cache can have a side benefit of freeing up space without having to repartition or remap directories at the operating-system level. The best benefit, though, comes if you happen to have two physical hard drives installed. In my experience, moving a system's paging file and Firefox's disk cache to a secondary drive helps performance by balancing disk reads and writes across both drives.

Tip: Before applying this hack, clear your cache directory.

By default, newer computers come with one hard drive and one partition. This, coupled with the fact that newer hard drives are very fast, means that this hack is not a top priority for very fast computers. If you are on an older system with a second hard drive or would like to repoint the disk cache to a RAM drive, this tweak is for you. Here's how to modify this setting:

// Sample for Windows Users
user_pref("browser.cache.disk.parent_directory", "d:\\temp\\");

 // Sample for Unix/Linux/Mac Users
user_pref("browser.cache.disk.parent_directory", "/tmp");

Note: A subdirectory of cache is created in the directory you choose.

If the path you have chosen does not exist, Firefox creates it the next time you open it up. Windows users should make sure that this value has double slashes, as displayed in the preceding code; not including these causes internal parsing errors and possible preference-file corruption. The only exception to this rule is if you are adding this value via the about:config screen, in which case, you should not use the double slashes—single slashes will automatically get converted to double.