01 Why protocol matters
If your site loads slowly, the first instinct is usually to optimise images, defer JavaScript, or upgrade hosting. All worthwhile. But the largest single performance gain on most sites is the one almost nobody talks about: upgrading the HTTP protocol.
HTTP/1.1 — the protocol most of the web ran on for two decades — has structural limits that no amount of front-end optimisation can fix. Upgrading to HTTP/2 cuts page-load time by 20–40% on typical sites. Adding HTTP/3 cuts it further on lossy mobile connections.
Yet as of 2026, around 30% of websites still serve over HTTP/1.1. That's a lot of free performance sitting on the table.
02 HTTP/2 — multiplexing changes everything
The core problem with HTTP/1.1 is head-of-line blocking. Each connection can only handle one request at a time. To work around this, browsers open six parallel connections per host — but that means resource #7 has to wait for resource #1, #2, #3, #4, #5, or #6 to finish.
HTTP/2 introduces multiplexing: a single connection carries any number of requests in parallel. There's no more queueing, no more "domain sharding" hacks (which actively hurt HTTP/2 performance). The browser issues all requests at once and the server streams responses back as they become available.
The other big HTTP/2 wins:
- Header compression (HPACK). HTTP headers sent on every request are highly redundant. HPACK compresses them, saving meaningful bytes per request.
- Server push. The server can pre-emptively send resources it knows the browser will need. (In practice, server push has been deprecated in Chrome — preload links are now preferred.)
- Binary framing. More efficient parsing than HTTP/1.1's text-based protocol.
03 HTTP/3 — and QUIC under the hood
HTTP/3 takes the multiplexing idea further by switching the underlying transport from TCP to QUIC (which runs over UDP).
Why does that matter? Because TCP also has head-of-line blocking, but at the transport layer. If a single packet is lost on an HTTP/2 connection, the entire connection stalls until that packet is retransmitted — even though logically, the lost packet only affects one of the multiplexed streams.
QUIC fixes this by running each multiplexed stream as a separate logical channel. A lost packet only affects its own stream; the others keep flowing.
The practical impact: HTTP/3 is dramatically better than HTTP/2 on lossy connections — mobile networks, congested wifi, transatlantic links. On a high-quality connection the difference is small. But on the connections most of your users actually use, it's substantial.
Other HTTP/3 wins:
- 0-RTT connection setup for repeat visits — saves a round-trip on every page load after the first.
- Connection migration — your connection survives a network change (wifi to LTE) instead of dying.
04 TTFB and what affects it
Time to First Byte (TTFB) is the time between the browser sending its request and receiving the first byte of the response. It's the foundation under everything else — if TTFB is slow, every other metric is delayed by that amount.
What controls TTFB:
- Network distance — the round-trip time between user and server. Use a CDN.
- Server response time — how long your application takes to generate the response. Cache aggressively.
- Protocol — HTTP/3's 0-RTT vs HTTP/2's 1-RTT vs HTTP/1.1's multiple round-trips.
- Connection reuse — established TLS connections skip the handshake on subsequent requests.
A "good" TTFB is under 200ms at the 75th percentile. Many sites sit at 800ms+ because they're running uncached PHP or rendering on every request — both fixable.
05 How to detect what you're using
The fastest check: open Chrome DevTools, go to the Network tab, right-click any column header, enable the "Protocol" column. Reload the page. The protocol column shows h2 (HTTP/2), h3 (HTTP/3), or http/1.1 for each request.
If you're seeing http/1.1 for your main HTML resource, you have a free 20–40% performance upgrade waiting.
For automated detection, Smart SEO Audit's performance check flags both HTTP/2 and HTTP/3 status on every audit, so you can spot when a server-side change has accidentally regressed.
06 Enabling HTTP/2 and HTTP/3
The good news: enabling these is usually a config change, not a development project. Where the change happens depends on your stack:
- If you're behind a CDN (Cloudflare, Fastly, CloudFront), HTTP/2 is on by default and HTTP/3 is one toggle in the dashboard. This is often a five-minute change.
- If you run nginx, HTTP/2 is enabled by adding
http2to yourlistendirective. HTTP/3 requires nginx 1.25+ with QUIC support compiled in. - If you run Apache, enable the
mod_http2module and addProtocols h2 http/1.1to your config. - If you're on a managed PaaS (Vercel, Netlify, Heroku, Cloudflare Pages), HTTP/2 and HTTP/3 are typically already enabled by default.
Both protocols require HTTPS — there's no HTTP/2 or HTTP/3 over plain HTTP. If you're not on HTTPS yet, that's a prerequisite (and is required for SEO regardless).
07 How to audit your protocol stack
What Smart SEO Audit checks on every audit:
- HTTPS with valid certificate.
- HTTP/2 in use.
- HTTP/3 / QUIC available (informational — not yet a hard fail criterion).
- Brotli compression on text resources.
- Response time baseline.
Run an audit on any URL to see your full protocol picture in one report.
? Frequently asked questions
How much faster is HTTP/2 than HTTP/1.1?
Upgrading to HTTP/2 typically cuts page-load time by 20–40% on a typical site, mainly through multiplexing — a single connection carries any number of parallel requests, eliminating HTTP/1.1's head-of-line blocking. As of 2026 around 30% of sites still run HTTP/1.1, so it's a large, free performance gain sitting on the table.
When is HTTP/3 worth enabling over HTTP/2?
HTTP/3 runs over QUIC instead of TCP, so a lost packet only stalls its own stream rather than the whole connection. On a high-quality connection the difference is small, but on lossy connections — mobile networks, congested wifi, transatlantic links — it's substantial. It also adds 0-RTT setup for repeat visits and survives network changes.
How do I check which HTTP protocol my site uses?
Open Chrome DevTools, go to the Network tab, right-click a column header and enable the "Protocol" column, then reload. You'll see h2, h3 or http/1.1 per request. If your main HTML resource shows http/1.1, you have a 20–40% upgrade waiting — usually a config change behind a CDN or in nginx/Apache, not a development project.
→ Related guides
Keep going — these companion guides go deeper on related topics.