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.

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?

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.

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