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:
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 sensitive 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!