Configuring the server for HTTP/2 supportfor Drupal 11 , 10 , 9 , and 8

HTTP/1.1 forces browsers to open a limited number of parallel connections per domain — typically six — so a page needing 40 separate assets waits in queued batches. HTTP/2 multiplexes many requests over a single connection, so all 40 assets can genuinely download in parallel over one connection instead of queuing behind six at a time. For a typical Drupal page with several aggregated CSS/JS files plus multiple images, this is a real, measurable improvement with zero application-code changes required.

What you'll learn in this lesson

• Why HTTP/2 doesn't require any Drupal-side configuration at all
• What actually needs to change at the web-server level
• Why aggressive CSS/JS aggregation matters less (but still helps) under HTTP/2

Enabling it: entirely a web-server concern

# nginx — HTTP/2 requires TLS in practice (all major browsers require it)
server {
    listen 443 ssl http2;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    # ... rest of your existing server block
}

# Apache — requires mod_http2
Protocols h2 http/1.1

Why aggregation still matters, just less

Under HTTP/1.1, aggregating dozens of small CSS/JS files into one bundle was critical, specifically to avoid the six-connections-per-domain bottleneck. Under HTTP/2's multiplexing, that specific bottleneck disappears — but aggregation still reduces total request count and per-request HTTP header overhead, and still benefits from browser caching a single stable file rather than many. The Drupal CSS/JS aggregation you configured earlier in this tutorial remains worthwhile; it's just no longer solving the same critical problem it solved under HTTP/1.1.

Confirming it's actually active

# Check the negotiated protocol directly
curl -I --http2 -v https://example.com 2>&1 | grep "HTTP/2"

Or check your browser's Network tab — Chrome and Firefox both show the protocol column (h2 vs http/1.1) per request if you enable it.

Quick check: after enabling HTTP/2, should you also remove your existing CSS/JS aggregation configuration since the connection-limit problem it solved is gone? If you said no — aggregation still reduces request count and header overhead, it's just no longer solving the specific six-connections bottleneck — you've understood what actually changed and what didn't.

Key takeaways

• HTTP/2 is negotiated entirely at the web-server/TLS layer — zero Drupal configuration involved.
• It removes HTTP/1.1's per-domain connection limit, letting many assets download genuinely in parallel over one connection.
• CSS/JS aggregation remains worthwhile under HTTP/2 for reduced request count and header overhead, just for a different reason than before.
• Verify the protocol is actually negotiated with curl -I --http2 -v or your browser's Network tab — enabling it server-side doesn't guarantee every client uses it.

Coming up next

HTTP/2 speeds up asset delivery once a request reaches your server. Next, we look at stopping requests from reaching your Drupal application at all where possible, using a reverse proxy cache in front of it.