How HTTP/2 Boosts Front‑End Performance: Server Push, Multiplexing & Tips

Background

Since November 2013 the author’s blog supported SPDY, the predecessor of HTTP/2. In early 2016 Google dropped SPDY in favor of HTTP/2, and browsers such as Chrome 40+ and Firefox 36+ officially support the new protocol (RFC 7540). Nginx also announced support for HTTP/2 later that year.

Problem Statement

A web page consists of an HTML document and many resources (CSS, JavaScript, images, etc.). Critical resources that block rendering must be loaded as quickly as possible. The article investigates how to make these resources load faster.

HTTP/1 Analysis

When resources are hosted on CDNs, the main factors that delay loading are browser connection limits, DNS lookup time, and TCP connection establishment. Browsers historically limited each domain to two concurrent connections (later relaxed). DNS lookups can take tens to hundreds of milliseconds, and the TCP three‑way handshake adds further latency.

Static resources are usually cached with long‑lived headers. On a normal refresh the browser sends conditional headers ( If-Modified-Since or If-None-Match) and receives a 304 response if the resource is unchanged, which is very small.

Inlining CSS/JS gives a first‑visit speed advantage but prevents caching, causing repeated downloads on subsequent visits.

Solutions for First Visits

Early implementations inlined critical resources on the first visit and stored them in localStorage after the page loaded, using a version cookie to decide whether to inline or load from cache on later visits. This approach works but doubles traffic and is less suitable for mobile.

A refined method stores only a user identifier in a cookie, lets the server compute which resources need updating, and serves a tailored HTML page.

HTTP/2 Server Push

HTTP/2’s multiplexing allows a single TCP connection to carry many concurrent streams. Server Push lets the server proactively send resources (CSS, JS, images) while delivering the HTML, without waiting for the browser to request them. Pushed resources have their own URLs, can be cached, and can be reused by other pages. The browser may reject a push with an RST_STREAM frame if it already has the resource cached.

HTTP/2 Connection Model

HTTP/2 replaces the text‑based framing of HTTP/1 with binary frames. The main concepts are:

Frame : the smallest unit of communication, carrying headers, data, or control information.

Message : a logical HTTP request or response composed of one or more frames.

Stream : a virtual bidirectional channel within a connection, identified by an integer ID.

Connection : the underlying TCP connection, shared by all streams.

All communication to the same origin occurs over a single connection, which can carry an unlimited number of streams. Frames may arrive out of order and are reassembled using their stream IDs.

Why HTTP/1 Optimizations Become Redundant

HTTP/1 required many tricks to reduce the number of TCP connections: opening multiple domains, concatenating files, inlining resources, and using cookie‑free domains. HTTP/2’s multiplexing makes connections cheap, and header compression reduces overhead, so most of these techniques are no longer beneficial and can even hurt performance.

Remaining Useful Optimizations

Even with HTTP/2, the following practices still improve performance:

Enable GZIP/Brotli compression for text assets.

Leverage strong and weak HTTP caching ( Cache-Control, Expires, ETag, Last-Modified).

Reduce DNS lookups by limiting the number of hostnames and using DNS prefetching.

Minimize redirects and use permanent (301) redirects when necessary; enable HSTS for HTTPS sites.

Conclusion

HTTP/2’s multiplexing and header compression make many HTTP/1 connection‑saving tricks obsolete, but web performance optimization remains essential for the next decade. Developers should adopt Server Push where appropriate, continue to compress and cache assets, and simplify domain structures to reduce DNS latency.

Original article links: Part 1 , Part 2 , Part 3 .