Favicons: Perhaps the Least Understood Web Feature

Last week, there was a thread about how Chrome now has a default favicon (the little icons on each tab in the browser.)

I chimed in with some stats on how Favicons are used (from the HTTP Archive).  There is enough information to make it a post, so here goes 🙂

Every page has (or should have) a favicon. Favcions have been web standard for nearly 20 years and are supported by every browser (including IE6!).  In the April 2019 mobile dataset of the HTTP Archive, there are 4.9 million sites.  There are 3.7M responses with the “.ico” extension. Per the tweet above, a lot of sites don’t have a favicon.  How many exactly?  Well, only 75% of all ico responses result in a HTTP 200 (ok) response:

Screen Shot 2019-05-06 at 4.56.20 PM.png

16.4% of responses are not found (or does not exist), 7% result in a redirect (301 or 302). A further 1% of responses come in a smattering of “other responses”, including 2 418 (I am a teapot) responses.

How can support for a 20 year old standard be so scattered? Let’s dig deeper into the weirdness of the Favicon:

It works! (HTTP 200)

Of the 2.8M HTTP 200 responses in the dataset what do we see? Favicons are generally square and under 64×64 pixels (just think about the resolution that can fit in the tab window).  Accordingly, 95% of these files are under 25 KB.  Of course, this does require 5% to be over 25 KB.  I guess the good news is that 95% of 75% are doing favicons correctly.  Just for fun, let’s lok at some of the 200 outliers.. 🙂

453 sites have favicons over 1 MB, and there are 4 websites out there with favicons over 10MB!  While this will not slow down the load of the page (favicons are often the last to be downloaded), having 93% of your page weight in the favicon seems like an easy optimisation:

Screen Shot 2019-05-07 at 6.56.36 AM

It worked – sort of (HTTP 206)

HTTP 206 response means a partial response – only part of the file is returned.  There are only 683 of these in the dataset, but the 95th percentile tops out at 283KB.

There must be a build system somewhere that designs the favicon from an image, and sets it to exactly 370KB.

Screen Shot 2019-05-07 at 7.30.52 AM

When it comes to these icons, they look fabulous on the screen at 256×256 pixels:

Screen Shot 2019-05-07 at 7.32.19 AM

but the reality of the medium is that this image is squished to a tiny size, and all of the design intricacy is lost:

Screen Shot 2019-05-07 at 7.32.25 AM

delivering a green square would be much smaller 🙂


It doesn’t work (HTTP 404)

When the favicon doesn’t load, nothing really breaks – but it is hard to find the page again in the sea of tabs that many of us harbour in our browsers.  The biggest segment of HTTP responses (after 200 ok) is the 15% of  favicons that are not there, and drop a 404 error.  This is easily fixed by simply creating a favicon!  But 404 errors can go terribly wrong, and I’d like to focus quickly on these.

95% of the 404 responses are under 8 KB, which is great. but there are 1,000 favicons 404 errors that are over 100 KB, and 21 over 1 MB in data transfer.

What happens in these cases is that upon a file not being found, the website serves an HTML page announcing that the file was not found.  In these cases, the html is heavy with inline CSS, JavaScript, etc.

Screen Shot 2019-05-07 at 7.48.15 AM

When images, scripts or other files fail to load, a simple HTTP 404 response should be served, and the large 404 html page should only be delivered when a webpage does not load properly.  To serve a huge 404 page (or to just load the root page of your site) wastes data and server processing.


It worked… maybe? (HTTP 301 & 302)

Redirects.  So the favicon was found, but it has moved?  Maybe?  In some cases this works and the 2nd request is a 200 and the favicon loads.  But there are a number of 302 errors in the dataset that keep going, and going in a futile attempt to find the favicon:

Screen Shot 2019-05-07 at 7.57.25 AM

In this case, each request goes two layers deeper into the file structure, until at the end the request looks something like:


Alt text: Kids in back seat repeating ‘are we there yet?’

There are some fun riffs on this theme:

Screen Shot 2019-05-07 at 7.51.09 AM

In the above screenshot we see two loops interacting with one another:

  1. The 301s are permanent redirects from the http:// to the https:// resources (keeping those icons secure is a good thing!)
  2. the 302s are digging through the file system: https://www.<website&gt;.com.br/m/m/m/m/m/m/m/m/m/m/favicon.ico

Needless to say in both of these examples, the favicon never actually loads, and the browser gives up on this wild goose chase.  In both of these examples, each 302 redirect weighs in at over 180 KB – meaning that there is over 1MB of data transferred (on mobile!) in traffic control of files.


I am sure it is there, but the server screwed up (HTTP 500)

There are 4600 HTTP 500 responses (internal server error) when favicons are requested.

Screen Shot 2019-05-07 at 8.16.42 AM.png


Favicons are really useful for identifying an open tab in your browser, and the absence of a favicon makes this more difficult, but otherwise will not break your website.  This is probably why only 75% of sites in the HTTP Archive have favicons that load as expected.  In this post, I’ve identified how misconfigurations of 404 errors and redirects can generate a large amount of data traffic while failing to provide anything of use to the end users.  I’ve also shown how intricate favicons lose all detail, and should be simplified to reduce the size of the files.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.