Last week we blogged Firefox's cool about:config feature, that let's you view and edit the browser's configuration settings right in the browser window.
What we didn't mention is how Firefox stores these configuration changes. The way it does so is in a JavaScript file called prefs.js which (on Win2k) you'll find in: [AppData]\Mozilla\Firefox\Profiles\xxx.default\ (where xxx is a random string).
This is cool because, if you decide you don't like the changes you made when you were experimenting with the about:config URL, just delete the prefs.js file, and Firefox will recreate it with the default settings.
But don't get the idea that you should edit this file directly. If you want to do that, create another file (in the same directory) called user.js, and make your direct edits there. Anything you put in user.js will override what is in prefs.js (and therefore will show up when you run the about:config), and will actually get written to prefs.js when the browser closes.
While we're on the subject, here is an example of an interesting set of tweaks you can try that should speed up page load times:
user_pref("network.http.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 8);
That's what they look like in user.js. If you are using about:config, just find the two keys referenced in the quotation marks and doubleclick or rightclick-Modify to set their values accordingly. 8 is something of an arbitrary number for the maxrequests -- feel free to try something higher if you wish.
What are you doing by making these changes? You are trying out an HTTP feature called pipelining, which you can read Mozilla's take on in this Pipelining FAQ.
Pipelining is one of several connection management techniques (others are persistent connections, parallel connections and multiplexed connections) intended to speed up the delays associated with early HTTP's primitive use of TCP connections.
Among other things, those early HTTP connections were singular and sequential. Most modern browsers use parallel connections (opening multiple concurrent TCP connections -- usually 2 to 4) to get things done faster. Pipelining takes this a step farther by issuing multiple requests on a single socket, rather than sending them one at a time and waiting for the responses. As the Mozilla folks explain, this can really speed up page loads on high-latency connections, and also cut down on packet proliferation.
Naturally, there is a downside. HTTP 1.1 servers shouldn't have any problem with pipelined requests (even if they can't service them with pipelined responses). But, of course, in the real world, your mileage may vary. Or, as Darin Fisher gently puts it in the Mozilla pipelining FAQ: "This obviously has the potential to introduce a new category of evangelism bugs."
Happy tweaking!