SiteGround SuperCacher Now Running on NGINX with SSL Support!

Since we launched our SuperCacher system back in 2012 it has undergone many changes, but never as big as this one! Although the interface in your cPanel and WordPress/Joomla/Drupal extension looks and feels the same, under the hood we've practically replaced the engine of the service switching from Varnish to NGINX.

Why replace Varnish with NGINX?

We built our SuperCacher on top of Varnish because at the time that was the most flexible and robust solution that could accommodate the diverse needs of the websites we host. It allowed us to provide caching for various different apps and website configurations. Also, since we use Apache as a web server, that was the most clean and stable implementation possible. At that time, we were among the first companies to have a reverse proxy service for our customers with an easy to use interface, and the option to exclude URLs from the cache without having to contact the hosting company.

However, few years later, we've started experiencing some limitations to the configurability of this system. One of the major downsides of Varnish is the inability to cache https requests. Furthermore, the project leaders stated officially there are no plans to add this functionality. Needless to say, with Google announcing that they will rank sites with SSL certificates better and the great growth in E-commerce sites we host, the inability to cache pages over https became an issue. On the other hand, the NGINX technology has great SSL support and offers numerous speed and stability improvements which naturally led us to its adoption.

What’s in there for you?

The switch from Varnish to NGINX brings to you two main benefits:

SSL Support

Until now, our SuperCacher wasn't serving cached content to any https requests. This means that all encrypted pages on your site were 100% dynamic. For example, if you force your SSL certificate to be used on every page of your site, this means that you've practically disabled the SuperCacher. Now, with NGINX we can and do cache those pages (if you have the SuperCacher enabled).

However, there are pages that should not be cached at all - checkout, shopping cart, profile pages, etc. Shopping carts are most vulnerable to such issues because they store a lot more sensible information than a regular news or blog website. That's why we've added rules to our configuration that exclude those pages from the cache. Although we've covered all the popular extensions for online stores, we recommend that you exclude those pages manually from the SuperCacher plugin configuration just as an extra precaution.

To sum up, you can now force your entire site through SSL even if it's not an online store and rest assured that it will be super fast and stable without having to do any reconfiguration to the SuperCacher.

Improved Performance and Stability

To begin with, it's much easier on our end to manage, update and secure an NGINX reverse proxy. The service is even more stable than Varnish and needs less custom coding in order to work great for SiteGround customers. This allows our administrators to easily update and keep the service as secure as possible.

In addition to that, with NGINX we've enabled SPDY for the SuperCacher users. This and the difference in the service architecture itself results in even better performance than the one we've been getting out of Varnish. Practically, this means that some of your sites (it really depends on the particular page) can load even faster.

How did we migrate from Varnish to NGINX?

As usual, we didn't want to interrupt our customers' workflow or cause any downtime whatsoever with the changes we're doing. That is why we've done the switch in a few steps.

First, we launched a new version of the SuperCacher plugin for the supported applications. We gave our customers enough time to update to the new plugin version. Meanwhile, our technical departments were doing final tests of the service.

Once we detected that almost all our customers use the latest SuperCacher application extension, we started switching Varnish with NGINX on our servers. At this point the SSL cache was not enabled yet. We wanted to be 100% sure that everything is working fine before introducing this change. As usual, we didn't push it on all our servers at the same time but gradually increased the number of servers with the new configuration. I am happy to say that we didn't have any major issues during that process and it went as smooth as possible!

Finally, we enabled the caching for SSL pages. Again, no plugin update or any configuration was needed for this - it just works out of the box. So if you have an SSL certificate on your website and the SuperCacher enabled - just sit back and enjoy the improved performance of your website!

Enthusiastic about all Open Source applications you can think of, but mostly about WordPress. Add a pinch of love for web design, new technologies, search engine optimisation and you are pretty much there!

61 Comments

Thanks for explaining the switch Hristo. However, it should have been explained before that SuperCacher wasn't caching SSL-enabled pages. For all my sites with SSL, I force it on all pages - so without my knowledge, had disabled caching. There should have been an explanation accompanying SuperCacher activation.

And since you're pushing on SSL, are you going to fix staging to cope with SSL-enabled sites? I have to manually migrate SSL sites to staging and back at the moment. Is there an ETA for making staging work with SSL?

