Speed Index UX

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.

schema HTTP vs HTTPS

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.

Start Render Speed Index Number of requests Page size
HTTP 4,611 6831 112 1429
HTTPS 5,704
(+24%)
8108
(+19%)
112
(=)
1515

(+6%)

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:

Start Render Speed Index Number of requests Page size
HTTPS 5,704 8108 112 1515
HTTP/2 5,810
(+2%)
7536
(-7%)
113
(=)
1497
(-1%)

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 Speed Index Number of requests Page size
HTTPS 5,704 8108 112 1515
HTTP/2 + FEO 2,901
(-49%)
5446
(-32%)
61
(-45%)
976
(-36%)

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:

http-https-http2

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.

waterfall HTTP2
As we can see, some resources are already unsharded. But not all. This means that Start Render is delayed (see the green vertical line).
By unsharding all resources (such as fonts), Start Render can be brought forward because of the time saved establishing new TLS connections – and this will only improve the user experience.As you’ve seen, moving to HTTPS doesn’t necessarily mean losing speed, as long as you take the time to understand how your site loads and implement best practice (we can do it for you if you like). Over to you!

Want to delve a bit deeper into your waterfall ?
Download the white paper