Hacker News new | ask | show | jobs
by allyourhorses 1805 days ago
re: cacheability of favicons, this is basically a non-issue as the bandwidth-delay product of even a 10mbit/50ms connection is already 62 kB. Anything below this size on such a connection is likely to render faster than a separate request round-trip.

This raises to almost 1.2 MB with a 100mbit/100ms connection.
1 comments
toast0 1805 days ago
Early on in a connection, congestion window is much more limiting than bandwidth delay product. Do you really want to spend that limited bandwidth on your favicon that you might have already sent to the user before, maybe even in the same browsing session?

It's way better to put it as a separate image, maybe their browser will delay loading it because they're mostly useless. But, you can actually make a favicon useful! If you serve http-strict-transport-security headers with includeSubdomains from your top level domain and you serve your favicon from there, you can push browsers to load them. Ex: your website at www.example.org loads https://example.org/f as its favicon with content expiration about the same as HSTS expiration, and you've now set or refreshed that.

link
javajosh 1804 days ago
Good argument - unless the href length approaches the size of the resource itself!

I don't understand what you're saying about the utility of the favicon with HSTS. It's not something I'm expert in, so perhaps I'm missing something? What does "push browsers to load them" mean?

link
toast0 1804 days ago
If you want to tell browsers that your whole domain (*.example.com) should be https only, you need them to load something from the top level domain (example.com), they're loading is hosted on (say www.example.com or news.example.com). Any resource from https://example.com/ can serve an HSTS header with includeSubdomains, but it might as well be the favicon.
link
allyourhorses 1804 days ago
> Do you really want to spend that limited bandwidth on your favicon that you might have already sent to the user before, maybe even in the same browsing session?

That's a really going point, but if the site's coming down over classic HTTP then still possibly yes, as separate requests are liable to require additional rounds of cold start. The other detail is that I don't think I've worked with a favicon much exceeding 1500 bytes before.

Another option would be pushing the <link> into the footer, but HTML 5 seems to require <link rel="icon"> only in the header. I wonder if browsers really enforce that.

link