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