Intent to unship: HTTP/2 Push

Original Article ↗ Hacker News Discussion ↗

Why HTTP/2 Push Failed to Take Off

  • Predicted performance gains were rarely realized in practice.
  • Servers cannot know what’s in the client’s cache, so they often “over-push” already-cached assets, wasting bandwidth and sometimes slowing pages, especially on low-bandwidth or mobile connections.
  • Modern sites often:
    • Use big JS bundles or SPAs where a few files dominate, reducing the benefit of pushing many small assets.
    • Rely heavily on CDNs and multiple origins, where push is less useful or not supported across origins.
  • Existing mechanisms (caching, Link: preload, modulepreload) already cover many intended use cases with lower complexity.

Implementation, Complexity, and Ecosystem Issues

  • Semantics around push were complex: separate push caches, interaction with normal caches, and tricky edge cases across origins and virtual hosts.
  • Browsers had bugs and inconsistent behavior; some dropped push entirely, while Firefox stayed spec-compliant and then hit web compatibility issues due to non-compliant servers.
  • Server and framework support was spotty; many common stacks never exposed an ergonomic way to trigger push.
  • Determining when to push (e.g., only on first visit, per-user content, authenticated resources) added application-level logic and coupling that few wanted to maintain.

Security and Protocol-Level Concerns

  • Pushed resources needed special handling to avoid cache poisoning and cross-site issues, especially given connection coalescing and multi-host certificates.
  • Allowing servers to stuff arbitrary data into caches raises abuse risks (e.g., cache flooding), so browsers constrained push semantics, further reducing its appeal.

Alternatives and Successors

  • 103 Early Hints + Link: preload are seen as simpler, safer, and more cache-friendly ways to reduce latency, while preserving client control.
  • Traditional techniques (HTTP caching, CDNs, embedding critical CSS/JS) and other channels (WebSockets, SSE, WebTransport) address different use cases more cleanly.

Meta and Retrospective Views

  • Some commenters are disappointed; they see push as underexplored and hamstrung by weak tooling rather than inherently flawed.
  • Others view it as an overcomplicated “stretch goal” driven by large vendors, citing it as a cautionary tale about bloating web standards with speculative features.