Simple performance comparison of HTTPS, SPDY and HTTP / 2

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

HTTP / 2 is not a complete technology, so Firefox activates version 14 of HTTP / 2 , although little has to change in this protocol. Currently, Google is supporting this 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 not so long ago was updated HttpWatch. Now it supports HTTP / 2 inside Firefox. A new column appeared, telling us the protocol by which each request was processed:
')

Performance comparison

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

• Raw https
• SPDY / 3.1
• HTTP / 2

Switching between channels takes place 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 moved to compress the content of their pages, which is a clear advantage in the speed of the site. Unfortunately, HTTP / 1.1 does not support HTTP header compression, which is added to each request and response. SPDY and HTTP / 2 were designed to transmit this data in a variety of ways.

SPDY uses a generic 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 screenshot of HttpWatch shows the difference in the size of sent and received messages:


Winner: HTTP / 2

HTTP / 2 request sizes are significantly smaller due to the HPACK algorithm.

Test # 2: response size

Message-response is formed from the text of the request, as well as the answer in an encrypted form. Knowing that HTTP / 2 sends smaller requests doesn’t mean that they receive more concise answers, right?

Take a look at the screenshots:



As you can see, SPDY overtakes its rival:



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

Additional characters are inserted to prevent HTTP attacks. For example, attacks, which include the full text of the answer (look at BREACH ).

Winner: SPDY

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

Test # 3: Number of TCP connections and SSL Handshakes required to load the page

Browsers achieved improved HTTP / 1.1 performance by increasing the number of maximum possible connections to a single 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 for one connection. 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

SPDY and HTTP / 2 reduced the number of requests, 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 page loading speeds using different protocols:



Winner: HTTP / 2

HTTPS loses in this matter due to the lack of a better mechanism for compressing 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 the responses were greater. The advantage is clearly due to the smaller GET and HPACK compression. Our internet connection, like many, is asymmetrical - the download speed can be many times greater than the speed of sending packets. This means that any advantage in sending will be more important than the equivalent download.

HTTP / 2 can tamper with protocols such as HTTPS and even SPDY. However, the additional bytes we see in the responses are a controversial feature, as they pose a choice of security and performance.