optimization tips for Firefox

[file cabinet]

Most of them don't seem to apply to Firefox 1.0PR
http://forums.mozillazine.org/viewtopic.php?t=53650

Type `about:config` in your address bar then press enter.

Set the following to true(double-click on the variable):

network.http.pipelining
network.http.proxy.pipelining

Set this to 8(double-click and input 8):

network.http.pipelining.maxrequests


people who have a lot of RAM might be interested in doing this one:

browser.cache.memory.capacity
* Description: amount of memory assigned to memory cache.
* Type: integer
* Unit: kilobytes
* Default: 4096 in older builds, dynamically assigned depending on total amount of memory in newer builds (?).
* Recommendation: set this to a high fixed value if you have enough RAM to noticeably improve back/forward button performance while going many steps back/forward (?)



There is also this if you're using .9 still (not sure if it applies to 1.0PR since he said the stuff he posted might be in the .9.x trunk which may have made its way to 1.0.x .. so.. yeah.
http://www.mrtech.com/cgi-local/msgboard/ikonboard.cgi?act=ST&f=11&t=87

// This will allow Firefox to maintain it GUI memory so that the browser window
// will snap right back after being minimized. This is fairly new and will be available
// in the very near future, might be in the 0.9.x builds, but it works in current Trunk/Brand builds

[Sam172]

and what, may I ask - do would these do in Firefox. Just the usual speeding up of webpage loading I assume?

[file cabinet]

From the Mozillazine thread I linked to:

network.http.pipelining
* Description: enable pipelining for non-proxy connections.
* Type: boolean
* Default: false
* Additional Info: might still lead to problems with servers that don't support pipelining correctly and that are not on the internal blacklist.
* Recommendation: true

network.http.proxy.pipelining
* Description: enable pipelining over a proxy.
* Type: boolean
* Default: false
* Additional Info: see network.http.pipelining.
* Recommendation: true


network.http.pipelining.maxrequests
* Description: maximum number of consecutive requests in one pipeline.
* Type: integer
* Limit: 8
* Default: 4
* Additional Info: nsHTTP.h. Optimal value depends on connection bandwidth/latency.
* Recommendation: 8. While it doesn't hurt to set it to 100 like in other tweak examples, it will have no effect whatsoever because of the mentioned limit.

[Sam172]

and what, may I ask - do would these do in Firefox in laymans terms ;P

You have to deal with the technologically inept proletariats now ^_^

[file cabinet]

Essentially it will speed up page loads or something..

Points of references:

From the Mozilla FAQ:
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

What is HTTP pipelining?

Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.

HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.

Pipelining can also dramatically reduce the number of TCP/IP packets. With a typical MSS (maximum segment size) of 512 bytes, it is possible to pack several HTTP requests into one TCP/IP packet. Reducing the number of packets required to load a page benefits the internet as a whole, as fewer packets naturally reduces the burden on IP routers and networks.

HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests. This obviously has the potential to introduce a new category of evangelism bugs, since no other popular web browsers implement pipelining.


When should we pipeline requests?

Only idempotent requests can be pipelined, such as GET and HEAD requests. POST and PUT requests should not be pipelined. We also should not pipeline requests on a new connection, since it has not yet been determined if the origin server (or proxy) supports HTTP/1.1. Hence, pipelining can only be done when reusing an existing keep-alive connection.

How many requests should be pipelined?

Well, 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. The HTTP/1.1 spec does not provide any guidelines on the ideal number of requests to pipeline. It does, however, suggest a limit of no more than 2 keep-alive connections per server. Clearly, it depends on the application. A web browser probably doesn't want a very long pipeline for the reasons mentioned above. 2 may be an appropriate value, but this remains to be tested.


What happens if a request is canceled?

If a request is canceled, does this mean that the entire pipeline is canceled? Or, does it mean that the response for the canceled request should simply be discarded, so as not to be forced to repeat the other requests belonging to the pipeline? The answer depends on several factors, including the size of the portion of the response for the canceled request that has not been received. A naive approach may be to simply cancel the pipeline and re-issue all requests. This can only be done because the requests are idempotent. This naive approach may also make good sense since the requests being pipelined likely belong to the same load group (page) being canceled.


What happens if a connection fails?

If a connection fails or is dropped by the server partway into downloading a pipelined response, the web browser must be capable of restarting the lost requests. This case could be naively handled equivalently to the cancelation case discussed above.

http://forums.mozillazine.org/viewtopic.php?t=34645
from page 2 of that thread

IE simply cannot pipeline, which is why it's page-load performance is often slower than FB (unless FB uses a misconfigured network settings or a dodgy server).

PROBLEMS: For servers that are not properly HTTP/1.1 compliant, pipelining can sometimes slow down network performance, as they mishandle the asynchronous requests (maybe on that MSN site?). Opera have largely solved this by using heuristics to dynamically match pipeling parameters to server types, but to be honest the number of servers that get pipelining badly wrong are few and far between.

Some people that criticise pipelining even for compliant servers often assume that it is inefficient - but it can only ever be more inefficient IF there is only one persistent connection ever used (and an item that has 'clogged' that connection), and this is never the case.

There is also this discussion which occurred on a mailing list:
http://sourceforge.net/tracker/index.php?func=detail&aid=668966&group_id=11118&atid=361118

It sounds like it is the way to go.. but... ergh.. I don't know. I think setting maxrequests to 4 might be more recommended then setting it to 8.

and.. not totally sure how pipelining affects dialup users.

[Sam172]

Okay, i'll see if it makes any difference :)

If not....well it can't do any harm

[jimkopelli]

Cool.
Applied... hope the university firewall doesn't give me crap...

Edit: WOOO! Faster already. Thankee muchly.

[Zero Angel]

Thx for the tips!