Acutally, since its launch, the SuperCacher has never been caching SSL pages and that was stated in the old documentation. So, in your case, the caching wasn't working in the first place. Are you experiencing improvement in your speeds now? There should be a pretty big improvement...

As to your other question, patching the Staging tool to work with SSL is in the queue. However, most probably we will forcefully disable the SSL on the staging copy and enable it on push since it's really not a good idea to have a certificate for your staging domains(at least, you will need a wildcard SSL, otherwise you will get errors) but no matter what we will make sure the process is fluent and straight forward.

August 9, 2015 / 01:07SnippymediaSiteGround Team

I'm not sure about the accuracy of this article at all considering the siteground support team just replied to my support ticket telling me that the supercacher does NOT work with SSL (https) at all. Please clarify, because this was the whole reason I signed up for sitegrounds services, although to be fair I'm much happier than I was with godaddy.

August 10, 2015 / 05:58Hristo PandjarovSiteGround Team

I am not sure what you've discussed with our Support / Sales teams but the SuperCacher now successfully caches SSL requests 🙂

August 12, 2015 / 00:06Snippy MediaSiteGround Team

I asked support why the supercacher plugin gives me a warning that the https site is NOT cahced when I am logged into the admin area using ssl, and they told me it doesnt work with ssl.

August 12, 2015 / 00:44snippymediaSiteGround Team

**update**
I have figured out the issue, using softaculous I was able to edit the installation to reflect the https url and as a result that same url has been updated in the supercacher. I wish the technicians would have been able to figure that out and explain it to me properly, but instead they told me it would not work with ssl. It works great now, loving the supercacher. Problem solved.

The SuperCacher does not serve cached content for logged in users. This means that your logged in users will see completely dynamic content and won't benefit from the speed boost the system provides. However, it's still a good idea to enable it because not all of your visitors have accounts and I think that if those who haven't yet subscribed to it load your site faster, that's a good thing 🙂

June 26, 2015 / 03:20Leho Kraav @lkraavSiteGround Team

@hristo regardless of caching content, are we getting HTTP/2 / SDPY boost on connections for logged in activity?

Hristo, are you saying that logged-in people completely bypass nginx? Loading resources over HTTP/2 and caching are two different things that don't necessarily need to be coupled to each other.

June 30, 2015 / 05:42Hristo PandjarovSiteGround Team

Yes, if you're logged in, you get completely dynamic content. We simply don't want to cache content, disaplyed to logged in users. There are multiple reasons for that but mostly we don't want to risk showing cached content with personal/sensitive information to the incorrect user.

July 8, 2015 / 14:05DerekSiteGround Team

Just to clarify then about disabling the SuperCacher on specific pages due to the risk of "showing cached content with personal/sensitive information to the incorrect user," should we disable the SuperCacher on any page that has a form (e.g. WP/Gravity Forms) collecting personal/sensitive information?

Do I perform this simply in the "Exclude URLs From Dynamic Caching" section of the plugin?

July 9, 2015 / 00:54Hristo PandjarovSiteGround Team

No, if it's a simple form that people use to submit information, that's ok, there isn't risk of showing incorrect content. However, if you display info like personal details, addresses, etc. you can add those urls to the exclusion list to make sure they are completely dynamic.

Cloudflare caches only the static content of your page. Although the dynamic caching will not work with it, I would recommend you to try enabling the Memcache part of the SuperCacher service plus Railgun for Cloudflare.

June 26, 2015 / 10:17WimSiteGround Team

Thanks, but these settings seem to slow my site down.

June 28, 2015 / 23:46Hristo PandjarovSiteGround Team

Have you tested if you're actually caching those pages and how? Probably something's not configured correctly.

The W3TC plugin provides all sort of different optimization techniques. I would recommend that if you use it for caching only to disable it completely and use the SuperCacher. It's WAY faster than anything you can accomplish with a caching plugin.

On the other hand, if you use W3TC for things like CSS and JS minification for example, you can safely leave it and continue using those. Just make sure you disable all the caching options from the plugin so you don't end up double caching content.

Part of what I am trying to figure out is WP Rocket also helps to tie MaxCDN's service into my site's caching functionality and domain sharding functionality.

I don't want to lose my MaxCDN CDN and sharding benefits but I don't want to be negatively impacted by double caching my content.

Any suggestions you might be able to provide?

July 11, 2015 / 07:48Hristo PandjarovSiteGround Team

