homepage Welcome to WebmasterWorld Guest from 54.166.65.9
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Browsers / Firefox Browser Usage and Support
Forum Library, Charter, Moderators: incrediBILL

Firefox Browser Usage and Support Forum

    
Faster Browsing with Firefox (2006 edition)
Updated information on how to get the most out of Firefox
MatthewHSE




msg:3003155
 9:31 pm on Jul 11, 2006 (gmt 0)

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]

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 about:config 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 about:config since installing extensions can tend to have a hit on Firefox performance.
[webmasterworld.com...]

So on to the actual preferences you'll need to set. To change a preference, double-click it and enter the new value.

  • 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 requires the referer header during the checkout process. Only set this preference to '0' if you think you'll recognize related problems if/when they occur. 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.

    TIP: The excellent Web Developer [addons.mozilla.org] extension allows you to enable or disable referer headers with just two clicks. This option is listed under the "Disable" menu on the Web Developer toolbar.


  • network.http.pipelining - Enabling pipelining allows Firefox to request files (such as images, external CSS and Javascript files, etc.) at the same time instead of individually. The default for this preference is FALSE. Double-click it to set it to TRUE. Enabling pipelining is one of the biggest ways to boost your browsing speed, provided you have a high-speed connection. Pipelining on a dialup connection may have a less noticeable effect.

    WARNING: Pipelining is not well-supported (at all?) on Microsoft web servers. Most of the time everything will still work fine; however, some rare websites (most notably Adobe) that are hosted on Microsoft servers will slow to a crawl if you try to browse them with pipelining turned on. I have only run into this on about three or four occasions in over two years of surfing with pipelining enabled; still, it pays to know the symptoms so you can temporarily disable pipelining if you need to.


  • network.http.pipelining.firstrequest - 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.

    WARNING: The comments above about pipelining may also apply to this setting - or maybe not. I honestly don't know.


  • network.http.pipelining.maxrequests - 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.

    WARNING: Setting this too high may set off security triggers on some web servers and could get you banned from some websites. Keep it to a reasonably low number in the interests of courtesy and convenience to website operators.


  • network.http.proxy.pipelining - If you're behind a proxy, you may want to set this value to TRUE as well. Default is FALSE.

    WARNING: I'm not sure if any proxies would have problems with pipelined requests or not. Maybe someone who knows more about proxies could comment on this.


  • nglayout.initialpaint.delay - This preference doesn't exist by default, so you'll have to create it. Right-click on some whitespace in about:config, 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.

    WARNING: Setting this value below 250 may cause minor rendering problems on some table-based websites. This usually is not a problem, normally being a minor inconvenience at worst.


  • browser.cache.memory.enable - 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.


  • browser.cache.memory.capacity - 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.


  • A Note on the Cache: Firefox tends to slow down a bit as your cache (disk cache, not memory cache) nears its capacity, particularly if you're using a higher than average cache size. Clear your cache periodically to avoid this performance hit. I use the Clear Cache Button [addons.mozilla.org] extension, which gives a toolbar button to quickly clear the browser cache. (This can also be useful for developers who need to be sure they're viewing the most recent version of a page but don't want to disable the cache entirely.)



More Ideas:

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 content.max.tokenizing.time. 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 about:config.

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]

 

jdMorgan




msg:3003250
 10:56 pm on Jul 11, 2006 (gmt 0)

A couple of comments:

> 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
Host: www.webmasterworld.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 60
Connection: keep-alive
Referer: http://www.webmasterworld.com/firefox_browser/
Cookie: WebmasterWorldVegas2006=.abc123xyz.ghi.192.168.0.; WebmasterWorldBoston2006=.abc123xyz.ghi.192.168.0.
Pragma: no-cache
Cache-Control: no-cache

You can see that the Referrer header makes up only a small part of the whole. And since the client request is almost always *much* smaller than the server response, the message bytes and time consumed by sending the HTTP Referer header are fairly insignificant.

> 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!

Jim

MatthewHSE




msg:3003304
 11:43 pm on Jul 11, 2006 (gmt 0)

Thanks for the comments. 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). However, I can see how the performance boost may not be as noticeable once you start getting onto a higher quality connection.

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 about:config 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.

jdMorgan




msg:3003377
 12:52 am on Jul 12, 2006 (gmt 0)

> Could you explain how one would notice if there are multiple rendering attempts?

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.

Jim

Stefan




msg:3003427
 1:48 am on Jul 12, 2006 (gmt 0)

Great thread. I remember using an older version to tweak Firefox, probably started by Matthew. This is one to be bookmarked.

amznVibe




msg:3004069
 2:30 pm on Jul 12, 2006 (gmt 0)

fasterfox will do most of the above in a nice, easily toggle-able way...
[fasterfox.mozdev.org...]

...and please be nice to the other webmasters, turn off prefetching!

"network.prefetch-next" false

[edited by: amznVibe at 2:31 pm (utc) on July 12, 2006]

MatthewHSE




msg:3004183
 3:36 pm on Jul 12, 2006 (gmt 0)

Okay jdMorgan, I understand what you mean now. I've seen it too, although it always goes so quick I never really paid attention to it. This is where the "illusion of speed" comes from. You get feedback faster, which makes browsing seem faster to a lot of people, even though you still have to wait that fraction of a second for the re-rendering to occur before you get readable content. But of course, source-ordered CSS layouts don't have this problem at all, so you do get readable content faster in those cases with a lower delay.

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.

UserFriendly




msg:3004296
 4:49 pm on Jul 12, 2006 (gmt 0)

Precisely because people are increasingly hiding the referer information, I've disabled access to my non-page content unless a valid referer is supplied.

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]

tictoc




msg:3004907
 12:49 am on Jul 13, 2006 (gmt 0)

Great Post. I set the refererheader to 1 and tweaked the other settings you recommended and already see faster browsing.

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.

afmbr




msg:3005816
 5:04 pm on Jul 13, 2006 (gmt 0)

(...)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.

UserFriendly




msg:3006496
 2:34 am on Jul 14, 2006 (gmt 0)

tictoc, what do you mean by "how to block referrers that come up blocked"?

iamlost




msg:3007802
 4:42 pm on Jul 14, 2006 (gmt 0)

Please note that I am on dial-up with an accelerator.

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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Browsers / Firefox Browser Usage and Support
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved