HTTP/2 dramatically speeds up web asset delivery by allowing a single TCP connection to multiplex multiple requests and responses concurrently, eliminating the head-of-line blocking that plagued HTTP/1.1.
Imagine you’re serving a webpage with dozens of small images, CSS files, and JavaScript snippets. In HTTP/1.1, each of these typically requires its own TCP connection, or if multiplexed over a few connections, they still have to wait in line. If one request is slow to respond, it holds up all the others behind it on that same connection.
With HTTP/2, all these requests and their responses travel over a single, persistent TCP connection. The browser and server break down the data into smaller frames and interleave them. This means a slow response for one asset doesn’t block faster ones; they can all be processed and delivered simultaneously.
Let’s see this in action. We’ll use curl to simulate requests to a server that should be configured for HTTP/2. The key is the -v (verbose) flag, which shows us the connection details.
First, without HTTP/2 (or if it’s not enabled):
curl -v --http1.1 https://example.com/some-asset.jpg
You’ll see output indicating HTTP/1.1 in the request and response headers. If you were to fetch multiple assets this way, you’d observe multiple TCP connections being established (or at least the potential for head-of-line blocking).
Now, with HTTP/2 (assuming your CDN and origin server support it and it’s enabled):
curl -v --http2 https://example.com/some-asset.jpg
The magic happens when you look at the verbose output. You’ll see lines like:
* ALPN, offering h2
* ALPN, server accepted to use h2
* Using HTTP2, server supports multiplexing
This confirms that the connection is using HTTP/2 (h2) and that multiplexing is enabled. If you were to fetch multiple assets using curl --http2 in separate commands (though a more realistic test involves fetching a page with multiple assets within a single browser session), the underlying TCP connection would be reused, and frames for different requests would be interleaved.
The primary lever you control for enabling HTTP/2 on your CDN is your CDN provider’s configuration. Most major CDNs (like Cloudflare, Akamai, AWS CloudFront, Fastly) have a simple toggle or setting within their dashboard to enable HTTP/2 for your domain.
CDN Configuration Steps (General):
- Access CDN Dashboard: Log in to your CDN provider’s web interface.
- Navigate to Domain Settings: Find the specific domain or website configuration for which you want to enable HTTP/2.
- Locate Performance/Speed Settings: Look for sections related to "Performance," "Speed," "Protocols," or "HTTP/2."
- Enable HTTP/2: There will typically be a checkbox or a dropdown menu. Select "Enabled" or "HTTP/2."
- Save Changes: Apply the new configuration.
The CDN then handles the negotiation with the client (browser) using Application-Layer Protocol Negotiation (ALPN) during the TLS handshake. If both the client and the CDN support HTTP/2, they agree to use it. The CDN also needs to be configured to communicate with your origin server using HTTP/2 if possible, though it can fall back to HTTP/1.1 if the origin doesn’t support it.
The benefit isn’t just about speed; it’s also about efficiency. Fewer TCP connections mean less overhead for the client and server. This can lead to lower latency, reduced server load, and a better user experience, especially on mobile networks where connection establishment can be costly.
While CDNs often manage the client-facing HTTP/2 enablement, some advanced configurations might involve:
- Origin Server Support: Ensuring your origin server also supports HTTP/2 can allow for end-to-end HTTP/2 communication, further reducing latency. This involves web server configuration (e.g., Nginx
listen 443 ssl http2;or ApacheProtocols h2 http/1.1). - TLS Configuration: HTTP/2 requires TLS (HTTPS). Ensure your SSL/TLS certificates are correctly installed and valid on your CDN.
- Edge Caching: HTTP/2 is most effective when assets are cacheable. Ensure your caching rules are set up correctly on the CDN to maximize cache hits.
One subtle but powerful aspect of HTTP/2 is its stream prioritization. While the browser and server manage the interleaving of frames, they can also signal the importance of certain streams. For instance, the HTML document itself might be prioritized over a non-critical image. This allows the browser to render the page faster by ensuring essential resources are delivered first, even if they were requested slightly later than other, less important assets. This prioritization is often handled automatically by modern browsers and CDNs, but understanding its existence explains why critical assets might seem to arrive "out of order" but still contribute to a quicker perceived load time.
The next step after enabling HTTP/2 is usually exploring HTTP/3, which builds upon HTTP/2’s multiplexing by using QUIC (built on UDP) instead of TCP, further reducing connection establishment latency and eliminating head-of-line blocking at the transport layer.