the hidden https slowdown no one knows about, adding 1 second to WordPress page load times, and how to fix it

So you have https enabled on your site, or you’re thinking about it. If you are selling stuff – obviously https is a must have. But if your WordPress site is largely marketing – there is the promise of better google SEO rankings for https sites, so more folk are moving to HTTPS.

Before you race to enabling HTTPS, here are a few things to think about:

1. Your google SEO rankings will tank for a bit (I’ll write about that soon).
2. It’s difficult to get your WordPress theme/plugins/content moved to https (see mixed content)
3. It will slow the first page load – which is what this post is about.

There is 3 places https causes a slow down, here is an image of the slowdown I’ll refer to:

In the worst case scenario, if your hosting is in the US, this adds around 1 second to your web page loading speed, and 1 second to your time to first byte (ttfb).

This is the test details from http://www.webpagetest.org (if you want to test your own page – make sure you put https:// in the test url).

1.HTTPS/SSL negotiation

Some folk know about HTTPS/SSL negotiation. It’s the quick chat your browser does with the web server.

The SSL negotiation is purple above. It’s only 50ms ( 5/100ths of a second on this site). But the hosting is in Australia, and the test is from Australia.

This gets to 300ms (0.3 seconds) if your hosting is in the US, and your user is here in Australia.

And caching plugins can’t help this.

2.HTTPS certificate checking/authentication

HTTPS is based on a chain of trust, your browser trusts certain certificates and needs to check others. So In the example above – the ocsp.comodoca4.com – is the certificate check. And yep, that’s 740ms (0.74 seconds).

And that is a cloudflare certificate – adding nearly 1 second to the page loading time. Again, you can’t cache this, or speed it up.

If you know anything about WordPress web page performance, you’ll notice this added directly to ‘time to first byte’ ttfb – which is a killer for SEO and usability.

3.Loading of additional assets

I didn’t screen capture this one, but the browser starts a few more threads to download others assets faster (like jpg/css/js).

The additional threads don’t all do a certificate check, but they incur the https/ssl negotiation again (see 1 above). So this time delay can be caused multiple times.

What can you do about it ?

You can do a few things

• move your site to hosting in Australia – a CDN doesn’t really help WordPress with this SSL slowdown
• ask your host to enable OCSP stapling
• use our new wpImmortal product – which artifically moves your site to Aussie, supports OCSP stapling, and you don’t need to move your hosting.

There is a super smart config called ‘ocsp stapling’  – this is so rare, most hosting companies won’t even know what your talking about.

You can check your site here for OCSP stapling : https://www.digicert.com/help/ , here is what you’re looking for:

With everything super optimized, this is how the speed test looks like. Things to notice:

• no certificate check at all – because of OCSP stapling
• the purple ‘SSL negotiation’ is pretty slim (about 40ms) – as it’s our super fasting hosting on https://www.wpdone.com.au
• the super cool ‘Visually Complete’ in 1.683 seconds.

By Scott Farrell on April 26th, 2016 , Follow @scott_WordPress Tweet to @scott_WordPress