All you need to do is disable the file caching by WP Rocket. Everything else will work just fine. You can do that by using this filter:add_filters( 'do_rocket_generate_caching_files', '__return_false' );

January 20, 2017 / 09:22ManoloSiteGround Team

> You can do that by using this filter:
add_filters( 'do_rocket_generate_caching_files', '__return_false' );

Regarding optimization and compression, I would like to see SiteGround implementing WebP on their servers.

Cloudflare lately have been causing too many issues on live sites, both Joomla! and WordPress. After a week often displaying 404 error pages on a daily basis, I have decided to reset the NameServers back to SiteGround. After the change was made, few minutes after, both my sites on Joomla! and WordPress became fully responsive, faster and more productive.

W3TC plugin seems that lately was somehow abandoned. There are plenty of complaints regarding their service as well as incompatible issues with other plugins that were never fixed. I am using WP Rocket, which so far as done wonders to my WordPress installations, besides the fast and professional support backed by them.

I currently output all assets fully embedded in the html.
That's inlined SVG, CSS and JS.
Would I expect to see improved performance via SuperCacher and / or Cloudflare?
Or would improvements rely on using multiple http requests?

Those are completely different things. The SuperCacher will serve your HTML output faster. Way faster. The ammount of time your output requries to be rendered depends on your code and the physical size of the resources you're using.

Everything will work the way it was working before that change with the only difference that we will cache suitable pages through SSL. This said, you can configure Joomla the way you want, just make sure SuperCacher is ON 🙂

That's a bit flattering to be honest, because it means our hosting is so fast that you haven't realized your caching mechanism is not caching :)The update applies to all packages, we've completely replaced Varnish with NGINX. You see Apache, because we're using NGINX on top of it in its reverse-proxy part only. In your case, everything should be working now. Open a new browser, Firebug, networking section and reload your page (make sure you're not logged in). Check the headers your site returns. If you see X-cache: HIT, this means you're loading cached content. If it's a MISS then it's dynamic. That's the most accurate way to test which page is cached and which not.

Wow... This is actually messed up. You should have made it MUCH more clear that SSL wasn't working along-side SuperCacher... I had absolutely zero knowledge of this, and shouldn't have to read a documentation to find this out. Don't hide stuff like this, it makes you look bad, SiteGround.

All this time, I thought my site was being SuperCached, when really it just... Wasn't.

Anyway, good news. Thanks for informing us. Make sure to inform us of bad news too though - like SSL not working on the old SuperCacher platform, for example.

There aren't "old Super Cacher" platforms 🙂 Everybody got the update and we've completely moved from Varnish to NGINX. I am sorry that you feel this way about this, it was never our intention to hide this fact. We've been always clear we're using Varnish for this system and probably just assumed people know it doesn't cache https... Note taken, though, we will do our best to be as clear and detailed as possible for such services.

However, I am having a problem with the dynamic caching. My website is e-commerce and I have a shopping cart on every page. This is being cached and therefore I can't delete products from the cart after being added.

Depends on the application you're using. For example we've done it for EDD to show dynamic content each time when there is something in the shoping cart. Please, mail me at hristo.p at siteground dot com and I will look into it 🙂

Hi Hristo
Are you able to post some url's on here of websites which are joomla sites which are configured to use the Super Cacher? (or perhaps email me one or two if posting on here is not possible). I would like to see what kind of server response time they have. Thank you

Hi,
How about the Supercacher for Magento? When can we expect an update there? It's still not available in my cPanel.
It's been months now that you disabled the old one ... but I'm still waiting for any news on the new one ...
So I'm a bit frustrated to read about this "good news show" knowing that the old one was suspended without having a replacement.

Thanks for this info Hristo.
I was just looking through info on speeding up site.
I spoke with support...but want to make sure that I have gotten it correct.

if going with supercacher: enable the 3 options (static.dynamic,etc.)... then do not allow for the google page speed. (this is what I have done for max speed).
Then obviously if using ssl this is now accommodated for.

If I have a plugin, need to find out if it is minimizing things (other than simply caching info), then somehow disallow the caching part (so no double caching) (was thinking of using hypercache extended plugin). Otherwise if it is only caching, might as well delete plug in.

That's definitelly not a normal behaviour, the https version of the site should be indistinguishably slower than the non-encrypted version. Probably something is not working correctly via https? I will mail you for more details so I can take a look at the site and tell you what's wrong 🙂