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