Use data uri for favicon?

[nimbupani]

@SlexAxton mentioned on twitter:

I wonder how many people could cut their logs in half by using an empty favicon as a data uri? Can we just default to blank uri in @h5bp ? the log file quip was a gag. I think it's better for @h5bp to ship with no additional requests for empty/default favicons. Not that cut & dry I spose. Depends on it's a better default for most peeps. Do people usually have favicons?

PROS:

• One less network request by default
• Lower number of accidentally-showing-underwear kinds of sites that wear @h5bp favicons by accident.

CONS:

• More markup!
• Users might think data-uris are better ways of serving favicons and cram index.html with huge ones.
• data URIs don’t work in IE < 8.
• IE (even IE 10) only supports .ico favicons — so, you’d only be able to use such a data URL only. No PNG, GIF, SVG, or anything else.

Opinions?

[mathiasbynens]

Aha, @dperini has been saying this for years! I disagreed with him then and I still disagree with this proposal now.

IMHO, this is a partial solution to a problem that can’t be fixed. More tools than just browsers rely on /favicon.ico as the de facto location of the icon.

I personally really dislike bloating the markup.

Another con is that data URIs don’t work in IE < 8 (yeah yeah, I know most of you don’t care).

Also note that IE (even IE 10) only supports .ico favicons — so, you’d only be able to use such a data URL only. No PNG, GIF, SVG, or anything else. :(

I feel like it’s better to encourage people to add a favicon in /favicon.ico than to default to data URLs that bloat the markup while still not fully fixing the “OMG NETWORK REQUESTZ” problem.

[paulirish]

I'm also -1 on the proposal

• favicon requests are done very lazily so they should have zero impact on the perf of your page
• if superfluous 200's are the problem, expires headers are the solution. 1day expires seems fine, although we actually have 1w expires specified in the .htaccess
• data-uri is a bad solution for the reasons above as well as pages are always delivered without caching and assets are typically cached. this means you force around 200 additional bytes on all page requests (that's gzipped). not cool, man.

I do feel strongly that all sites need a favicon. Ones without are a pox upon my tab bar and decrease the usability of my browsing experience.

h5bp includes a default favicon to remind you to change it. If we want to change the star to a GW Bush head, then that might be more effective.

[richardcornish]

@paulirish I'm -1 on the GW Bush head favicon. :p

[mathiasbynens]

A GW Bush head favicon could be the new hotpink text selection.

I like it.

[nimbupani]

+1 on GWB icon. But sounds like everything else about this issue is -1. Closing.

[dperini]

@mathiasbynens I have never said to use a data URI to replace legitimate favicons. I do like FAVICONS and I agree that each page should have a favicon if it would be visible to the user.

What I suggested is a way to avoid fake favicons requests by using an empty data URI, that still holds true.

Let's suppose a page containing ONLY three iframes. Where will the iframes favicons be visible ?

This is ONE case were there is no need to serve requests for favicons, now multiply the requests length and add the transferred data size to that to find out how much bloat you could have removed.

ANOTHER case is were one uses the embeded Webkit in Android or iOS, favicons are not showed anywhere but they are still requested and downloaded for nothing.

@paulirish the empty data URI link syntax is just adding 80bytes not 200bytes, the request alone is weighting more than 200 bytes anyway and for each iframe in the page, now consider the number of iframes possibly present in every page.

[mathiasbynens]

I have never said to use a data URI to replace legitimate favicons. […] What I suggested is a way to avoid fake favicons requests by using an empty data URI, that still holds true.

Sure, but that’s what this discussion is about — using data URLs for placeholder favicons until the user replaces it with a legitimate icon. I guess we all agree that real favicons should be /favicon.ico :)

[paulirish]

I just tested the iframe situation in modern webkit and cannot repro superfluous favicon requests for iframe'd content.

<!doctype html>
<h1>i am the parent page and i'll trigger a favicon request</h1>

<iframe src="//localhost:8060/iframed.html"></iframe>

and then for iframed.html

<!doctype html>
<h1>i'm iframed. hopefully no favicon req</h1>

using independent origins for safekeeping.. and refreshes only expose the page request.

$ python -m SimpleHTTPServer 8060
Serving HTTP on 0.0.0.0 port 8060 ...
localhost - - [05/Jun/2012 17:44:18] "GET /iframed.html HTTP/1.1" 200 -
localhost - - [05/Jun/2012 17:44:20] "GET /iframed.html HTTP/1.1" 200 -
localhost - - [05/Jun/2012 17:44:22] "GET /iframed.html HTTP/1.1" 200 -

Same results opening the test page with iOS 4.

[dperini]

Paul, it seems in current Chrome the requests are triggered on the parent. Try adding this line at the end of the iframe HTML code so it refreshes the iframe continuously (as ADs do):

<script type="text/javascript">setTimeout(function() { location.reload(true); }, 5000);</script>

clear the browser "cache" let it run and then check your parent page server logs. You should see the fake /favicon.ico 404 requests. I am currently using Chrome 19.0.1084.54.

[paulirish]

@dperini

added the reload bit to the iframed.html. It's causing repeated requests to the parent page's favicon. that's bizarre. HTTP caching would solve that, and it's probably a bug anyway in webkit.

the iframed page doesnt incur any favicon requests in this setup.

same behavior for me in chrome stable and canary.

[dperini]

Yes, it must be a Chrome bug I tested the same behaviour on Chrome for Windows and Chrome Beta on Android.

However the same does not happen in Safari/Mac. So I doubt it to be a Webkit bug, not sure about that anyway.

On Chrome/Android this turns to be actually worst, I get three request to the parent page for each frame reload:

192.168.1.4 - - [06/Jun/2012:17:03:25 +0200] "GET /favicon.ico HTTP/1.1" 404 183
192.168.1.4 - - [06/Jun/2012:17:03:25 +0200] "GET /apple-touch-icon-precomposed.png HTTP/1.1" 404 197
192.168.1.4 - - [06/Jun/2012:17:03:25 +0200] "GET /apple-touch-icon.png HTTP/1.1" 404 189

I confirm that none of the current browsers incur in favicon requests for iframes, though I am sure I have seen this happen in older Firefox releases and possibly on other browsers too.

[paulirish]

ouch. pretty bad. can you file a ticket for that at new.mcrbug.com ? thx

[dperini]

https://code.google.com/p/chromium/issues/detail?id=131567

ticket done !

Deserves a quick fix.

Edit: not sure I marked the bug correctly, I used "Android Issue".

[paulirish]

Thanks. You marked it well. :)