HTTP2 Test
The HTTP/2 Test verifies whether your origin or CDN is serving content over HTTP/2 (and ideally HTTP/3 / QUIC) instead of the legacy HTTP/1.1 protocol.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The HTTP/2 Test verifies whether your origin or CDN is serving content over HTTP/2 (and ideally HTTP/3 / QUIC) instead of the legacy HTTP/1.1 protocol. HTTP/2 multiplexes requests over a single connection, eliminates head-of-line blocking, and ships header compression — together cutting load times by 20-50% with no application changes. HTTP/3 takes this further over UDP for even lower latency. Any modern CDN supports both with a single setting; some legacy origins are still on HTTP/1.1 by default.
What This Tool Checks
- Negotiated HTTP protocol version (1.1, 2, 3)
- ALPN negotiation result
- HTTP/2 server push usage (now deprecated)
- HTTP/3 / QUIC support via Alt-Svc header
- TLS 1.2 / 1.3 negotiation
- Connection multiplexing observable in waterfall
Why It Matters for SEO
HTTP/2 is the baseline expected by Google, every modern CDN and every browser since 2015. Sites still on HTTP/1.1 suffer per-connection limits (6 connections per origin) and head-of-line blocking, which slow page load substantially when you have more than a handful of assets. HTTP/3 over QUIC handles network changes (Wi-Fi to mobile) gracefully and reduces handshake latency further. Both are free wins from a CDN config flag.
How to Fix It
Enable HTTP/2 at your CDN (almost universally a single toggle). Enable HTTP/3 / QUIC alongside. Verify ALPN negotiation succeeds on TLS 1.2 / 1.3. If you control the origin, enable HTTP/2 there too — modern Nginx, Apache, IIS, Caddy and Node all support it natively.
How It Works
We open a TLS connection to your origin and inspect the ALPN (Application-Layer Protocol Negotiation) result, then make a request and verify the protocol used. The Alt-Svc header tells us whether HTTP/3 is advertised. The full TLS / HTTP handshake is reported.
Common Mistakes to Avoid
- Origin still on HTTP/1.1 even though CDN speaks HTTP/2 to clients
- HTTP/2 enabled but TLS configured incorrectly (forces fallback)
- Continuing to use HTTP/2 server push (now deprecated; use 103 Early Hints)
- HTTP/3 not enabled when CDN supports it
- Mixed HTTP/2 and HTTP/1.1 across subdomains, breaking connection coalescing
Quick Checklist
- HTTP/2 negotiated on every request
- HTTP/3 advertised via Alt-Svc
- TLS 1.3 supported
- No HTTP/1.1 fallback under normal conditions
- Origin protocol matches edge protocol
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
A major revision of the HTTP protocol that multiplexes requests over a single connection, eliminates head-of-line blocking, and compresses headers. Cuts load times by 20-50% versus HTTP/1.1.
Both. HTTP/2 is the universal baseline; HTTP/3 over QUIC handles network changes more gracefully and reduces handshake latency. Browsers fall back to HTTP/2 if HTTP/3 fails.
No. HTTP/2 server push has been deprecated in major browsers because it rarely beat preload hints and caused complexity. Use 103 Early Hints with link rel=preload instead.
Indirectly but consistently. Faster page loads from HTTP/2 multiplexing improve Core Web Vitals scores in CrUX field data, feeding Google's page-experience ranking signal.
Add `http2` to the listen directive: `listen 443 ssl http2;`. For HTTP/3 you need an Nginx version with QUIC support or a CDN in front. Reload Nginx after editing the config.