HTTP/2 is the modern standard for web communication, and most major browsers support it, but knowing how to check and ensure your server is speaking it can be tricky.
Let’s see it in action. Open your browser’s developer tools (usually F12), go to the "Network" tab, and reload a page. Look for a "Protocol" column. If you don’t see it, right-click the column headers and enable it. You should see h2 for connections using HTTP/2, or http/1.1 for older ones.
[Screenshot of browser developer tools showing HTTP/2 protocol in the Network tab]
The primary benefit of HTTP/2 is its multiplexing capability. Unlike HTTP/1.1, which had to send requests and responses one at a time over a single connection (leading to head-of-line blocking), HTTP/2 can send multiple requests and responses concurrently over the same connection. This dramatically reduces latency, especially on high-latency networks or when loading pages with many small assets like images and scripts. It also introduces header compression (HPACK) which further shrinks the data transferred.
To understand how it works internally, imagine a single, very efficient pipeline instead of multiple, easily clogged, single-lane roads. When your browser requests a webpage, it establishes a TCP connection. With HTTP/2, it then sends many "streams" of data over that single connection. Each stream represents a request (e.g., for an HTML file, a CSS file, an image). The server can interleave the responses to these streams, sending them back as they become ready, without waiting for previous responses to fully complete. This is the magic of multiplexing.
The key levers you control are on the server-side. You need a web server (like Nginx, Apache, or Caddy) configured to support and enable TLS (HTTPS) for HTTP/2. Most modern web servers enable HTTP/2 by default when HTTPS is configured.
Here’s a typical Nginx configuration snippet for enabling HTTP/2:
server {
listen 443 ssl http2; # The 'http2' directive is key here
server_name yourdomain.com;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
# ... other configurations
}
The http2 directive on the listen directive is the critical piece for Nginx. For Apache, it’s usually an H2 or Protocols h2 http/1.1 directive within your SSL virtual host.
The most surprising thing about HTTP/2 is that it’s actually slower on a perfect, zero-latency network for a single, small request compared to HTTP/1.1. The overhead of setting up the streams and the HPACK compression can add a tiny bit of latency. HTTP/2’s advantages only truly shine when you have multiple requests or when network conditions are less than ideal, which is precisely the scenario most users experience.
To test your server’s HTTP/2 support from the command line, you can use tools like curl with the --http2 flag.
curl --http2 https://yourdomain.com -I
If successful, you should see output indicating a successful connection. A more robust test is to use an online tool like KeyCDN’s HTTP/2 Test or Geekflare’s HTTP/2 Test, which will connect to your domain and report on its HTTP/2 capabilities and TLS configuration.
The next step after ensuring HTTP/2 is working is to explore HTTP/3, which uses QUIC instead of TCP.