What Is HTTP/2? Test Whether Your Site Supports It

The Hypertext Transfer Protocol (HTTP) is a set of standards that lets people on the internet exchange website information. Four versions of HTTP have been developed since it was introduced in 1991.

HTTP/2 was released in 2015 as a major revision of the HTTP/1.1 protocol, and it brought significant improvements in speed. The protocol grew out of SPDY, built to raise page loading speed and to cut round-trip time (RTT), above all on pages heavy with resources.

This article covers why the new protocol was needed, how it evolved from SPDY into HTTP/2, how it differs from HTTP/1.1, and how a CDN (content delivery network) can help make your content HTTP/2 compatible. You will also be able to test whether your own site supports HTTP/2.

HTTP/2 Test

HTTP/2 test tool

Sites running on HTTP/2 are, we should say, better placed on SEO thanks to their speed and security characteristics.

From SPDY to HTTP/2

HTTP/1.1 was the third version of HTTP and the standard protocol for more than 15 years. It managed to raise performance with persistent connections and laid the groundwork for standard requests such as GET, HEAD, PUT and POST.

But as websites grew and started using far more resources, the limits of HTTP/1.1 became plain. Allowing only one open request per TCP connection, in particular, created serious overhead that slowed page loading in 1.1.

In 2010 Google introduced the SPDY protocol to change how HTTP handles requests and responses. SPDY was about cutting latency through TCP pipelining and offering features such as mandatory compression.

HTTP/2 was first built on SPDY, but it was quickly changed to add features of its own, the fixed header compression algorithm among them. Google then announced it would drop support for SPDY and back HTTP/2 instead.

How HTTP/1.1 and HTTP/2 Differ

Feature	HTTP/1.1	HTTP/2
Multiplexing	None – every request needs its own TCP connection	Yes – several requests and responses at once over a single TCP connection
Header compression	None – headers go over the wire as plain text	HPACK compression cuts header size by up to 80%
Data transfer	Sequential and blocking	Parallel and non-blocking
Server push	None	Yes – the server can send resources before the client asks
Head-of-line blocking	Yes – a new request waits until the previous one finishes	No – streams run independently
Binary protocol	ASCII format	Binary format – more efficient parsing
Stream priority	None	Yes – you can set the priority of resources
Security	TLS optional	TLS the recommended standard
Connection handling	Managed with Connection: keep-alive	Persistent connection by default
Performance	Baseline	50 to 70% faster page loading

Rolling Out HTTP/2 and the Role of a CDN

Once Google decided to end its support for SPDY, moving to HTTP/2 became a requirement for websites that wanted to cut RTT and speed up page loading.

The move to HTTP/2 can involve a few awkward steps, though:

1. HTTPS compatibility: the new extension to TLS means a site has to be made HTTPS compatible first.
2. Server upgrades: every server has to be upgraded from HTTP/1.1 to HTTP/2. That work can be complicated and easy to get wrong.
3. Bug fixes: HTTP/1.1 bugs can cause trouble during the move to HTTP/2, which means developers have to come up with new solutions.

This is where CDNs make things easier, standing between users and servers as an intermediary. Imperva CDN, for instance, makes your servers HTTP/2 compatible automatically, with no manual upgrade needed.

If your site is in a single language and your visitors are all in one country, a CDN may slow you down rather than speed you up. Measure the effect of a CDN before and after you put it in place.

A Worked Example

The question: how long does it take to load 100 files weighing 10 MB in total from the server to the client? We took help from ChatGPT for the figures in this example.

Loading over HTTP/1.1

1. A separate request per file: in HTTP/1.1 every file comes down over a TCP connection. Browsers usually open 6 parallel connections.
   • Downloading 100 files means opening and closing connections over and over.
   • Connection setup (the TCP handshake) and latency (RTT) push the loading time up as the file count grows.
2. Slow start: every TCP connection uses limited bandwidth at first and speeds up over time. That stretches the loading out further.
3. Header overhead: separate HTTP headers travel with every file, which grows the total size of the data.

Time estimate

• Latency (RTT): about 50 ms (taken as an example).
• Total setup time: 100 files ÷ 6 parallel connections ≈ 17 rounds.
• Connection setup alone: 17 x 50 ms = 850 ms.
• Actual data transfer plus overhead: 10 MB of data plus headers ≈ 1.2 to 1.5 seconds.
• Total: about 2 to 2.5 seconds.

Loading over HTTP/2

A single connection: HTTP/2 moves every file over one TCP connection. That removes the overhead of opening TCP connections.

1. Multiplexing: files travel in parallel over the same connection, which lets them download at the same time.
2. Header compression: HTTP/2 uses HPACK header compression to shrink the size of HTTP headers.
3. Less latency: RTT delays are minimized thanks to multiplexing.

Time estimate

• Connection setup: RTT for a single connection = 50 ms.
• Actual data transfer: 10 MB of data ≈ 1 second (on a 100 Mbps connection).
• Total: about 1 to 1.1 seconds.

In Closing

Across everything we have looked at here, HTTP/2 holds a great many advantages on both speed and security. On search engine optimization too, HTTP/2 is the one to choose, because of exactly those speed and security improvements.