Ok, lets discuss a tiny small performance tweak this weekend :-)! The favicon.

I think this: the favicon should be small, no bigger than 1KB. So that it can load very fast. For that reason we use a favicon of 318 bytes on our website...

Preferrably put this favicon in the root of your site, and let browsers deal with it. This is better than linking to the favicon in the html because that line of code makes your html (a tiny tiny bit) bigger with no extra benefit.

Cool, never seen a favicon in a data URI before. That should work for IE > 8, Chrome and Firefox. If the file is small enough it could be a win but you're adding that to EVERY html response so it probably makes first view faster but could be less than optimal for a repeat visit.

It could be an example of over-optimizing since the browsers generally lazy load the favicon anyway and it doesn't interfere with the page content (so as a net this would actually be slower than not referencing one).

Favicon is is usually so small that makes little difference in loading time. There probably should be set some cache time for favicon and other images on site. Just not in the head-meta tags, preferably via servers .htaccess file.

Quote:If the website in question is using a CDN, the favicons should be served over the CDN

I have just performed several tests comparing the load speed of my home page:

- when my favicon.ico is located in the root of my www, and there's no path to favicon.ico in the header

versus:

- favicon.ico served from CDN, and path to it is defined in the header.

I can clearly see that the Time To First Bite + Content Download for the favicon.ico itself is shorter when the .ico is served from my CDN. (The difference for the single .ico file, when tested in a far away location, São Paulo, Brasil, is 175 ms versus 225 ms.) However, even after performing over 30 comparison tests, I'm unable to determine if the over all page load speed is now better, unchanged, or worse. Neither am I able to determine if the .HTTP file's speed is now better, unchanged, or worse.

The problem with testing these very small changes is that the results are being interfered by the changes in DNS Lookup speed and Initial Connection speed, which both may vary from test to test.

I think if there was a way to see test results which would exclude both, DNS Lookup speed and Initial Connection speed, it could be clearer to see if very small changes done to the page affect the load time in a positive or negative way.

After doing my tests, not really understanding the overall impact of adding the extra line to the header, I decided to revert the change, remove the line of code, and return to serving the .ICO from www.

Yeah, I wouldn't really bother with it, most browsers lazy-load it anyway.

One of the things we're working on is to integrate Web Page Replay (http://code.google.com/p/web-page-replay/) into WebPagetest so you can eliminate all of the real-world variability and test just front-end changes in isolation. It won't be useful for things like CDN testing but it will eliminate the network variability for things like your html change.