2 ms·

HTTP/2 Push would have fit the exact same use case as preload links with reduced latency. The whole point was for the server to send the content that should be

HTTP/2 Push would have fit the exact same use case as preload links with reduced latency. The whole point was for the server to send the content that should be preloaded as a header so it could be preloaded before the link tag was ever sent or parsed. This is less useful, in my opinion, for pages that support streaming but for any request that hangs until the entire HTML page has been rendered server-side could have noticeable gains.

klabb3 2y ago
> HTTP/2 Push would have fit the exact same use case as preload links with reduced latency. I’m no expert, but it sounds like this still breaks a lot of assumptions about the 1:1 request-response based protocol that http is. If there’s no request, headers are… inferred? And the determination of what needs to be sent requires the server to model relationships between resources, as well as infer user-agent behaviors. Anyway, I never looked into it deeply. But I always felt this was a massive complexity burden spanning browsers and servers, for essentially bootstrapping cache performance only. Given that websites often don’t even cache properly, don’t bundle their bloated JS, etc, there’s so much low hanging fruit that needs addressing first anyway. So I’m happy it’s dying. Bank for the buck is crucial, and complexity creep is suffocation.