HTTP/2 and HTTP/3: Make HTTP Faster and Safer (SPDY Is Dead)

HTTP/2 and HTTP/3 are the modern protocols that make websites faster and safer than HTTP/1.1. HTTP/2 (standardized in 2015) sends many requests in parallel over a single encrypted connection and compresses headers, so a page with dozens of assets loads in far fewer round trips. HTTP/3 (2022) carries those same streams over QUIC on UDP instead of TCP, which removes transport-level head-of-line blocking and speeds up connection setup. SPDY -- Google's original experiment that inspired both -- is dead: it was folded into HTTP/2, browsers dropped it around 2016, and you should not configure it on any server today.

Key takeaways

• HTTP/2 replaced SPDY. SPDY's best ideas -- multiplexing, header compression and stream prioritization -- were standardized into HTTP/2, and SPDY was then retired.
• SPDY is dead. Major browsers removed SPDY support around 2016 and nginx dropped its spdy module in version 1.9.5. There is no reason to enable SPDY in 2026.
• HTTP/3 runs on QUIC (UDP). It fixes the TCP head-of-line blocking that still affects HTTP/2 and connects faster, especially on flaky mobile networks.
• HTTPS is mandatory. Browsers only negotiate HTTP/2 and HTTP/3 over TLS, so a valid certificate (TLS 1.2/1.3) is required.
• http2 on; is the current nginx syntax. The old listen ... http2 form was deprecated in nginx 1.25.1; HTTP/3 uses a listen ... quic directive.
• Server push is gone. Once an HTTP/2 headline feature, it was deprecated and removed from Chrome -- use preload hints and 103 Early Hints instead.

What problem did HTTP/2 solve in HTTP/1.1?

HTTP/1.1 sends one request at a time per connection. Because each response must come back before the next request goes out, browsers open 6-8 parallel TCP connections per host to fetch a page's images, scripts and stylesheets -- and once those are busy, everything else waits. This is head-of-line blocking at the application layer, and it gets worse as pages grow more asset-heavy.

HTTP/2 fixes this with a few core techniques:

• Multiplexing -- many requests and responses share one connection as independent streams, so a slow image no longer blocks a small CSS file.
• Header compression (HPACK) -- repetitive headers like cookies and user-agent are compressed and de-duplicated instead of re-sent in full with every request.
• Stream prioritization -- the client can hint which resources matter most so the server sends them first.
• Binary framing -- messages are framed in binary rather than plain text, which is faster and less error-prone to parse.

The result: fewer connections, fewer round trips, and noticeably faster page loads on the same hardware.

Where does SPDY fit now?

SPDY (pronounced "speedy") was an experimental protocol Google built around 2009 to prove the web could be much faster. It introduced multiplexing, header compression and prioritization over a single TLS connection, and Google reported page-load improvements of up to ~55% in its own tests.

Those ideas worked so well that the IETF adopted them as the foundation of HTTP/2. Once HTTP/2 shipped in 2015, SPDY had served its purpose: Google deprecated it, Chrome and other browsers removed SPDY support around 2016, and nginx deleted its spdy module in version 1.9.5 (replacing it with http2).

In short, SPDY is purely historical. If you find spdy in an old nginx config, delete it -- it does nothing on modern nginx, and the directive will simply fail to load.

What do HTTP/3 and QUIC add?

HTTP/2 solved application-level head-of-line blocking, but it still runs over TCP -- so if a single TCP packet is lost, every stream on that connection stalls while TCP waits for the retransmission. On lossy mobile networks this can make HTTP/2 feel slower than expected.

HTTP/3 moves the whole protocol onto QUIC, a transport built on UDP:

• No transport head-of-line blocking -- QUIC streams are independent, so one lost packet only stalls its own stream.
• Faster handshakes -- QUIC integrates TLS 1.3, combining transport and encryption setup; returning visitors can even use 0-RTT.
• Connection migration -- a QUIC connection survives a network change (Wi-Fi to cellular) without starting over.

HTTP/3 is supported by current Chrome, Firefox, Edge and Safari and by every major CDN. Because some networks block UDP, clients automatically fall back to HTTP/2 -- so in practice you serve both side by side.

HTTP/1.1 vs HTTP/2 vs HTTP/3: how do they compare?

