The body for the majority of favicons should fit into a single tcp packet.
Adding the overhead of chunking is completely pointless.
Partial icon streams have no use to the client, and given the server should almost certainly have the entire icon in ram, streaming has no use for the server.
> The body for the majority of favicons should fit into a single tcp packet.
That all depends on the type of internet connection. Sure, it's a great idea for the first world where you get 1Gbps symmetrical for $70 a month. But not everyone has that good of a connection, and packets can be dropped like crazy, dramatically decreasing the size of the window.
Still not a hot idea. The IP packet size is ultimately limited by the Ethernet frame size, which is 1500 bytes practically everywhere. The article says, “A ton of favicon were bigger than 50k,” so it would take over 30 flawlessly delivered fragments to create this hypothetical “single” TCP segment. Any congestion anywhere between you and the server, and the segment does not succeed.
Though, I suspect stestagg meant IP packet. Less than 1.5 kB is just too small for most icons. The ubiquitous 32×32 Wordpress icon is just about small enough, and still sharp enough for Retina, but Amazon’s more detailed favicon is 2.8 kB, Y-Combinator’s icon is 6.5 kB, Apple’s 2-toned logo is 9.1 kB, and Microsoft’s 4 colored squares are an astonishing 17.1 kB.
On the other hand, like everything else outdated about it, Slashdot’s icon is a mere 668 bytes.
Guess whose. (Starts with A, ends with -pple. Actually, that's not true either - .ICO has historically supported 256x256x16b for decades: there just wasn't anyone making them.)
Of course, there's nothing intrinsically bad about high-resolution favicons - esp. given the current ultra-high-res displays. The size difference is only most marked in this specific use-case.
Partial icon streams have no use to the client, and given the server should almost certainly have the entire icon in ram, streaming has no use for the server.