HTTPS: the impact on your loading times

Everyone knows that HTTPS sites are more resource-hungry than their HTTP counterparts, and the additional complexity that they bring to server-browser communications can affect loading times. This raises a number of questions: where do the slowdowns occur? How big are they? And what are the solutions to avoid these slowdowns?

Where do slowdowns occur?

It’s true that a few years ago, the process of encryption was CPU-intensive, but today’s processors can cope with it fairly easily.

“TLS/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.”
— Migration de GMail en 2010 – Adam Langley (Google)

“We have found that modern software-based TLS implementations running on commodity CPUs are fast enough to handle heavy HTTPS traffic.”
— Doug Beaver (Facebook)

It seems that the impact on the server is limited.

Plus, it’s very often the case that the TLS termination takes place on dedicated devices (load-balancers, for example) that may have dedicated CPUs for this task (ASIC).

Although the impacts are limited at the server level, adding a layer of encryption makes communicating with your visitors more difficult.

TLS encryption is therefore capable of slowing down web page loading.

How big are these slowdowns?

We performed a few simulations using the WebPageTest tool. We tested the same mobile site under the following conditions: 3G connection, from Paris, using Chrome and a Nexus 5 emulator.

This test shows the impact that TLS has on Start Render (+24%) and Speed Index (+19%). It’s far from minimal!
Of course, the number of requests remains the same and the increase in page size can be explained by content changes (such as ads) and certificate size.

What are the solutions?

1. HTTP/2

The arrival of HTTP/2 resolves some of the performance issues linked to the HTTP/1.1 protocol:

• request and response header compression,
• multiplexing server requests,
• Server Push,
• binary protocol.

It means that waterfalls are much shorter: as Stéphane, our CEO, would say, “Goodbye waterfall, hello wall!”.

When it comes to HTTPS, the biggest thing about HTTP/2 is that it no longer makes six connections to each domain, but just one – which means an end to having to create multiple TLS connections that take a long time!

2. Front-end Optimization (or FEO)

While HTTP/2 reduces the number of connections and can save precious time, this improvement nonetheless remains limited.
Let’s go back to our previous example. Here are the results when you apply HTTP/2:

Here, HTTP/2 has little or no impact. Essentially, HTTP/2 isn’t always any better.But if you combine HTTP/2 with Front-End Optimization (FEO), the result is a lot more positive:

Start Render is cut in half, Speed Index is reduced by 32%, the number of requests falls by 45% and finally page size is down by 36% – non-negligible savings in terms of user experience.

To give you a better idea of these savings, here are some representations of the different loading times:

3. ”Unsharding”

As the name suggests, ‘unsharding’ is the opposite of sharding, which involves artificially increasing the number of domains to increase the number of parallel connections under HTTP/1.1.
Unsharding, then, is rewriting URLs using the page domain. This helps to reduce the number of DNS resolutions or to reuse the website’s CDN for external resources. The aim is to reduce the number of domains used in order to take advantage of HTTP/2’s single connection.
Here’s the waterfall from the above test using HTTP/2.