HTTP/2 is the second major revision of the HTTP protocol, standardised in RFC 7540. Its key changes over HTTP/1.1 are request multiplexing (many requests share a single TCP connection), HPACK header compression, binary framing, and stream prioritisation. These reduce round-trips and connection overhead without changing how applications send or receive data.
Why it matters
HTTP/2 noticeably reduces load time on pages with many small resources — fonts, icons, scripts, images — by removing the per-connection bottleneck of HTTP/1.1. That feeds directly into TTFB and the broader Core Web Vitals. Because all major browsers require HTTPS for HTTP/2, enabling it also pushes you onto a more secure baseline.
How to check
- Inspect a response in DevTools or with
curl -I --http2 https://example.comand look forHTTP/2 200. - Confirm your CDN, load balancer, or origin server has HTTP/2 enabled — most modern stacks ship it on by default.
- Make sure HTTPS is correctly configured; HTTP/2 will not negotiate over plaintext in browsers.
- Audit asset bundling: under HTTP/2 you usually want smaller, granular files, not megabyte sprite sheets.
- Pair with response compression (Brotli or Gzip) for the biggest wins on text payloads.
- Once HTTP/2 is stable, evaluate HTTP/3 on a CDN for users on lossy mobile networks.