HTTP/2 vs HTTP/3: Differences and Performance Comparison

HTTP is the foundation of the modern web. The evolution from HTTP/1.1 to HTTP/2 and HTTP/3 brought significant performance improvements. Understanding the differences between these versions helps you configure your server properly and speed up your website.

Brief History of HTTP

HTTP/1.1 — The Problems

HTTP/1.1 is simple and well-understood, but has serious performance limitations:

• One request at a time — each TCP connection processes requests sequentially. Browsers open 6–8 parallel connections per domain, but that's not enough for modern sites with dozens of resources.
• Text headers — headers are transmitted as text and repeated in every request. Cookies and other headers can take several kilobytes.
• No prioritization — all resources load with equal priority.

HTTP/2 — Multiplexing

HTTP/2 solves HTTP/1.1's problems through binary framing:

Multiplexing

Multiple requests and responses are transmitted simultaneously over a single TCP connection. Each request is a separate "stream," and streams don't block each other at the HTTP level.

Header Compression (HPACK)

HTTP/2 uses the HPACK algorithm for header compression. Repeated headers (Host, User-Agent, Accept) are encoded as indices, reducing size by 85–90%.

Stream Prioritization

Clients can specify priority for each request. CSS and JS can load with high priority while images load with low priority.

Server Push

The server can send resources before the client requests them. In practice, Server Push is rarely used due to complexity with caching.

HTTP/2's Problem: Head-of-Line Blocking

Although HTTP/2 multiplexes streams at the HTTP level, they all travel over a single TCP connection. If one TCP packet is lost, all streams are blocked until retransmission. This is TCP Head-of-Line (HOL) Blocking.

HTTP/3 — QUIC Instead of TCP

HTTP/3 solves HOL blocking by replacing TCP with QUIC — a new transport protocol built on UDP.

QUIC: Key Advantages

• Independent streams — packet loss in one stream doesn't block others. Each QUIC stream is independent at the transport level.
• Faster connection setup — QUIC combines the TLS handshake with transport, reducing connection time from 2–3 RTT (TCP + TLS) to 1 RTT (or 0-RTT for repeat connections).
• Connection migration — when switching networks (Wi-Fi → cellular), the connection persists because QUIC uses Connection IDs instead of IP:port tuples.
• Built-in encryption — TLS 1.3 is built into the protocol. Unencrypted HTTP/3 is impossible.

Performance Comparison

When HTTP/3 Is Noticeably Faster

• On mobile networks with high packet loss rates
• With high latency (RTT > 100ms)
• When frequently switching networks (mobile devices)
• For sites with many small resources

How to Check a Site's Protocol

In the Browser

Open DevTools (F12) → Network → right-click column headers → enable "Protocol." You'll see h2 (HTTP/2) or h3 (HTTP/3) for each resource.

Using curl

# HTTP/2
curl -I --http2 https://example.com

# HTTP/3 (requires curl with QUIC support)
curl -I --http3 https://example.com

Online Tools

The HTTP header checker on Enterno.io shows the protocol version in the server response.

Server Configuration

nginx (HTTP/2)

server {
    listen 443 ssl;
    http2 on;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
}

nginx (HTTP/3)

server {
    listen 443 ssl;
    http2 on;
    listen 443 quic reuseport;
    http3 on;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Recommendations

• Enable HTTP/2 — this is the minimum for a modern website
• Consider HTTP/3 if your audience is on mobile devices
• Don't disable HTTP/1.1 — it's needed as a fallback
• Use TLS 1.3 for maximum performance
• Regularly check your protocol with header analysis tools