HTTP/2 Push Promise Deprecation
HTTP/2 push promise let the server send a response before the client asked, but it was widely misimplemented and is being deprecated in favor of 103 early hints and preload links.
Definition
HTTP/2 push promise was a feature where the server could send a response on a stream the client had not yet requested, proactively pushing dependencies; it is being deprecated because clients and intermediaries implemented cache handling inconsistently, and 103 early hints plus Link preload achieve the same waterfall reduction without the push complexity.
Context and scope
Applied in server-rendered performance optimization; the current guidance is to use early hints or preload links instead of push.
Common misconceptions
- Push is just preload — preload is a client-side fetch hint; push was a server-side proactive response, which is why it failed — the server could not know the cache state
- Push is still useful in HTTP/3 — it is being deprecated across HTTP/2 and HTTP/3; the replacement (early hints) works in both
Anti-patterns
- Using push to send resources the client already has cached, wasting bandwidth on a push that is immediately discarded
- Pushing so many resources that the client must buffer them all, creating memory pressure worse than the waterfall push was meant to fix
Related concepts
Authoritative source
What it is
HTTP/2 push promise was a feature where the server could send a response on a stream the client had not yet requested, proactively pushing dependencies; it is being deprecated because clients and intermediaries implemented cache handling inconsistently, and 103 early hints plus Link preload achieve the same waterfall reduction without the push complexity. Applied in server-rendered performance optimization; the current guidance is to use early hints or preload links instead of push. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.