HTTPS / SSL and it’s negative impact on mobile speed.

white opt

Save the Internet from WordPress speed abuse.

Updated: September 2017

8 minute read

Google edicts! We’re sick of them. The new HTTPS speed penalty is incredible. To us, it’s horrible and appalling. There is a myth HTTPS / SSL Certification makes no increase in page delays. Our testing says otherwise. Read on.

“HTTPS sites also load significantly faster. In a test on HTTP vs, the unsecure version of the page loads 334% slower than HTTPS.” – A3 creative Solutions

“HTTPS did have an impact on my page load times, however the difference is negligible and I only noticed a 300 millisecond difference.” – Dean Hume

The quotes above reveal the foolishness of many people about site security and speed. HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in Time-to-First-Byte information (aka TTFB).

The HTTPS overhead (delay) is NOT due to the encryption. The overhead is due to the SSL handshakes. An extra time-to-first-byte delay of about 400 to 500 milliseconds is typical. Sites that were under 100 milliseconds TTFB are now over 500 milliseconds TTFB. When your performance budget is 2 seconds, that’s 25 percent waste.

HTTPS is slower because it does double the work. A normal HTTP request does a “2-leg” delay for network connections. This a round-trip request and response. With HTTPS, you have 4-legs (2 round trips). It’s 100 milliseconds to travel between the client and the server. That means your first HTTPS request is at least 500 milliseconds. (That’s what were seeing happen.)

HTTPS handshake overhead appears in Time-to-First-Byte information (TTFB). Common TTFB ranges from under 100 milliseconds (best-case) to over 1.5 seconds (worst case). But, of course, with HTTPS it’s 500 milliseconds worse.

Roundtrip, wireless 3G connections can be 500 milliseconds or more. The extra trips doubles delays to 1 second or more. This is a big, negative impact on mobile performance. Very bad news.

So if you use SiteGround 1.2 second TTFB + 500 ms for SSL + 125 ms for CloudFlare redirect = 1.825 seconds TTFB total. Subtract that from 2 seconds and you don’t have much left (175ms). That’s the result on a desktop – not mobile.

To put those times in perspective, a free WordPress theme loads in under only 50 milliseconds.


SSL by Default Usage Statistics
Only 1.9 percent of the top 1 million websites redirect users to a default HTTPS/SSL version. –

Less than 2 percent! Hardly the stampede of panic many bloggers claim. Some are saying 30 percent of the web made the switch. That inflated bump occurred after Wikipedia switched to HTTPS. This shows the impact one powerhouse site can have. The English Wikipedia includes 5,475,729 articles and it averages 650 new articles per day. You can see why it made a statistical difference in HTTPS usage. But that hardly means everyone is using HTTPS.

Google announced using HTTPS as a “lightweight” ranking signal in search algorithms. Google stated if all factors are equal, HTTPS will act as a tiebreaker in search engine results. That was in mid-2014.

Google didn’t get significant compliance after 2 years. So, they incentivized moving from HTTP to HTTPS. Google Chrome browsers started shaming unencrypted HTTP websites. How? With a little “shield icon” in the Chrome address bar. See chart below.

This information is found at

Google Speed-Irony Strikes Again

We admit we love the irony of testing TTFB on Google’s page with online testing tool:

Please note: ByteCheck is a HTTP site – not an HTTPS site. They know the price. Shown above 407 millisecond delay on a Google page. Yes. Even Google’s home page for search has this new delay. Incredible!

Google’s TTFB for their HTTPS-information page is 407 milliseconds. Oops! It could have been less than 100 milliseconds – if they left HTTPS off the site. Is there a monetary or even information transaction on this page? Nope. Sheer waste of speed. Especially for mobile users.

Let’s look at a few more examples:

This site formerly changed hosts to avoid a 1.5 millisecond TTFB. The new host had a TTFB of less than 100 milliseconds. Bravo! But today, after the site owner added SSL Certification, TTFB is 533 milliseconds. We ask: In this case, how much additional TTFB delay is caused by HTTPS / SSL Certification? Does he need SSL? No. He just has email signups. No monetary transactions!

459 milliseconds wasted!

That’s the same as adding a video or podcast player to every single page and post of the site.

