Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: incrediBILL
It's been awhile since I first posted a few simple tips on how to speed up Firefox performance. Some of the information is outdated, so I thought a recap might be a good idea.
All of these tips can be implemented by anyone who knows how to use their keyboard and mouse. No advanced knowledge is required. With that said, however, the adjustments we'll be looking at can have adverse effects when visiting certain websites. I'll note possible concerns with each tip so everyone can decide for themselves if that particular tip is for them. Each of these will help speed up Firefox, independently of the others, so don't feel like you have to use all of them if you don't want to.
To start your tweaking, type
in your Firefox location bar. This will bring up a list of hundreds of preference settings. All the changes we'll be making can be done here. Use the filter bar just above the list of preferences to "drill down" to the preferences you need. There are Firefox extensions [webmasterworld.com] that will allow you to change most of the settings we'll be talking about in more of a GUI environment, but I prefer to do it in
since installing extensions can tend to have a hit on Firefox performance.
So on to the actual preferences you'll need to set. To change a preference, double-click it and enter the new value.
- This setting controls whether or not Firefox will send a "referer header" for the pages and files it requests. Sending the referer header takes time, actually more time than you might think. Turning it off can improve your browsing speed quite a bit. The default for this one is '2', which means Firefox will send the referer header for page requests AND for images. Set this preference to '1' to send a referer header for page requests only (faster), or to '0' to not send referer headers at all (fastest).
- As the name implies, this setting (supposedly) controls whether or not Firefox pipelines the first request for a pageview. I don't see what real-world difference this setting can make, but I always set it to TRUE anyway, just in case. The default is FALSE.
- This is the maximum number of concurrent requests Firefox is allowed to make. I used to recommend setting this to a high value, around 32 or so. I have since found out that this can have serious implications for web servers that may get overloaded trying to respond to so many requests all at the same time. I don't have any statistics on what a good upper limit for this setting would be, but I have mine set to 16 which seems to work well (possibly better than 32 in the first place). From what I've heard, I would not try setting this higher than 16. Depending on your connection speed, you may have better success setting this to an even lower number.
- If you're behind a proxy, you may want to set this value to TRUE as well. Default is FALSE.
- This preference doesn't exist by default, so you'll have to create it. Right-click on some whitespace in
, point to New, then choose Integer. Enter a number between 0 and 1000 (or more if you like, but I don't recommend it) then click OK. This setting stipulates how many milliseconds Firefox waits to start rendering a page after it starts to receive data. The default behavior is 250. I usually set mine to 0, meaning Firefox will start rendering the page with no delay at all. This provides near-instant feedback while browsing. Setting this preference to a higher number - 250 (default), 500, 1000, etc. - will allow Firefox to download more data before it starts to render the page. Some people prefer to set this to 1000 or so, which will give a one-second delay before the page starts to render, but will usually render the entire page all at once in the blink of an eye. Try several settings and see how you like it best. Setting the delay to 0 may actually slow down browsing slightly, but gives an illusion of speed since the rendering begins immediately. Setting a long delay doesn't give feedback so quickly, but you get the whole page all at once instead of in chunks, which seems faster to some people.
- This preference allows Firefox to cache pages and files in memory, which can allegedly improve performance with the back and forward buttons. I've never noticed a difference myself, but I imagine mileage will vary on different systems. Default is TRUE so you probably don't need to change this one.
- Only used if the above setting is set to TRUE. This setting controls how much memory Firefox is allowed to use for caching purposes. Supposedly, setting this to a higher number can improve performance, provided you have enough free memory in the first place. Again, I've never noticed a difference from this.
There are other Firefox settings that can help with performance, but they tend to be very specific to the kind of system you're running Firefox on. A partial list can be found here [tweakfactor.com]. Most of these other settings are more advanced, and should only be attempted by those who are fairly familiar with Firefox. If you choose to play around with any of this advanced stuff, be sure to write down your current settings for the relevant preferences so you can get them back if you need to - I have run into serious problems with some of these settings, particularly
. Please Note: The page I linked to above tells how to adjust these settings in your user.js file. Unless I'm mistaken, all those settings can also be changed in
Faster Browsing with Firefox (2006 edition)
Updated information on how to get the most out of Firefox
by: MatthewHSE as published on WebmasterWorld [webmasterworld.com]
> Sending the referer header takes time, actually more time than you might think.
In a typical HTTP request header, the Referer field would account for, at most, only about 15% of the request. And this assumes a 'minimalist' request header; In most cases using a standard browser, the Referer would account for even less of the header content.
For example, requesting this thread yields the following request (specifics obscured):
GET /firefox_browser/3003153.htm HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060508 Firefox/188.8.131.52
Cookie: WebmasterWorldVegas2006=.abc123xyz.ghi.192.168.0.; WebmasterWorldBoston2006=.abc123xyz.ghi.192.168.0.
> I can't imagine any problems that might be caused by setting this preference to '1' (send referer header for page requests only) and that should improve performance dramatically on most websites.
Disabling referers for image and script requests may cause you to run afoul of Web sites that employ anti-hotlinking and/or anti-scraping protection, and lessen the accuracy of all visited sites' statistics for marketing and usability analysis. As a mark of respect for my fellow Webmasters, I surf with referers enabled unless a compelling 'privacy' issue exists, and recommend that most folks do the same.
Note that somewhere in the mists of time, the name of the HTTP header which conveyed the URL of the referring page was misspelled, and so remains "Referer" to this day.
Setting nglayout.initialpaint.delay to anything less that 20 is pointless, since 20 milliseconds is just at the time threshold visually perceivable to humans. Also, even longer (but still too-short) layout delay settings can be self-defeating, since the browser will restart layout repeatedly until the entire page contents have been received and rendered. Therefore, I'd recommend leaving this at the default 250 milliseconds, or --if you want to tweak-- setting this number to the "highest value that you can stand" and lowering it until you notice that *most* of the pages that you habitually visit start to show signs of multiple rendering attempts. Then increase the value slightly until you no longer see frequent multiple layout attempts. The faster your connection and the faster your computer's CPU/memory, the lower this setting can go without causing distracting multiple-rendering passes.
Other than those two minor points, thanks for the update!
I have to say I'm a little surprised at your conclusions regarding nglayout.initialpaint.delay. Actually, if I could recommend a single change to make Firefox faster (or at least seem that way), this one would be it. So 20 milliseconds is the most we'd be able to notice anyway? That's interesting; I didn't know that. Could you explain how one would notice if there are multiple rendering attempts? I've had my nglayout.initialpaint.delay set to 0 for a couple years and have never seen anything that looks like another rendering attempt, but maybe I don't know what to look for. Come to think of it, if multiple renderings are involved, is it possible that a higher-end CPU would make the rendering attempts quicker, and therefore less liable to be noticed? If so, it might be such a thing that people with fairly good processors may prefer a lower value, while those with older CPU's might like a higher value.
If anyone wants to test this, changes to the nglayout.initialpaint.delay setting are applied immediately, without requiring a browser restart. (Actually, I think all
settings are like that, but I'm not sure.) You can even have about:config open in one tab, change your settings, then quickly switch to another tab to test the result. This means you can try several settings within a few seconds and see the differences practically side-by-side (and decide if you'd like a larger or smaller value).
Also, I'd like to reiterate that a smaller value gives an illusion of faster browsing by providing instant feedback, even though it may actually slow down the complete length of time required to render the page. As I said, if I could recommend any single setting to increase browsing speed (or the impression thereof) in Firefox, it would be this one. However, since this admittedly has everything to do with your system, and nothing to do with your connection speed, results will undoubtedly vary.
The simplest example is multiple-column pages laid out using <table> --like the WebmasterWorld home page-- when the columns do not have a specified width.
In this case, if the content for the second column is delayed, you will see the page rendered with the left-most column taking the full width of the screen. A short time later, you'll see the first column shrink in width, as the second column renders to the right of it. This can happen with any number of columns greater than 1.
The delay in the browser receiving the second-column markup to be rendered could be due to connection-related delays, or perhaps delays in a script or a database lookup on a busy server.
But regardless of the reason, the effect is that you see "things moving around or changing size" on the screen.
You can also see this on busy "graphics-and-ad-rich" sites like The Weather Channel, but they're not good for setting/testing the browser settings because they are just "too slow" on their own, due to all the image requests from external ad servers, image servers, etc. I very rarely see sites like that that *don't* force at least one re-rendering pass during their "busy hours" when one or more of the servers get back-logged. But they make good examples to watch for re-rendering cycles if you want to see them.
I recommended "setting nglayout delay to the longest you can stand," and then adjusting down until this happens. I always end up somewhere around the default value anyway, but the number I start with -- the longest I can stand -- is admittedly only about 750 mSecs anyway... :)
The minimum visually-perceptible timeframe affected/affects the design of many systems -- The frame rate of motion pictures, the refresh rate/response time of television and computer monitors, etc. When frame/refresh rates are too slow, we perceive this as a 'flickering' on the screen. At 50 cycles per second (20 mSec per frame), the flicker is just barely perceptible, but can be quite annoying over long sittings. Raise the frequency just a little bit to 60 Hertz or 16.7 mSecs, and most people can no longer see the flicker. And at 14mSecs, almost no-one can perceive it.
Either way you like it, high or low, nglayout.initialpaint.delay does have a major impact on the "feel" of browsing. I'd encourage folks to play around with it and see what they like best.
Like amznVibe said, FasterFox will do lots of this in a GUI, but remember that every extension you add will slightly slow down startup times. For that reason, I prefer to make changes like these in about:config instead of with extensions. But if you're uncomfortable editing about:config manually, then FasterFox is an excellent choice.
Well-spotted about the prefetching too - I always turn that off now and it doesn't seem to help much anyway.
I was getting annoyed by the number of sites (usually discussion forums and livejournal pages) that were using my bandwidth and images without even asking me, let alone linking back to the page the image came from.
Many webmasters feel the same, so visitors may find a lot of sites don't display properly if they disable the referer header.
[edited by: UserFriendly at 4:58 pm (utc) on July 12, 2006]
network.http.sendRefererHeader - This setting controls whether or not Firefox will send a "referer header" for the pages and files it requests. Sending the referer header takes time, actually more time than you might think. Turning it off can improve your browsing speed quite a bit. The default for this one is '2', which means Firefox will send the referer header for page requests AND for images. Set this preference to '1' to send a referer header for page requests only (faster), or to '0' to not send referer headers at all (fastest).
WARNING: Disabling the referer header can cause some websites not to work correctly; for instance, Buy.com
Would this disable affiliate links that I clicked on from working? or make the tracking so that affiliate links would not be paid?
I am also curious if there is a thread on how to block referrers that come up blocked.
(...)I understand about the referer header being useful to webmasters, but included the tip for the sake of completeness. Regarding whether or not it actually helps, all I can say is that I can tell a definite difference when I turn off referers (which is only about half the time, and even then more for privacy than speed).(...)
Technical view: HTTP requests use TCP which, in turns, usually use IP packets to transfer data. Your browser will be most of time sending full MTU-sized packets on the header request, have them an "Referer" header or not. Of course, omiting the "Referer" header may cause one packet to be omited at the end, but you must be lucky to make it always happen (it suffice a single additional byte to make the TCP stack send another IP packet). FYI, maximum packet sizes usually have 1500 bytes for LAN, and 1400-1492 in DSL connections, so normally it suffices only 1-3 packets for your browser to make the header request. Nevertheless, "wasted" and lost IP packets are "routine" on IP connections (due to congestion, path MTU discovery etc.), so it's not by avoiding one or other packet that your connection will go "faster".
Statistical view: given an average request response size of 10kb (for instance, this very same WW topic listing has currently 11kb), and an average 100 bytes "Referer" header, referral information will acount for only for 1% of the network traffic. (And we even aren't accounting for HTTP headers). If it takes 1 second of network time to service your page request (a fairly slow time), omiting the "Referer" header would give you only 10ms less! NB: you may notice that it takes longer on your browser to load and display a page, but this happens due to other factors, such as HTTP handshaking, browser parser and layout engine, etc, which have nothing to do with the "Referer" header.
So I doubt your browser is anyway faster because you turned off the "Referer" header.
network.http.pipelining.maxrequests - this had been set at '32' since your original thread. After changing to '16' my load time for a single page doubled while multiple tabs just sat and spun. It is now back to '32' :-)
network.http.sendRefererHeader - changed from '0' to '1' and load times tripled. Changed from '1' to '2' and things slowed even more. It is back to '0'. I have yet to have a site display problem - knocks head. Fortunately, as mentioned, it is a simple toggle change with the Web Developer Toolbar.
Why the dramatic load time differences I don't know - testing was across two days and the results were consistent.