Simple comparison of HTTPS, SPDY, and HTTP / 2 performance

Firefox 35 was released recently and became the first browser to support HTTP / 2 by default.

HTTP / 2 is not a complete technology, so Firefox will activate version 14 of HTTP / 2 , although not much needs to be changed in this protocol. Currently, Google supports the same version on its servers in parallel with SPDY , which gives us a chance to compare the performance of simple HTTPS, SPDY and HTTP / 2 on the same page.

Also, HttpWatch was recently updated. Now it supports HTTP / 2 inside Firefox. A new column has appeared that tells us the protocol by which each request was processed:

Performance comparison

For testing, we will try to load the same page several times (via different protocols). Our test subject, Google UK , uses the following technologies:

• Raw HTTPS
• SPDY / 3.1
• HTTP / 2

Switching between channels is done using the about: config page in Firefox:



Each test was performed in a “fresh” browser installation, which implies the complete absence of cache and other files.

Test # 1 - Request Size and Response Headers

Many sites have already switched to compressing the content of their pages, which is a clear plus in the speed of the site. Unfortunately, HTTP / 1.1 does not support HTTP header compression, which is added to every request and response. SPDY and HTTP / 2 were designed to transmit this data in a variety of ways.

SPDY uses a general-purpose DEFLATE algorithm , while HTTP / 2 uses HPACK specifically designed for this purpose. It uses predefined tokens, dynamic tables, and Huffman technology.

You can notice the difference in the size of the headers even when sending an empty request. On the Google UK page, there is a beacon request that returns an empty response (code 204). This HttpWatch screenshot shows the difference in the size of sent and received messages:


Winner: HTTP / 2

The size of HTTP / 2 requests is significantly smaller thanks to the HPACK algorithm.

Test # 2: response size

The response message is formed from the text of the request, as well as the response in encrypted form. Knowing that HTTP / 2 sends smaller requests doesn’t mean they get more compressed responses, right?

Take a look at the screenshots:



As you can see, SPDY is ahead of its competitor:



The reason may be in extra bytes added to the HTTP / 2 DATA frame . In our logs, we can observe this phenomenon when receiving a response from Google servers. The documentation for the protocol indicates the following reason for adding bytes:

Additional characters are inserted to prevent attacks through HTTP. For example, attacks that include the full response text (look at BREACH ).

Winner: SPDY

It is possible that the response size will be reduced in a later version of HTTP, but now it is not a leader in this category.

Test # 3: Number of TCP Connections and SSL Handshakes Required to Load a Page

Browsers achieved improved performance in HTTP / 1.1 by increasing the number of maximum possible connections to one host from two to six or more. This allowed the page to load faster at the cost of creating more requests.

SPDY and HTTP / 2 allow you to receive and send more information in one connection. Let's look at the test results.


HTTP / 2:



HTTPS can create more than one connection, but less information is transferred to them:



Draw: SPDY & HTTP / 2

In SPDY and HTTP / 2, the number of requests is reduced, but they became more voluminous, which should have a good effect on the speed of data loading . It also loads the server less, because now they do not need to cope with a large number of requests, which also affects their performance a lot.

Test # 4: Page load time

The screenshots below show the page loading speeds using different protocols:



Winner: HTTP / 2

HTTPS loses in this matter due to not the best compression mechanism of the transmitted information, as well as the need to open additional connections. For more complex pages, the difference between SPDY and HTTP / 2 should be more noticeable.

Conclusion

It seemed to us that HTTP / 2 was noticeably faster than SPDY, but there were more answers. The advantage is clearly derived from the smaller GET and HPACK compression. Our Internet connection, like many others, is asymmetric - the download speed can be several times faster than the speed of sending packets. This means that any advantage in sending will be more important than the equivalent download.

HTTP / 2 can compete with protocols such as HTTPS and even SPDY. However, the additional bytes observed by us in the responses are a controversial function, since they pose a choice of security and performance.