If you botch installing HTTPS, you can end up with duplicate content issues. You’ll have both HTTP and HTTPS versions of your page getting indexed. Different versions of the same page might also show up in search engine results. This will confuse your visitors and lead to a negative user experience. HTTPS has a minor effect on search rankings. Producing quality, relevant content is still the most important SEO tactic.

To correct HTTPS problems, you have to do 301 redirects for every page and post of your site. Bummer! It takes time for Google to re-index your website and a certain drop in rankings will most likely happen.

“Don’t make the switch to HTTPS solely for SEO purposes. It’s a resource intensive process and there isn’t a strong correlation between the two.” – Neil Patel

There is no point serving a blog over HTTPS when you have no sensitive data exchanged. Why on earth would Google force you to do it? Why would you favor a secure blog over a non-secure blog, if you don’t exchange any sensitive data anyway?

“My recent profile of my homepage, HTTP vs HTTPS, the average load times were 1.5s and 4.5s, respectively. When looking at the connection details, the big slow down factor was the extra round trips due to the SSL handshake. Mobile browsers over 3G was even worse. The numbers were 5s and 9s, respectively.” – Clint Pachl

Do site owners realize the contradictory nature of Google edicts about speed?

Google’s claim: To help you stay safe on the web, Chrome requires websites to use certificates from trusted organizations. –

The argument is that the website owner is assured they’re going to the right website owned by the right party. In a perfect world, this would be correct. In the world we live in though, it’s incorrect. Not because the certificate doesn’t verify the owner – it does. If a website housing a phishing page has verified HTTPS, it will show the user the lovely green padlock. Everyday users see the padlock and trust everything else from there, even if it’s from a different domain. Deception!

HTTPS isn’t going to stop the spying of anything. The average user doesn’t care. HTTPS is not going to stop websites from getting hacked. Nor the distribution of malware or keeping website owners safe.


You can get an SSL certificate for free. Blog posts debate the value of a free SSL Certificate. But, the costs can shoot up to $1,499/year if you opt for an SSL certificate from a provider like Symantec. You don’t have to provide corporate documentation to get SSL Certification. The authorization may be a simple email. Confirm the email inquiry, and you’re accepted as the authorized domain holder. Can Free TLS Certificates provided by Let’s Encrypt still be hacked? Absolutely. Anyone can get an SSL certificate – including hackers. They can set up a site to harvest information.

SSL Certificates aren’t justifiable for small business owners with limited budgets. Are you a blog owner that only asks for email info from your visitors? You’re better off spending your limited budget somewhere else.

But what if you’re using secure PayPal as a payment gateway? Why do you have to wear the derogatory “Scarlet Letter” on your site’s address bar? Why does a site that’s collecting zero information from anyone need an SSL certificate? It makes no sense at all. If your web site doesn’t have financial transactions, why do you need an SSL certificate?

If you have small, lightweight, 1M page weights or less, stick with HTTP. It’s all you need.

It’s often implied (pure lies?) HTTPS secures your website. It won’t. SSL Certification doesn’t make a web site impervious to hackers. Labeling a site as secure because it has SSL is wrong. In error, users think they’re using a secure site when in reality its not better than before.

What HTTPS will do is deliver the intended good or bad information securely. We repeat “good or bad” information. HTTPS is indifferent to what’s transmitted. Infected websites distribute malware. HTTPS doesn’t do anything to ensure displayed information’s integrity. HTTPS will also deliver manipulated information to unsuspecting website visitors. Installing a Secure Socket Layer certificate prevents man-in-the-middle attacks. That’s it. It doesn’t warn of evil.

An encrypted HTTPS connection doesn’t stop attackers from hacking a website or server. It won’t stop an attacker from exploiting software vulnerabilities. They can still do brute force access. Or cause Distributed Denial of Services (DDOS) attacks.

Encrypting information over HTTPS can be a good thing for some users – but not all users.

If you need speed – and don’t have critical confidential information – forget HTTPS and SSL Certification. Stick with the cheaper and faster HTTP.

PagePipe’s TTFB is 208 milliseconds on cheap shared GoDaddy hosting. No HTTP / SSL Certificate delays added to global load times. Our book sales are handled using secure PayPal transactions.


Steve Teare
performance engineer

Mobile WordPress Speed – without coding!

What others think of us:

"I'm so thankful to you, Steve for helping me throughout. That page loads very fast." Mumbai, Maharashtra, India

by - Faizan Shaikh