Favicons

Web Performance Optimization Discussions
1

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.

But today I saw this:

[code]

[/code]

This is a favicon in base64 encoding? Is this an even better way to do a favicon?

2

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

3

I would not do it.
IE lazy loads the favicon (after onload) and FF will also lazy load it, if you do NOT put a link tag in the HTML (and of course, the favcion.ico file must be in the root).

4

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.

5

Ive finally decided to add a favicon on a client site. It was working when I first I uploaded the files to public_html

But now it doesnt.

Html code:
Or do I need to change it to: ?

Thanks,
Duncan - StraightSilver

6

Where is the document? You can use relative URLs just like with images. I do think you need 2 different entries to support various browsers. This is what mine looks like:

<link rel="shortcut icon" href="/images/favicon.ico" type="image/vnd.microsoft.icon">
<link rel="icon" href="/images/favicon.png" type="image/png">
7

[quote=“pmeenan, post:6, topic:449”]
I do think you need 2 different entries to support various browsers.[/quote]

More or less, yes. You don’t strictly need the 2 versions that you show, because the ICO format is understood by every major desktop browser. But you might want to have 2 links nevertheless, one for desktop browsers, and one for Apple’s proprietary Apple Touch Icon which is used by iPhones, iPads etc.

So I would recommend (in HTML4 / HTML5 syntax):

<!-- Major desktop browsers -->
<link rel="shortcut icon" href="/images/favicon.ico">

<!-- Apple specific -->
<link rel="apple-touch-icon" href="/images/apple-touch-icon.png">

or alternatively for sites which use both HTTP and HTTPS (“//” is a shortcut for the same HTTP/HTTPS as the HTML page itself has):

<link rel="shortcut icon" href="//www.company.com/images/favicon.ico">
<link rel="apple-touch-icon" href="//www.company.com/images/apple-touch-icon.png">

(If the website in question is using a CDN, the favicons should be served over the CDN and the URLs above adapted to this.)

3 quick side notes about favicons:
[list]
[]The ICO format is actually a container which can have multiple resolutions in it (16x16, 32x32, et cetera). Keep this in mind when making the ICO.
[]The type=“image/vnd.microsoft.icon” should not be necessary, since any modern web server ought to recognize the .ico file extension and serve the favicon itself with the correct MIME type.
[*]rel=“shortcut icon” is actually not standards-compliant HTML markup (the space between the two words). But it works, and is understood by every browser AFAIK.
[/list]

8

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.

9

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 (GitHub - chromium/web-page-replay: DEPRECATED - Use WebPageReplayGo instead:) 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.

10

Thanks, Pat!

11

@Marvin: Great test you have done. For what little it’s worth, I have seen much the same – the real-life impact of the favicons is quite small.

If you’re interested, the reason why I suggested to load favicons via CDN comes here:

AFAIK old Internet Explorers would lazy-load the favicon if it’s not added explicitly with markup, but would load it right away if it’s added explicitly in the HTML. That behavior is said to be the origin of the advice to just add favicons to the root of your website, and not mention them in the HTML.

However, old IEs are slowly dying out, and AFAIK all modern browsers will lazy-load the favicons, even if they’re explicitly linked in the HTML. I have no reference for this at hand, but I’ve been told so a couple of times now.

Lastly, modern social media favicons and gravitars like Facebook’s “Share” icon may appear on many sites, and in contexts where they cannot be lazy-loaded.

So on balance, given the above, I find it more maintainable to handle the favicons, gravatars, social media icons and whatnot as just another static resource – and put them on the CDN, where all the other static resources already reside. And if modern browsers lazy-load the CDN favicons too, then it’s certainly not going to be slower to load favicons via CDN.

12

Jasper, I thank you very kindly for replying in such detail. Now that I understand it, I placed my favicon on the CDN permanently. I again did a series of before & after tests. Just like in the first testing in the morning, I can still very clearly see that placing the .ico on the CDN saves about 50 milliseconds. I’ll leave it as is. :slight_smile: