This website uses cookies

Our website, platform and/or any sub domains use cookies to understand how you use our services, and to improve both your experience and our marketing relevance.

CloudwaysCDN — a powerful solution that offers superior performance and satisfied global audience for your business. Read More

Why HTTPS is not for everyone?

Updated on  January 28, 2017

4 Min Read
Reading Time: 4 minutes

A few months ago, Google announced something that made sysadmins lives a bit more tougher by making some changes to its algorithm. It is now programmed to consider whether a site is HTTPS or HTTP.

However, it does not necessarily mean that everyone should switch to HTTPS. This is what Google says on HTTPS:

“You can make your site secure with HTTPS (Hypertext Transport Protocol Secure), which protects the integrity and confidentiality of your users’ data. For example, when a user enters data into a form on your site in order to subscribe to updates or purchase a product, a secure site protects that user’s personal information and ensures that the user communicates with the authorized owner of the site.”

http vs https

HTTPS is useful for sites that collect and transmit personal information. Banks, e-commerce sites, social networks and online schools need to have HTTPS in place to make sure consumers’ sensitive information is protected.

Now, I understand when there is security involved there is no compromise, it should be secured, but lately, this is not what is happening. There is a sense of urgency among people to get their sites completely on HTTPS for the sake of getting improved rankings on the search engine, which I believe is a bit crazy.

HTTPS only protects against a very limited number of site vulnerabilities, specifically wiretapping and man-in-the-middle type attacks—in other words, spying. It makes the NSA’s job of tracking and spying on internet users more difficult. HTTPS does not protect against hackers, brute force attacks, DDOS attacks, cross site scripting, server or other database exploits.

In HTTP, our data travels in clear text. So if I am reading a news post or a blog and that data is sniffed, then there is no harm in it as the sniffer will only be reading the same news. Which is not bad, I think.

Rather than switching your whole site to HTTPS, we need to understand which parts of a website needs to be switched to SSL and which parts carry important user data that we would not want to be compromised. For that, we first need to understand what actually HTTPS is.

What is HTTPS?

Hypertext Transfer Protocol Secure (HTTPS) is a communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in and of itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. The main motivation for HTTPS is to prevent wiretapping and man-in-the-middle attacks. [Source: Wikipedia]

We use HTTPS when there is classified data transmission, for e.g. credit card numbers, security credentials etc. But if you are visiting a news site or a blog in which there is NO classified information, then I believe its a waste of resources to put it under HTTPS.

HTTPS is slower than HTTP and takes more resources.

Image Credits: DifferenceBetween

As you can see in the illustration above, SSL communication is a 5 step process and on 6th step data transmission occurs. While on the http protocol, the request completes in just 2 steps.

Turning your complete traffic over to https will have more bad effects rather than good. Network latency can also be a factor here as a router which transmits 2 million requests would now have to transmit 6 Million requests because the search engines are providing more benefits to HTTPS sites. For me, that is not a good utilization of resources.

To illustrate the difference in speed for HTTP and HTTPS, I have created a small script.


# a basic curler in bash

# usage: urlfile.txt


IFS=$’\n’ read -d ” -r -a urls < $URLS_FILE


until [  $length -lt 0 ]; do

let length-=1

curl -s -w ‘\nLookup time:%{time_namelookup}\tConnect time:%{time_connect}\tSSL negotiation time:%{time_appconnect}\tPreXfer time:%{time_pretransfer}\tStartXfer time:%{time_starttransfer}\n\n\t\t\t\tTotal time:%{time_total}\n’ -o /dev/null ${urls[$length]}


For the execution, I have created 2 URL files, one with HTTP and another with HTTPS.

The first test is with HTTP URLs and we get:

And for HTTPS URLs, we get:

If you focus on the third column, which is the SSL negotiation time, you will notice that the total time increased by around 3 seconds for 5 URLs. Now, imagine how much time a million pages, all on SSL, will take. Astonishing, isn’t it!

To HTTPS or not to HTTPS?

This in no way means I am against SSL. But the point I am trying to make here is that if you have confidential information, only then should you deploy the HTTPS protocol. However, security comes at a compromise of slowing down by a few seconds. Therefore, pick wisely when you are implementing SSL on your website.

But, in any case, you want HTTPS for your website then deploying one is a headache unless you are on Cloudways. Our Cloud Platform allows you to set SSL certificates in just 3 easy steps. Furthermore, you can deploy multiple HTTPS-protected websites on the same server. Interested? Start your free trial now.

Share your opinion in the comment section. COMMENT NOW

Start Growing with Cloudways Today.

Our Clients Love us because we never compromise on these

About The Author

Maaz Shah

Maaz Shah works as System Engineer for Cloudways. His days are spent in tackling technical troubles.

Stay Connected:

Get Our Newsletter
Be the first to get the latest updates and tutorials.


  • Thanks I needed to read that, I run a small nonprofit blog about WordPress, I don’t collect emails or deliver newsletters, I just write about my findings and experiments, and think HTTPS is overkill.