Hacker News Reader

Comment by billti | Hacker News Reader

When I'm testing locally with a trivial site, those favicon 404 requests bugged me when checking the log. I'm also a little bit obsessive about keeping my pages small. This resulted in me going down a rabbit hole of the GIF spec to see the smallest inline blank favicon I could create. I ended up with:

  <link rel="icon" href="data:image/gif;base64,R0lGODlhEAAQAAAAACwAAAAAAQABAAACASgAOw==">

Putting that small line in my HEAD tag gets rid of those annoying extra requests, and results in no favicon (it's just a totally transparent image).

If interested in the format, I put a gist up at https://gist.github.com/billti/81d4b601c9022ba3655a3a03873ca... with the small node.js script I wrote to generate various examples. (You can see more examples and links in the comments in the top if interested).

View on HN

I was looking into the same issue and learned that modern browsers now also support SVG images for favicons.

So far, this is what I've come up with -

  <link rel="icon" href="data:image/svg+xml,%3csvg%3e %3c/svg%3e">

Interesting solution! It shows at the "no favicon" image on the page tab (the dog-eared page icon) in the latest Chrome/Edge for me, not as a blank/clear icon. (I get that same result when I used GIFs that were invalid).

Thanks for letting me know. I probably have to tweak it a bit to make sure it's valid in all browsers.

While researching, I've found some fun things people have been doing using text and emojis in SVGs [0]

[0] https://lean8086.com/articles/using-an-emoji-as-favicon-with... [1] https://css-tricks.com/emojis-as-favicons/

Check out small, it’s a collection of the smallest perfectly cromulent instance for common file types. The last time I saw it the repo was not being very actively maintained but had lots more samples filed as pull requests.

They come in handy more often than you’d think.

https://github.com/mathiasbynens/small

Yeah, Mathias and I already exchanged on this. (I know him from working on V8). The GIF in that repo doesn’t work as a favicon:

https://twitter.com/billticehurst/status/1288721150780964866...

You can also use:

    <link rel="icon" href="data:,">

I tried stuff like that. While it does remove the extra web request, the favicon that shows on the browser tab shows as the broken image/dog-eared page (at least in Chrome/Edge), not as a lack of a favicon (i.e. transparent image).

Very clever solution!

There should be a browser directive for this. It feels like we should be able to tell the browser no.

A favicon is historically associated with a site, rather than a page. If you look at it that way it seems wrong to attach an extra header to every HTTP request, rather than just incurring the overhead on the first visit to a site.

Of course you can now have a different favicon for every page, or update it dynamically, so that semantic argument is no longer as strong.

Good point. But then many (most?) sites these days don't use a favicon.ico file in the root, but point to a .png or similar via a header tag as shown in the article (e.g. "<link rel=”icon” href=”/path/to/icon.png”>"). That has the same 'semantic' issue of the favicon being specific to the page and not site.

That works until you get crawled by totally broken crawlers that interpret data: URIs as a relative URL. (It's happened to me.)

Why would that matter though? Crawlers of that low quality are almost guaranteed to be worthless for traffic purposes and should likely just be blocked as incorrectly functioning trash.

Reply on news.ycombinator.com