Forum Moderators: open
Disclaimer: This is not, and is not intended to be, a FireFox vs. Opera thread. The following are simply some basic guidelines for increasing FireFox performance, and is not meant to be a comparison of any kind! ;)
I've heard it said, here and other places, that Opera is the fastest browser available. It is fast - there's no denying that - but there are ways to make FireFox render pages every bit as quickly, with just a few easy "tweaks." I had thought these adjustments were pretty well-known, but it's beginning to seem as though they may not be. So I thought it was worthwhile to bring these "hidden settings" more into the light.
To get started, type "about:config" in your FireFox address bar. The settings you're looking for are:
1.) network.http.pipelining
2.) network.http.pipelining.firstrequest
3.) network.http.pipelining.maxrequests
4.) network.http.proxy.pipelining
5.) nglayout.ititialpaint.delay
Set #1, #2, and #4 to "true". Set #3 to a high number, like 32. Set #5 to 0.
Enabling the pipelining features allows the browser to make multiple requests to the server at the same time. The "maxrequests" is the maximum number of requests it will send at once. I've heard that 8 is the most it will send at once, but setting it higher won't hurt, just in case. The initialpaint.delay is the length of time (in milliseconds) after the server response before the browser begins to paint the page.
Adjusting those settings will help pages render much faster in FireFox. In fact, my own observations have been that, tweaked in this manner, FireFox will render faster than Opera (and yes, I realize that others may experience different results).
The FireFox Tuning thread [forums.mozillazine.org] over at Mozillazine has more information for different connection speeds, etc.
[edited by: encyclo at 2:27 am (utc) on July 13, 2006]
1.) network.http.pipelining
2.) network.http.pipelining.firstrequest
3.) network.http.pipelining.maxrequests
4.) network.http.proxy.pipelining
5.) nglayout.ititialpaint.delay
So I changed #1, #3, #4 but didn't see the other two.
Pages load surprisingly faster. I think when people talk about how fast Firefox is, they must mean with these tweaks in place.
Thanks for the tip!
nglayout.initialpaint.delay is no longer included as a default preference in about:config. It still works, however, if you create it yourself. To create this setting:
about:config nglayout.initialpaint.delay As mentioned later on in the thread, setting
network.http.sendRefererHeader to 0 can help quite a lot as well, though it can cause problems in very rare instances.
One question, if you add the pipeline.firstrequest, will it help or it only helps for install that have it there?
Turning off referer is perfectly safe. I have yet to find a site that has issues with it. Occasionally there is incorrect referer blocking on images, and I let the site owner know they have to allow for blank referers since alot of personal firewalls block them anyway. By the way you have to turn off https (ssl) referer's under a seperate setting (again, I've yet to find problems with this).
For those that want the cutting edge in Firefox speed, also try a MOOX build [moox.ws] which is especially compiled for certain CPU's. There is a noticable speed boost. Basically you unzip the moox files right over your firefox folder, while all your settings are kept intact. If you don't like it, just install the regular build back over it.
For those that want to see just how long its taking the pages and objects to download, try this nifty obscure "lori" extension [lori.mozdev.org] that adds page timing like opera does to the status bar.
It's a marketing error on their part as very few users discover these features.
One question, if you add the pipeline.firstrequest, will it help or it only helps for install that have it there?
To tell the truth, I don't think first requests even can be pipelined, though when it was still a preference I always set it to "true" just in case. I never noticed any performance boost from this one, but included it in the initial post in case it could be useful on some systems or something. Frankly, I doubt adding the preference will do anything for you.
I'll add my vote to that of amznVibe for the "lori" extension. Strangely enough I just installed it yesterday; very nice functionality.
the only major problem I have with it is downloading big files and the way it completely slows everything else down. Anyone else have this same problem? Any tweaks?
Install the "download with" and/or "launchy" extensions and use getright as the downloader instead. Vasty superior. I am sure some of the other downloading agents can be used as well and some of them are free.
Also noteworthy is the "Disable Targets For Downloads" extension.
ps. After using "Lori" for awhile it is kind of too beta to use. Takes up too much status bar and can't be toggled. I am now trying Extended Statusbar 1.0 [extensionsmirror.nl] instead (update apparently it can't be toggled either - looks like I'll have to hack some features in).
Oh and I just can't resist since I was so happy to find it, even thought it's not a performance enhancement - since they took away the stylesheet changer from the preview to final release, this person has made a stylesheet switcher extension [olab.free.fr]
1: On PHP or CGI "generated" pages, it has a habit of breaking down from time to time on the tables. Tables either end up becoming 100% in width or height, which can really mess with the layout of a page. It's not a "permanent" error and can usually be fixed by refreshing the page.
2. Similar problem with CSS based layouts. For some reason, it gets relative and absolute positions messed up, and you can end up with different elements rendering "on top" of one another, most often with footer elements. The most extreme example I've seen of this is having three text blocks render on top of each other. Again, this is most likely to occur with PHP or CGI/Perl generated pages, and can usually be fixed by refreshing the page.
3. Weird link behaviour: From time to time, when you click on a link, instead of following the link, the page just repositions itself on the screen, or does nothing. A second click on the link will take you through to the apropriate page. This is most likely to occur on javascript buttons and form submit buttons, and is more likely in CGI/Perl generated pages than in PHP generated pages.
These are occasional errors, and I suspect somewhat dependant on how the pages are encoded. PHP generated pages seem to create the errors most often, say about 1 in 100 rendered pages. (And no, I haven't run any hard statistcal tests, 1 in 100 is just a guess)
Also, certain servers are not configure to handle pipelining. If the page is being served from an IIS server, fuggetaboutit.
Also, certain servers are not configure to handle pipelining. If the page is being served from an IIS server, fuggetaboutit.
Actually, I've found that IIS handles pipelining just fine, most of the time. There are a few sites I've seen where it doesn't work well, but on the whole it seems okay to me.
Probably other similar episodes would occur as well.
Doesn't this go against some http standard or other?
No, because HTTP standard limits number of concurrent connections to a web server to a maximum of 2, where as pipelining uses same connection to request more than one object at the same time, and then receive a bunch of responses rather than request and receive for each of those objects separately.
For those complaining that these make non-standard requests to the server, see here:
[w3.org...]
Last but not least, read about how IE "cheats" [grotto11.com] to make itself seem faster, especially for first requests.
ps. I would not tamper with initial paint delay in newer Firefox builds, it's not needed and can cause a second rendering of the page to be required.