3 ms·

> Http push required extra config on the server to decide what to push. This requires extra headers to determine what content to compress against (and the serve

> Http push required extra config on the server to decide what to push. This requires extra headers to determine what content to compress against (and the server to store that old/common content). This does seem like an advanced use case you won't generally want to set up manually, but it is pretty different than push. Push required knowing what to push, which depends on what a page loads but also when the page loads it, which itself depends on the speed of the client. Mess that up and you can actually slow down the page load (like pushing resources the client already started downloading). Compression dictionaries could be as simple as vercel or whoever supporting deltas for your last n deployments, at which point the header to include is trivial.

londons_explore 2y ago
> Push required knowing what to push, Could have been as simple as once-per-resource webpack build step which detected all resources downloaded per-page (easy with a headless chromium), and then pushing all of those (or all of the non-cacheable ones if the client sends a recent cookie). Yet frameworks and build systems didn't do that, and the feature was never really used. > you can actually slow down the page load (like pushing resources the client already started downloading). Any semi-smart server can prevent that, because it already knows what is currently being transferred to the client, or was already transferred in this session. There is no race condition as long as the server refuses to double-send resources. Granted, some server side architectures make this hard without the load balancer being aware. This compression dictionary will see the exact same fate IMO.