Does HTTP/2 server push really cut requests for improved SEO?

What exactly is HTTP/2 server push?

HTTP/2 server push allows the server to send resources to the browser even before the browser requests them. Specifically, when a user requests an HTML page, the server can immediately push the critical CSS, JavaScript, or images without waiting for the browser to parse the HTML and issue new requests.

This approach aims to eliminate network round trips that slow down loading. Instead of waiting for the browser to discover that it needs style.css, the server proactively sends it. In theory, this reduces initial rendering time and improves the speed metrics that Google uses for ranking.

Why does Google highlight this feature?

Loading speed has been a confirmed ranking factor for years, reinforced by the introduction of Core Web Vitals. HTTP/2 represented a major advancement over HTTP/1.1, particularly due to request multiplexing on a single TCP connection.

Server push fit into this logic: providing webmasters with a technical lever to optimize rendering without multiplying connections. Google encouraged this adoption to speed up the web as a whole, enhancing user experience and reducing bounce rates.

Is this recommendation still relevant?

This is where it becomes complicated. Chrome has abandoned support for HTTP/2 server push since November 2022 in favor of HTTP/3 and Early Hints (103). Other browsers are following this trend. Server push created caching issues: the server could send resources already cached on the client side, wasting bandwidth.

Today, Early Hints (HTTP 103) effectively replace server push by indicating to the browser which resources to preload, without forcefully sending them. This approach better respects browser caching and has proven more effective in real-world tests. Google's statement remains technically accurate for HTTP/2 but becomes obsolete for modern implementations.

• HTTP/2 server push allowed sending resources before the browser explicitly requested them
• The goal was to reduce HTTP requests and network round trips to speed up rendering
• This feature is now obsolete in Chrome and replaced by Early Hints (103)
• The Core Web Vitals remain the real challenge: LCP, FID, CLS must be optimized regardless of the method
• HTTP/3 with QUIC and Early Hints represent the modern approach to achieve the same goals

Does this statement still reflect real-world conditions?

To be honest, this recommendation from Google is outdated and incomplete. HTTP/2 server push was promising in theory, but real-world implementations revealed major issues. Servers often pushed resources that were already cached, creating overhead rather than gains. [To be verified] if Google itself still uses this technique on its own services.

A/B tests conducted by large platforms like Cloudflare or Fastly have shown that server push sometimes degraded performance instead of improving it. The reason? Timing: pushing all critical resources at once can saturate the connection and delay the HTML itself, negatively impacting First Contentful Paint.

What nuances should we add to this claim?

HTTP/2 does indeed improve speed, but not primarily due to server push. The real gain comes from request multiplexing, HPACK header compression, and stream prioritization. These features still work and provide measurable gains on sites with many resources.

Server push, however, required surgical configuration: precisely identify which resources to push, ensure they weren't already cached, and adjust timing. Few sites implemented it correctly. Today, resources are better invested in intelligent preloading via link rel preload, Early Hints, and optimizing the critical rendering path.

What alternative should we prioritize today?

Early Hints (HTTP 103) represent the logical evolution of server push. Instead of forcefully sending resources, the server sends hints to the browser, which decides whether to preload them based on its cache state. Cloudflare and Fastly support this feature natively.

Meanwhile, HTTP/3 with QUIC enhances latency and resilience to packet loss. Combined with Early Hints and a targeted preload strategy, this far exceeds the hypothetical gains of server push. For e-commerce or media sites, migrating to HTTP/3 and implementing Early Hints on critical resources yields measurable gains on LCP and FCP.

What specific actions should be taken to optimize HTTP requests?

Start by migrating to HTTP/2 if you haven't already, but don't bother with server push. Enable HTTP/2 on your server (Apache, Nginx, Caddy) and check with tools like KeyCDN HTTP/2 Test that multiplexing is working correctly. This alone reduces latency on sites with many resources.

Next, identify your critical resources for initial rendering: fonts, above-the-fold CSS, essential JavaScript. Use link rel preload in the HTML head to indicate to the browser to load them first. This approach respects cache and works on all modern browsers without complex server configuration.

How can you take advantage of Early Hints without networking expertise?

If you are using a modern CDN like Cloudflare, enable Early Hints in the Speed settings. The CDN will automatically send 103 hints for preloaded resources. Test the impact on WebPageTest by comparing waterfall charts before and after: you should see critical resources loading sooner.

For self-hosted sites, check that your server supports HTTP 103 code. Nginx from version 1.21 and Apache 2.4.52+ handle it natively. Configure Link headers with rel=preload for your critical assets. Be careful: only preload 3-4 resources maximum to avoid saturating the initial connection.

What mistakes should be avoided when optimizing requests?

Don't fall into the trap of over-preloading. Preloading 20 resources degrades performance instead of improving it, as you saturate bandwidth and delay the HTML. Prioritize only the blocking assets for initial rendering: the web font used above-the-fold, critical CSS, and possibly an essential script.

Also, avoid blindly concatenating all your CSS and JS files. With HTTP/2, multiplexing makes this practice obsolete and counterproductive: a large bundle forces the browser to download unnecessary code for the current page. Prefer code splitting and deferred loading of non-critical modules.

• Migrate to HTTP/2 (or HTTP/3 if available) on your server or CDN
• Identify the 3-4 critical resources for initial rendering using Lighthouse or WebPageTest
• Implement link rel preload in the HTML head for these resources only
• Enable Early Hints (103) if your CDN or server supports it natively
• Test the impact on LCP and FCP with tools like PageSpeed Insights and WebPageTest
• Avoid HTTP/2 server push which is obsolete and unsupported by Chrome