FireFox Users! Wonderful Tweak.

[abudhu]

Yes, FireFox may be fast, but it can go much faster.

Here's a little tweak to get that preformance, and it is very noticable.

1. Type "about:config" into the address bar (no spaces and Minus the qoutes) and hit Return. Scroll down and look for the following entries:

--network.http.pipelining
--network.http.proxy.pipelining
--network.http.pipelining.maxrequests

Normally the browser will make one request at a time to a Web page. When you enable pipelining, the browser will make several at once, which really speeds up page loading.

2. Alter the entries as follows:
Set "network.http.pipelining" to "true"
Set "network.http.proxy.pipelining" to "true"
(Just double click the value to change it)
Set "network.http.pipelining.maxrequests" to some number like 30. (This tells the browser to make 30 requests at once.)

3. Lastly, right-click anywhere and select New-> Integer. Name it "nglayout.initialpaint.delay" (minus the quotes) and set its value to "0" (again, minus the quotes). This value is the amount of time the browser waits before acting on received information.

Things go very fast now, and its somewhat freaky.

Enjoy.

----
Update 2:
I have just found this:
The guy who does this hasn't compiled the 1.02 version yet, but if you want to squeeze more out of it try these. (I personally HAVEN'T but I hear they actually Help a LOT!)

Basically they are builds of firefox that are optimized for your particular processor by using the given advance instruction sets like SSE 2

http://www.moox.ws/tech/mozilla/firefox.htm

To find out which one to download for your processor go here:

http://www.moox.ws/tech/mozilla/mdefs.htm

[dparm]

That's amazing.

[reuter]

Doesn't seem to make a difference on my machine, then again I have a disgustingly slow "high speed" connection here at palm shadows.

[dparm]

At home I think pages might render a bit faster. Even if it's total placebo effect, it can't be hurting anything.

[dparm]

I've installed the M3-build. I don't think there's any big differences.

[abudhu]

Thanks for letting me know if those builds work or not. I didn't think they would. After all how much improvement can a web-browser get from using a more advance instruction set? I mean its not like it needs to use it in the first place. O'well. At least things go speedy now. I did it on PC 2 in MLL and left the other two. If you want you non-believers can go see.

[dparm]

Interestingly, those M1/2/3 builds already had those pipelining settings enabled.

Adam seemed to think that on image-intensive sites (as in VERY intensive), there might be an improvement.

[abudhu]

Would make sense, seeing as text wouldnt need to use it much. Its still fun. There is an article on it called "Firefox on Steroids" :)

[dparm]

The problem is that we have no reference points or benchmarking to do a comparison. There is always that placebo-effect where you THINK it's faster when it actually isn't. This is common in the world of car modification.

[abudhu]

Alas you are correct. But logically it would make sense to be faster as you are enabling more pipelines to be used to send and recieve information. That and the simple fact that you are sending more request to a page, which the page then has to act upon by sending data back...well, whatever. Haha, its doing something cause websites do "seem" to load faster.

[dparm]

Truth be told though, it's still hard to test. Too many factors....you pass through so many servers that even a slowdown in one totally skews results. I'll leave the options enabled, because they're certainly not going to hurt anything. Thanks for the tips.

[dparm]

I stumbled across this on the web today:

Setting the initial paint delay at 0, may get you some content on the screen faster, but it's worth
noting that it will dramatically slow down the time it takes the entire page to display. Here's
what's going on. Gecko, Firefox's rendering engine, is trying to optimize between the cost of
waiting for a bit more data versus doing more painting and reflows as new data comes in.
Waiting a bit longer before it starts painting the page gives Gecko a chance to receive more
content before chewing up CPU cycles to render and reflow the document. If you drop this value
down to 0 or near 0, that means you'll see the page start displaying a bit earlier, but not having
received much data in that short interval, you'll have a lot more paint and reflow cycles to
complete rendering of the page.
So if you don’t care about overall rendering time then yes, setting this to 0 can result in some content
being displayed immediately (giving the perception of improved speed). If however, you’d prefer
improved overall page rendering time then you’ll want to adjust this value based on bandwidth available.
Low bandwidth (dial-up) connections can benefit noticeably by increasing this value, with 750/1000 (The
former being what I use currently) proving good. High bandwidth connections should be just fine at the
default (250) – besides, is ¼ second really that noticeable a delay anyway?