HTTP/2 and HTTP/3: how to speed up a website with new protocols

Switching from HTTP/1.1 to HTTP/2 and HTTP/3 delivers a noticeable performance boost through multiplexing, header compression, and reduced latency. This article explains how the protocols differ and how to configure them to speed up a website.

You can check support for HTTP/2 and performance metrics using HTTP/2 Checker and Web Vitals on rechecker.ru.

The evolution of HTTP

HTTP/2: key benefits

Multiplexing

A single TCP connection handles multiple parallel streams. With HTTP/1.1, browsers are limited to 6 connections per domain; HTTP/2 removes this limitation.

HTTP/1.1:  [Req1]----[Req2]----[Req3]----  (очередь)
HTTP/2:    [Req1][Req2][Req3][Req4]...    (параллельно)

HPACK header compression

Headers are sent in compressed form. Repeated fields (Host, User-Agent) are encoded by index.

Server Push

The server can send resources before the client requests them. For example, CSS and JS can be sent along with HTML.

Binary framing

Data is sent in binary frames instead of text. This means less parsing and fewer errors.

HTTP/3: what changed

QUIC instead of TCP

HTTP/3 runs over QUIC (Quick UDP Internet Connections), a protocol based on UDP. Key benefits:

• Fast connection establishment — 0-RTT for repeat connections
• Independent streams — packet loss in one stream does not block the others
• Built-in encryption — TLS 1.3 is required
• Resilience to network changes — the Connection ID persists when switching between Wi-Fi and 4G

Latency comparison

Server requirements

Nginx (HTTP/2)

server {
    listen 443 ssl http2;
    server_name example.com;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    # Рекомендуемые настройки
    http2_max_concurrent_streams 128;
    http2_max_field_size 4k;
    http2_max_header_size 16k;
}

Nginx (HTTP/3)

Requires Nginx 1.25+ with the --with-http_v3_module module:

server {
    listen 443 quic reuseport;
    listen 443 ssl http2;
    server_name example.com;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Apache (HTTP/2)

<VirtualHost *:443>
    ServerName example.com
    Protocols h2 http/1.1
    
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
</VirtualHost>

Checking support

In a browser

DevTools → Network → Protocol: check the "Protocol" column (h2, h3, http/1.1).

With curl

curl -sI --http2 https://example.com
curl -sI --http3 https://example.com  # curl 7.66+

Online check

HTTP/2 Checker on rechecker.ru checks HTTP/2 and Brotli support for any domain. Web Vitals measures LCP, FID, and CLS — metrics affected by the choice of protocol.

Impact on Core Web Vitals

Switching to HTTP/2 and HTTP/3 improves performance metrics:

Web Vitals on rechecker.ru measures LCP, FID, and CLS for any page — use it to assess the effect of changing protocols.

Compatibility with CDNs and proxies

Corporate proxies and firewalls may block QUIC (UDP 443). In such cases, the connection falls back to HTTP/2.

The Alt-Svc header

To advertise support for HTTP/3, the server sends:

Alt-Svc: h3=":443"; ma=86400

The browser remembers this information and can establish a QUIC connection immediately on the next visit. The ma parameter is the lifetime in seconds.

Metrics to monitor

After implementing HTTP/2 or HTTP/3, monitor:

• TTFB — time to the first response byte
• LCP — loading of the main content
• Traffic share by protocol — using analytics or logs
• Connection errors — QUIC may be blocked by firewalls

If you have problems with HTTP/3, check that UDP 443 is not blocked. Some corporate networks allow only TCP.

Protocol priority

The browser selects a protocol in order of preference: HTTP/3 (QUIC) > HTTP/2 (TLS) > HTTP/1.1. If QUIC is unavailable, HTTP/2 is used. Fallback to HTTP/1.1 occurs for very old clients or when HTTP/2 is disabled on the server.

Checking protocol support is the first step before configuration. Use HTTP/2 Checker to diagnose the website's current status. Web Vitals metrics show how the protocol affects LCP, FID, and CLS.

Summary

HTTP/2 is the baseline requirement for modern websites. HTTP/3 is the next step and is especially valuable for mobile traffic and unstable networks. Both protocols are backward compatible: the browser automatically selects the best available option.

Configuration takes a few minutes for Nginx or Apache. After enabling the protocol, restart the server and check the result with HTTP/2 Checker. Regularly monitoring Web Vitals will help assess the impact on user experience. Compare the metrics before and after switching to the new protocol. The expected TTFB improvement when switching to HTTP/3 is 10–30% for repeat visits due to 0-RTT. Mobile users benefit the most because of frequent network switching. QUIC completely eliminates head-of-line blocking at the TCP level. The loss of one packet does not block the other streams.

Implementation recommendations

1. Enable HTTP/2 — supported by 97%+ of browsers, with a simple configuration
2. Plan for HTTP/3 — especially for mobile and unstable networks
3. Keep a fallback — HTTP/1.1 for older clients and proxies
4. Monitor metrics — TTFB, LCP, and FCP before and after switching
5. Check your CDN — make sure your provider supports the selected protocol

HTTP/2 is already standard for modern websites. HTTP/3 provides an additional benefit with high latency and packet loss. Check the current status using HTTP/2 Checker and Web Vitals.