- When you’ve activated Really Simple SSL on your site, in some cases you might notice your site has become slower: this is not caused by the plugin! I specifically built this plugin to be fast: most of the work is done in the back-end, which doesn’t harm your performance.
First, take a look at this independent test: https://plugintests.com/plugins/really-simple-ssl/latest. You will see the test indicates that page speed impact is “insignificant”. This is what I found as well when testing for speed. See for my own test results further in the article. So why is your site slower now?
What most people forget is that when you activate Really Simple SSL, not only are you activating a plugin, but you are now also running your site over SSL! A connection over https is always slower, because of the encryption. A few things to note when checking your speed on SSL:
- You should enable a .htaccess redirect for best speed results
- Third-party resources can have an impact on speed when the site loads over https.
- Speed should be measured without the redirect, over https directly
- SSL always causes a site to load a bit slower, as the server needs to encrypt the data
- The way in which this impacts your site depends on your server, and on the efficiency of the site code
Important: check your site speed without the redirect!
In case you checked the speed for the http url: this will include the redirect in the speed measurement, which always slows down the site, and is not representative for the site speed: most users will start coming in over https. To optimize the redirection speed, enable the .htaccess redirect.
On tools.pingdom.com you can check what parts of your site are causing the delay. Often you will see a third-party script loading very slow over https.
Services or resources from non SSL domains
I’ve come to realise that actually most reported issues are caused by stuff like this:
- Not loading images from domains without SSL. The entire site will wait for a not loading image
- Similar: Scripts for services trying to load over https, while the domain does not have an SSL certificate
- Plugins that do requests to the service domain, but don’t support https.
You can track these down by deactivating plugins, or even switch a theme. Issues like this can slow down your site dramatically. If a service or image is coming from a domain without SSL, you should remove or replace it. I’ve seen not loading images causing a site to load for 10 seconds before the browser finally rendered the site.
More generally speaking, I often see that site speed is much more impacted by third party scripts when these scripts are loaded over https, even when https is supported. To minimize this, you should minimize loading of scripts and services from third parties, or make sure the loading of these scripts is deferred. A good caching plugin can help you with this.
I see a lot of websites using CloudFlare. Strangely, a lot of issues with speed occur on CloudFlare websites, with inexplicable slow response times after a move to SSL. Try deactivating CloudFlare, to see if this helps.
Even without SSL, I rarely see any significant speed benefit from CloudFlare, and a lot of added complexity to website maintenance. If you’re going for speed, you should go for high quality hosting. But that’s a personal opinion 🙂
Actual speed impact of the Really Simple SSL plugin
On the front-end, most of the plugin code is not even loaded. Only two things are running: the redirect, which won’t kick in when the site is loaded over https, and the mixed content fixer. I have tested the mixed content fixer speed impact by saving the time on the “template redirect” hook in a variable, then subtracting that time from the “shutdown” hook, and logging that time 8 times.
- Theme: 2017 default WordPress theme
- Plugins: about 15 plugins random plugins copied from a customer’s site to give the site some “weight”.
- Hosting environment: average budget hosting environment
- 8 measurements
I have first just logged the time while commenting out all mixed content fixer code.
No output buffer, just time between the “template redirect” hook, and the “shutdown” hook. This is as if the plugin is not activated.
Average time delay between the two hooks: 0,187918752
Time between these hooks, with buffering, but no mixed content fixer. This is as if the plugin is fully active, but is just skipping the mixed content fixing code.
Average time delay between the two hooks: 0,183732033
Time between these hooks, with output buffering and with mixed content fixer active
Average time delay between the two hooks: 0,180673395
I’ve dropped the lowest value in the last test, otherwise it would have come out lower than without the mixed content fixer. Which would seem a bit odd.
Though the mixed content fixer of course has some impact, it does not seem to be enough to cause a major speed decrease. Of course, results can be different on other, heavyweight, themes/hosting environments. If you have more test results, measured in the same way, please leave them in the comments. Contact me if you would like the code that I used.
Actions to consider for speed improvement:
- Enable the .htaccess redirect to optimize redirection speed
- Limit the number of external resources (Facebook, Google fonts, hot linked images etc).
- Check your console for external resources that are not or slowly loading over SSL
- Consider using a caching plugin like Fastest Cache or WP Rocket
- Consider moving to a faster server/better hosting plan.
Look at this site: pretty fast!
And take a look at the speed of really-simple-ssl.com. Does it feel slow to you? A test on pingdom tools show it loads in 657 ms, faster then 95% of the sites.