Advanced: Connection

network.http.keep-alive (Boolean). Setting this to true enables the use of persistent connections. This can provide more efficient connections with legacy servers as it streamlines the process, e.g. fewer TCP connections/packets and pipelining support. In the event of problems arising with legacy servers set this to false. HTTP/1.1 supports persistent connections by default.

network.http.max-persistent-connections-per-server (Integer). The value entered here determines that maximum number of persistent connections to a server, with valid values being 1 - 255, the default being 2 as recommended in the HTTP/1.1 specification and it is recommended to not set this beyond 10 if you do intend to raise the value.

network.http.proxy.keep-alive (Boolean). Setting this to true enables the use of persistent connections over proxy servers. This can provide more efficient connections with legacy servers as it streamlines the process, e.g. fewer TCP connections/packets and pipelining support. In the event of problems arising with legacy servers set this to false. HTTP/1.1 supports persistent connections by default.

network.http.max-persistent-connections-per-proxy (Integer). The value entered here determines that maximum number of persistent connections to a proxy server, with valid values being 1 - 255, the default being 4 as recommended in the HTTP/1.1 specification.

network.http.pipelining (Boolean). HTTP/1.1 pipelining is a feature that allows multiple HTTP requests to be issued simultaneously. Without pipelining, HTTP requests are issued sequentially, with each further request not being issued until the previous has been completed. While this may seem like a more optimal approach, it's not without its detractors (Check out the Comments in particular). Firefox also contains an internal listing of servers that don't support pipelining and disables it for those to avoid problems (This isn't necessarily definitive of course). As such, you might find some experimentation worthwhile with this feature rather than just assuming it's always beneficial (As others guides seem to believe). As stated on W3C's Network Performance Effects of HTTP/1.1, CSS1, and PNG;

HTTP/1.1 implemented with pipelining outperformed HTTP/1.0, even when the HTTP/1.0 implementation uses multiple connections in parallel, under all circumstances tested. In terms of packets transmitted, the savings are typically at least a factor of 2, and often much more, for our tests. Elapsed time improvement is less dramatic, but significant.

Set this to true to enable pipelining (recommended), false to disable. Further information can be found at Mozilla.org's Pipelining FAQ.

network.http.proxy.pipelining (Boolean). This feature performs exactly as per the above (true to enable, false to disable), albeit it applies to connections over a proxy. As before, this is a feature you may want to experiment with to determine its benefits, if any.

network.http.pipelining.maxrequests (Integer). This specifies the maximum number of requests in a pipeline, the default being 4. If you've set both network.http.pipelining and network.http.proxy.pipelining to false this option can be ignored. The Pipelining FAQ makes the following point on the matter, pipelining many requests can be costly if the connection closes prematurely because we would have wasted time writing requests to the network, only to have to repeat them on a new connection. Moreover, a longer pipeline can actually cause user-perceived delays if earlier requests take a long time to complete. So while in general it would make sense to set a higher value (With the limit being 8), it may also be something you should experiment with to determine an optimal value.

network.http.max-connections (Integer). The value entered here specifies the maximum number of HTTP connections Firefox can make simultaneously, the default being 24, with valid values being 1 - 65535. On high bandwidth connections increasing this value can prove effective in reducing the amount of time required to download multiple pages, e.g. If you open multiple tabs at once/in short succession, as it allows Firefox to create more connections. That said, setting this too high can have adverse affects also (Assuming you actually were in a scenario where a large amount of connections were attempted). As such, a decent maximum value for broadband users would be 32.

network.http.max-connections-per-server (Integer). The value entered here specifies the maximum number of simultaneous connections to a server, the default being 8, with valid values being 1 - 255. Increasing this value can improve the loading times of certain sites (Or if multiple pages of a site are loaded simultaneously) as more data can be fetched at once. This is of most potential benefit to those with broadband connections, who will have the bandwidth to take advantage of this. A decent maximum to set this to would be 12. Bear in mind however that the more connections you are tying up, the less that will be available to others wishing to connect to the same server - so don't set this excessively high just because you can.

network.prefetch-next (Boolean). Link Prefetching is a browser mechanism, which utilizes browser idle time to download or prefetch documents that the user might visit in the near future. This is (somewhat understandably) a cause of concern for some, who aren't happy with their browser downloading content from sites which they may not even view anyway. Despite what you may have read elsewhere, there's no need to get too hysterical about this. The most notable site which uses it is Google and where it does (As not all searches do) it only uses it for the top search result, e.g. searching for Firefox yielded Firefox - Rediscover the web as the top result, and that's only 1 to use the rel="prefetch" tag for prefetching on that page. Prefetching occurs during Firefox idle time, so it doesn't detract from browsing speed either. Further details are available Mozilla.org's Link Prefetching FAQ. Set this to true to enable link prefetching for potentially faster loading times of prefetched sites, while if you're more privacy conscious set this to false instead to ensure only content for sites you intend to view is ever downloaded.

network.http.redirection-limit (Integer). The value entered here specifies the maximum number of redirects that can be attempted consecutively, e.g. after replying in a forum you may be redirected to your response. As noted in Bug 153888 the default value has been increased from 10 to 20 (on account of nytimes.com). While you may prefer to decrease this value to avoid exploitation by certain sites, it may be necessary to increase the value in order for some to work (If this is the case an error page stating Redirection limit for this URL exceeded will appear).

network.http.sendRefererHeader (Integer). The value entered here controls the transmission of the Referer HTTP header. This Referer header states the URL from which the browser was referred, e.g. if you click a link in this guide to another website, then TechSpot.com would be stated as the referrer, etc. This can be useful for sites as they can determine where traffic generates from, e.g. Google. Where no URL exists as the referral source, e.g. typing in the address, none is sent. 3 options are available.

0. This disables the sending of the Referer header, which yields a minimal bandwidth saving. This is perhaps more so useful if you're privacy conscious and simply don't want it to be known where you were linked from.

1. This specifies that the Referer header is only sent for clicked hyperlinks.

2. This specifies that the Referer header is sent for clicked hyperlinks and images.

network.http.sendSecureXSiteReferrer (Boolean). This setting controls the transmission of the Referer HTTP header between secure sites. It'd be recommended to set this to true as many secure sites will not function without the Referer header present, as part of a security check (As discussed in Bug 141641), e.g. some sites use a third party company for processing credit card transactions and may fail without the header. It shouldn't be necessary to set this to false.