What Is HTTP/2 Server Push? β Definition and How It Works
Learn what server push was meant to solve, why browsers removed it, and what replaced it.
HTTP/2 Server Push let a server send resources the client had not requested, anticipating what a page would need. Browsers have removed support for it, so it is now largely a historical feature.
1. The Idea
A browser requests an HTML page, parses it, discovers it needs a stylesheet, and requests that β one round trip after the HTML arrived.
Server push aimed to remove that delay: the server, knowing the page needs the stylesheet, sends it alongside the HTML without waiting to be asked.
Client: GET /index.html
Server: PUSH_PROMISE /style.css
PUSH_PROMISE /app.js
200 /index.html
200 /style.css
200 /app.js
2. Why It Was Removed
It sounded compelling and worked poorly in practice:
Cache-unaware pushing. The server does not know what the client already has, so it pushes resources the browser had cached β wasting bandwidth on every visit after the first.
Cancellation was too late. A client could reject a push, but often only after bytes were already in flight.
Bandwidth contention. Pushed resources competed with the HTML itself, sometimes making the critical path slower.
Measured results disappointed. Real-world data showed neutral or negative effects often enough that the complexity was not justified.
Implementation complexity across servers, CDNs, and browsers was substantial for an uncertain gain.
Chrome removed support, other browsers followed, and the feature is effectively dead on the web.
3. What Replaced It
103 Early Hints β the actual successor. The server sends an informational response with Link headers before the final response, telling the client what to start fetching:
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script
HTTP/1.1 200 OK
Content-Type: text/html
...
This is strictly better because the client decides. It checks its own cache and fetches only what it lacks β which is exactly the problem push could not solve.
rel=preload in HTML β the simpler, widely supported approach: the document declares its critical resources and the browser prioritises them.
rel=preconnect / dns-prefetch β warming connections rather than pushing content.
4. Why It Still Comes Up
Three reasons it remains worth knowing:
- Documentation and tutorials still describe it as a current optimisation, so recognising it as obsolete saves effort.
- Server configurations still contain push directives, now inert.
- HTTP/2 push is still used outside browsers β in some server-to-server and gRPC-adjacent contexts where the client is known and caching is controlled.
5. Relevance to Collection Work
Minimal, and worth stating plainly. For anyone fetching pages:
- You will not encounter push from browsers' perspective, since support is gone.
103 Early Hintsmay appear in responses, and an HTTP client should handle informational responses gracefully rather than treating them as errors.Link: rel=preloadheaders are informative β they tell you which resources the site considers critical, which is occasionally useful for deciding what to block in a browser context.
That last point is the one practical use: preload hints are a site telling you what matters, which helps when configuring resource blocking.
6. A Broader Lesson
Server push is a good example of an optimisation that was theoretically sound and empirically unhelpful. The reason it failed β the server could not know what the client had cached β was structural rather than a matter of tuning.
The replacement succeeded by inverting the control: hint, and let the party with the information decide. That pattern recurs across protocol design.
7. Summary
HTTP/2 Server Push let servers send unrequested resources to save a round trip, and browsers removed it because servers could not know what a client had cached, cancellation came too late, and measured results were often negative.
103 Early Hints replaced it by hinting rather than pushing, letting the client fetch only what it lacks β and for collection work the practical residue is handling informational responses gracefully and reading Link: rel=preload headers as a signal of which resources the site considers critical.