[UPDATE: This article was taken into consideration by Magento; the fix for Full Page Cache under HTTPS that Akoova made public, was included in the Magento Enterprise Edition 1.14.1 release note. The “Acknowledgments” section at the end of the linked page, includes two contributions from Akoova, including the fix for “full-page cache with HTTPS”. One less problem for adopting HTTPS on your whole Magento EE site.]
Are you thinking of having your entire site on HTTPS? Hold you horses!
Do you have an e-commerce site running on Magento Enterprise Edition with Full Page Cache? Or even Magento Community Edition with a Full Page Cache on it? Then keep reading.
Is your SEO agency / ninja telling you to move to HTTPS sooner rather than later? Tell them to give you a break and fully understand the implications.
On the 6th August 2014 Google announced HTTPS as a ranking signal and encourages website owners to switch from HTTP to HTTPS. Why? Because Google wants to make Internet safer. That’s fair enough, we owe it to our users to protect the security, privacy, and integrity of their data and Google led by example by rolling out HTTPS on all of their services.
For now HTTPS is only a lightweight ranking signal. With time it will carry more weight, while Google gives webmasters time to switch to HTTPS.
So at some point, you will want to make the switch to HTTPS, not only because it will help your site’s ranking, but most importantly because it will be faster and safer for your users.
Plan carefully or you will fail miserably
Below I explain:
- Why HTTPS is bad for Magento Enterprise
- Why HTTPS increases Page Load time
- Why HTTPS on CDN can be expensive
- How secure connections can actually reduce Page Load time
- The challenge ahead
1) HTTPS for the whole site stops Magento Enterprise’s Full Page Cache from working
the response time will slow down significantly and with enough visitors your site might crash down.
Please use Akoova’s free fix on Github, to make sure your Magento EE’s Full Page Cache will continue to work under HTTPS: https://github.com/akoova/EnterprisePageCacheSSL
2) Page Load Time will be slower
Hold on Google! You penalise a site if it is not using HTTPS, then if HTTPS is used it will slow down, and you penalise a site if it is slow! Sounds like dealing with a city hall!
When requesting a page via HTTPS all the resources, such as images, CSS, JS etc…, also need to be requested under HTTPS, to avoid those warning, which none of us wants to see, right?
Each HTTPS request has an overhead, caused by the encryption handshake that means additional round-trip for each HTTPS request.
Let’s use the logo of Paul Smith’s e-commerce site based in UK and let’s see the difference between an HTTP and HTTPS request. I’m using a free tool called WebPageTest.
I test from London, to reduce the possibility that the result is biased by network latency.
https://cdn.paulsmith.co.uk/skin/frontend/paulsmith/unicorn/images/logo.png
http://cdn.paulsmith.co.uk/skin/frontend/paulsmith/unicorn/images/logo.png
First byte in 0.152s – Can you see how much time is taken by the SSL Negotiation step?
Now imagine having this delay on 100 resources of a typical e-commerce page, and you can see how the SSL Negotiation step can easily adds up 0.5s to 1s to the Page Load, too bad! As a reader correctly pointed out, browsers reuse existing SSL negotiations to avoid repeating that process. What I should have clarified is that the problem with typical e-commerce sites are the 30% – 50% of external resources used for tracking, retargeting, Facebook, Google, Kissmetrics, Doubleclick, analytics, you name it. Each one of them come from a different domain, needs to be served via HTTPS; hence each one requires its own SSL negotiation.
Here is what it looks like on Tribesport, an e-commerce site completely under HTTPS.
Can you see those annoying purple color stretching the bars? Those are SSL Negotiations.
Clearly, having pages served via HTTPS will slow down the Page Load.
However, if you can defer the loading of those 3rd party resources after the page is loaded, you can improve performance considerably and this should be done regardless of HTTPS. In fact most of Page Load performance issues are due to those type of requests delaying the Page Load.
3) SSL certificate on a CDN is more expensive
You need to pay to obtain an SSL certificate.
If you use a CDN for your static content, most probably you are sharding assets, that is using different domains. With Magento you can go as far as:
- www.site.com – for the main request
- media.site.com – for the media assets
- js.site.com – for the JavaScript (if not merged)
- skin.site.com – primarily for the CSS (if not merged)
In order to have all of the above under HTTPS you either buy an SSL certificate for each one of them or buy a wildcard certificate, that will cover everything directly under the main domain site.com, which is more expensive than an individual SSL certificate.
It does not stop here. Certain CDN providers can charge you a hefty fee for installing your SSL certificate on their end points. AWS CloudFront, for instance, charges $600 per month for each custom SSL certificate!
But there are two ways around it, if using CloudFront for secure connections. This is important for you to know, regardless of this specific topic, because you might want to use the CDN for secure pages such as checkout.
- Use the original cloudfront.net domain name, it comes with free HTTPS, e.g.: https://d28xifl381rdzo.cloudfront.net/
- Use SNI Custom SSL, which allows to install your own custom SSL certificate without the need of a dedicated IP address. However, SNI is not supported by old browser.
At Akoova we use media.site.com for the media assets and static.site.com for both JS and the Skin folder (e.g. CSS). For secure pages, such as checkout and the account page, we use the https://X1Y2Z3.cloudfront.net/.
However, if the site is served solely via HTTPS you want to use the above sharding, in order to keep SEO juice of your image content within your main domain, site.com. Matt Cutts clearly stated in 2012 that Google treats subdomains like subdirectories. Do not give SEO juice away to cloudfront.net.
OK, so far we know that using SSL for your whole site can be a hindrance and cost you money. Google then is telling us to spend more money to slow down your site. What a bunch of nice folks they are!
4) HTTPS can be fast
Here is the thing, secure connections can be fast, by using SPDY, a secure protocol developed primarily at Google. After the initial handshake round-trip overhead, the content flows through one single connections between the browser and the server. The server might even push content or give hints to the browser instead of awaiting individual requests for each resource of a web page. In a nutshell, SPDY is a clever tunnel that reduces Page Load time.
Using SPDY makes sense if:
- The page and all of its resources are all served through the same domain, e.g. https://www.site.com/, which means
- no CDN is used
- a CDN supporting SPDY is used as an App Accelerator for the initial page request and for the static resources
- a CDN supporting SPDY is used for static resources delivered via a different domain, e.g. https://media.site.com/ – you would loose the Server Push and Hints capability to speed-up the page delivery.
For performance and scalability reasons, we wouldn’t want the servers running Magento to serve all of the requests, including static resources.
Ideally we would make use of a CDN supporting SPDY. Remember, without SPDY support, the CDN would slow the Page Load down.
Now here is the problem. Only a few CDN providers support SPDY (below is a snapshot, for the most updated chart go to istlsfastyet.com):
And also consider that support for SPDY is limited to Google Chrome and recent versions of Opera and Firefox browsers. Here is a list of modern browsers supporting SPDY. In case a browser does not support SPDY, it will fall back to standard HTTPS.
Akoova runs on Amazon Web Services to liberate online retailers using Magento from the headaches of performance, scalability, security, managing infrastructure etc… We’ll put pressure to our partners AWS to support SPDY sooner rather than later. The alternatives are not that great. Akamai is crazy expensive, CloudFlare (which we used in the past) had high level of performance variability, especially on peak times, MaxCDN does not match the the global reach of AWS’ CloudFront.
We’ll make sure our clients can count on us to receive the best advice, service and solution, without lifting a finger.