Aspect	HTTP/1.1	HTTP/2	HTTP/3
Released	1997	2015 (RFC 7540)	2022 (RFC 9114)
Transport	TCP	TCP	QUIC over UDP
Multiplexing	No (one request per connection)	Yes (many streams per connection)	Yes (independent streams)
Head-of-line blocking	Yes (application level)	Yes (TCP level)	No
Header compression	None (plain text)	HPACK	QPACK
Encryption	Optional	Required by browsers (TLS)	Always (TLS 1.3 built in)
Server push	n/a	Deprecated / removed	Not included
Status	Legacy, still common	Current default	Widely supported, growing

How do I enable HTTP/2 and HTTP/3 in nginx?

You need two things first: a recent nginx (1.25.1+ for the http2 on; directive, and a 1.25+ build with QUIC for HTTP/3) and a working TLS certificate, because browsers refuse HTTP/2 and HTTP/3 over plain HTTP. If you don't have certificates yet, set them up first with Let's Encrypt and nginx.

With TLS in place, a modern server block that serves both HTTP/2 and HTTP/3 looks like this:

# Requires nginx 1.25.1+ for `http2 on;` and a 1.25+ build with QUIC for HTTP/3
server {
    # HTTP/2 over TLS (TCP)
    listen 443 ssl;
    listen [::]:443 ssl;

    # HTTP/3 over QUIC (UDP) -- keep reuseport on a single server block
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    server_name example.com;

    # New directive (replaces the deprecated `listen ... http2` form)
    http2 on;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # Tell clients HTTP/3 is available so they upgrade from HTTP/2 to QUIC
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        root  /var/www/example.com;
        index index.html;
    }
}

# Validate the config and reload nginx:
# sudo nginx -t && sudo systemctl reload nginx

How do I test that HTTP/2 and HTTP/3 are working?

The quickest checks are from the command line and your browser:

• curl -- request your site and read the protocol in the status line.
• Browser DevTools -- open the Network panel, right-click the column header, enable Protocol, and reload: you will see h2 for HTTP/2 and h3 for HTTP/3.
• Online testers -- services such as the KeyCDN HTTP/2 test report the negotiated protocol from outside your own network.

# Check HTTP/2 (curl 7.43+)
curl -I --http2 https://example.com
# -> HTTP/2 200

# Check HTTP/3 (needs a curl built with HTTP/3 / QUIC support)
curl -I --http3 https://example.com
# -> HTTP/3 200

# Confirm the Alt-Svc header advertises h3
curl -sI https://example.com | grep -i alt-svc

Putting it together on your stack

Enabling HTTP/2 and HTTP/3 is one piece of a healthy nginx setup. Pair it with clean 301 redirects in nginx so old URLs and the HTTP-to-HTTPS jump don't cost extra round trips, and if you run a Python app, make sure your Django hosting on nginx with uWSGI is tuned to keep up with the extra concurrency these protocols unlock. If you would rather not manage any of this yourself, our server maintenance services keep nginx, TLS and protocol settings current for you.

Frequently Asked Questions

Is SPDY still used in 2026?

No. SPDY was deprecated by Google once its ideas were standardized into HTTP/2, and major browsers removed SPDY support around 2016. nginx also dropped its spdy module in version 1.9.5. Use HTTP/2 and HTTP/3 instead -- there is no reason to run SPDY today.

Do I need HTTPS to use HTTP/2 or HTTP/3?

In practice, yes. The specifications technically allow cleartext HTTP/2 (called h2c), but every major browser only negotiates HTTP/2 and HTTP/3 over TLS. You therefore need a valid certificate with TLS 1.2 or 1.3 enabled on your server.

What is the difference between HTTP/2 and HTTP/3?

HTTP/2 multiplexes many streams over a single TCP connection, while HTTP/3 carries those streams over QUIC, which runs on UDP. HTTP/3 removes the TCP head-of-line blocking that can still affect HTTP/2 and sets up connections faster, but HTTP/2 is perfectly fine for most sites.

Is HTTP/2 server push still recommended?

No. Server push was an early HTTP/2 feature, but it proved hard to use without wasting bandwidth, and Chrome removed support for it. Use <link rel="preload"> resource hints and 103 Early Hints to get similar benefits more reliably.

How do I enable HTTP/2 in nginx?

On nginx 1.25.1 or newer, keep your listen 443 ssl; line and add http2 on;, then reload nginx. On older versions use the combined listen 443 ssl http2; form. Either way a TLS certificate is required, because browsers will not use HTTP/2 over plain HTTP.

Does HTTP/3 replace HTTP/2?

Not entirely, at least not yet. HTTP/3 is widely supported and worth enabling alongside HTTP/2, but when a network blocks UDP, clients fall back to HTTP/2 or HTTP/1.1. The usual approach is to serve HTTP/2 and HTTP/3 together and let the browser pick the best option.