HTTP vs HTTPS performance comparison

Google recently announced that they will be starting to use HTTPS as a ranking signal in their search algorithms. This means that websites that serve traffic over HTTPS with secure, encrypted connections will be slightly favoured over those websites that don't. During Google I/O, there was a big push for "HTTPS everywhere" on the web and while this ranking factor is currently minimal, it is something to consider.

HTTP vs HTTPS web performance

In my mind, I have always associated HTTPS with slower page load times when compared to plain old HTTP. As a web developer, web page performance is important to me and anything that will slow down the performance of my web pages is a no-no.

In order to understand the performance implications involved, the diagram below gives you a basic idea of what happens under the hood when you make a request for a resource using HTTPS.

HTTPS vs HTTP web performance

As you can see from the diagram above, there are a few extra steps that need to take place when using HTTPS compared to using plain HTTP. When you make a request using HTTPS, a handshake needs to occur in order to verify the authenticity of the request. This handshake is an extra step when compared to an HTTP request and does unfortunately incur some overhead.

In order to understand the performance implications and see for myself whether or not the performance impact would be significant, I used this site as a testing platform. I headed over to and used the visual comparison tool to compare this site loading using HTTPS vs HTTP.

As you can see from the video above, using HTTPS did have an impact on my page load times, however the difference is negligible and I only noticed a 300 millisecond difference. It's important to note that these times depend on many factors, such as computer performance, connection speed, server load, and distance from server.

Your site may be different, and it is important to test your site thoroughly and check the performance impact involved in switching to HTTPS.

Can we improve the performance?

After looking at these results, it got me wondering - surely there is something we can do to speed up the initial connection and ensure that future requests are faster? After a bit of research online, it turns out that there are a number of things that you can do that will make a difference. There is a great chapter on SSL in Ilya Grigoriks book "High Performance Browser Networking" that dives a little deeper into this topic. Ensuring that your server is optimised correctly plays an important role in reducing this overhead. This chapter lists a few basic things that you can do to improve the performance by fine tuning your server.

One of the key areas that I found that can easily be adjusted is the Strict Transport Security header. If you browse to a site that is using this header by using the developer tools in your browser, you will see that the Strict Transport Security header looks similar to the image below.

Strict Transport Security

This simple header is great because it instructs the browser to do the HTTP to HTTPS redirection client-side, without ever touching the network. This makes it great for performance because it means that there is one less request for the user to make which in turn significantly speeds up the whole process. If you'd like to know more about this header and what browsers support it, check out

Start using HTTPS today

Using HTTPS on your site can be a great way to ensure that your users are receiving safe, encrypted information. If not configured correctly, HTTPS can be slightly slower when compared to HTTP, but there are steps that can be taken to reduce this overhead. Try and profile your site using the developer tools and sites such as to verify the performance of your website.

In fact, if you are worried about the prices involved with obtaining an SSL certificate, fear not; you can actually switch to HTTPS for free. Provided you are not using the certificate for commercial purposes - certificates for individuals are available for free.

For further reading, I recommend checking out and the slides from the recent Google I/O event.