SiteGround SuperCacher Now Running on NGINX with SSL Support!

super-cacher-with-ssl-and-ngimx

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!

Product Development - Technical

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

  1. Reply June 25, 2015 / 07:39 MattSiteGround Team

    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?

    • Reply June 25, 2015 / 07:59 Hristo PandjarovSiteGround Team

      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:07 SnippymediaSiteGround 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:58 Hristo 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:06 Snippy 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:44 snippymediaSiteGround 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.

    • Reply June 26, 2015 / 03:21 Leho Kraav @lkraavSiteGround Team

      +1 Matt. I wasn't aware of this either and sales copy most certainly didn't make it particularly obvious.

  2. Reply June 25, 2015 / 09:42 JoukeSiteGround Team

    Thanks for your explanation Hristo. What is your advice for sites where the majority of the content is visible only for registered users (using front-end login)? Enable the SuperCacher or not?

    • Reply June 26, 2015 / 00:01 Hristo PandjarovSiteGround Team

      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:20 Leho Kraav @lkraavSiteGround Team

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

        PS @everyone you want these HTTP/2 indicator addons for your browser

        https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en

        https://addons.mozilla.org/en-US/firefox/addon/spdy-indicator/?src=search

      • June 26, 2015 / 03:38 Hristo PandjarovSiteGround Team

        No, we don't serve cached content to logged in users.

      • June 30, 2015 / 02:37 Leho Kraav @lkraavSiteGround Team

        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:42 Hristo 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:05 DerekSiteGround 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:54 Hristo 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.

  3. Reply June 25, 2015 / 10:05 WimSiteGround Team

    so does supercacher work with cloudflare now?

    • Reply June 26, 2015 / 00:02 Hristo PandjarovSiteGround Team

      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:17 WimSiteGround Team

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

      • June 28, 2015 / 23:46 Hristo PandjarovSiteGround Team

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

  4. Reply June 25, 2015 / 12:07 Heather WoodSiteGround Team

    I am currently using WordPress, and also using w3 total cache for speed.

    Would you advise that I disable w3 total cache. Enable super cacher and be good to go with just that?

    • Reply June 26, 2015 / 00:04 Hristo PandjarovSiteGround Team

      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.

      • July 10, 2015 / 09:36 DerekSiteGround Team

        WP Rocket has listed some compatibility with SuperCacher (http://blog.wp-rocket.me/wp-rocket-2-3-alderaan-2/) and I know you previously made a comment about potential double caching issues before with WP Rocket (https://www.siteground.com/blog/wp-rocket/).

        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:48 Hristo 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:22 ManoloSiteGround Team

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

        where?
        I ve just got Wp Rocket and the GT Metrix improved A LOT

      • January 23, 2017 / 07:01 Hristo PandjarovSiteGround Team

        In the functions.php file of your theme.

  5. Reply June 26, 2015 / 07:50 IreenSiteGround Team

    Great informative post about the update. Thanks.

  6. Reply June 27, 2015 / 16:40 Max FeinSiteGround Team

    This is excellent news SG! Thanks for getting this functionality pushed out so quickly =)

  7. Reply June 30, 2015 / 00:02 Alex de BorbaSiteGround Team

    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.

    • Reply June 30, 2015 / 00:22 Hristo PandjarovSiteGround Team

      WebP is just a file format supported by Chrome and few other browsers. If you want to use it - feel free to do so, it doesn't require anything from your hosting provider πŸ™‚

  8. Reply July 3, 2015 / 15:08 mikeSiteGround Team

    Hi Hristo,

    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?

    • Reply July 6, 2015 / 01:21 Hristo PandjarovSiteGround Team

      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.

  9. Reply July 8, 2015 / 13:07 BryanSiteGround Team

    Can I turn on SuperCacher, if it not already enabled for my wordpress site?

    • Reply July 9, 2015 / 00:53 Hristo PandjarovSiteGround Team

      Yes, of course πŸ™‚

  10. Reply July 8, 2015 / 14:55 John KentSiteGround Team

    hello Hristo,
    It sounds like I do not need to use sprocket anymore? or am I wrong can I achieve even faster speeds with sprocket and the SuperCacher together?

    ~ John

    • Reply July 9, 2015 / 00:58 Hristo PandjarovSiteGround Team

      I guess you mean WP Rocket πŸ™‚ You can keep using it, the plugin handles much more than caching - minification, etc. So it can still improve the laoding speeds of your site.

  11. Reply July 8, 2015 / 16:56 AshtonSiteGround Team

    So how do I use Force SSL on specific pages? Joomla- Under Administrator it says none. Administrator or Entire site. SuperCacher it says on and off!

    Most importantly in layman's terms, can i now add extensions without turning SSL off?

    • Reply July 9, 2015 / 00:56 Hristo PandjarovSiteGround Team

      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 πŸ™‚

  12. Reply July 8, 2015 / 17:26 Ian JacksonSiteGround Team

    I was a bit shocked to find out that SSL pages where/are not being cached - as others have mentioned the marketing material is very quiet about this point.

    Does this update apply to the cloud hosting packages? My sites are still reporting to be on apache. The main reason I went with Siteground was Supercacher.

    All my ecommerce sites give the user the opportunity to login via a modal popup from every page of the site - so SSL is a must.

    Please advise - many thanks, Ian

    • Reply July 9, 2015 / 01:04 Hristo PandjarovSiteGround Team

      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.

  13. Reply July 9, 2015 / 00:31 JodySiteGround Team

    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.

    • Reply July 9, 2015 / 01:07 Hristo PandjarovSiteGround Team

      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.

  14. Reply July 9, 2015 / 01:52 KimSiteGround Team

    Hi Hristo

    And when will this get out to Cloud server owners ?

    Same with the new stats, when will we get that ?

  15. Reply July 9, 2015 / 02:37 EnricoSiteGround Team

    is NGINX already activated? or when will it be activated? Thanks!

    • Reply July 9, 2015 / 03:42 Hristo PandjarovSiteGround Team

      It is πŸ™‚

  16. Reply July 9, 2015 / 05:05 HalSiteGround Team

    Hello,

    Glad to see it's now working with SSL.

    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.

    Is there a fix for this?

    • Reply July 11, 2015 / 07:43 Hristo PandjarovSiteGround Team

      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 πŸ™‚

  17. Reply July 9, 2015 / 06:16 JDSiteGround Team

    Most of my Joomla! sites use RokBooster plugin from RocketTheme and SSL.

    Are there any known compatibility issues with SuperCacher?

    • Reply July 11, 2015 / 07:43 Hristo PandjarovSiteGround Team

      Not that I am aware of πŸ™‚

  18. Reply July 9, 2015 / 09:20 SimonSiteGround Team

    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

    • Reply July 11, 2015 / 07:45 Hristo PandjarovSiteGround Team

      Check out pandjarov.com or tallbox.org, two sites made by me. One is without SSL and the second one uses SSL on all pages πŸ™‚

  19. Reply July 11, 2015 / 04:29 GertSiteGround Team

    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.

    Gert

    • Reply July 11, 2015 / 07:48 Hristo PandjarovSiteGround Team

      I am afraid I don't have ETA on this at the moment. Will sync with my colleagues working on that project and reply again on Monday!

      • July 23, 2015 / 02:14 SebastianSiteGround Team

        Any news regarding to Magento? As Gert said, you always promised that update for Magento too. Why you don't enable the "old" supercacher anymore? It should not only be a feature for Cloud-plans.

      • July 25, 2015 / 03:15 GertSiteGround Team

        Any updates on this? The old Magento SuperCharger is suspended for months now ... At least give us a status. Or enable the old one again untill the new one is ready!

      • July 26, 2015 / 23:44 Hristo PandjarovSiteGround Team

        Pleaes contact our support team via the Help Desk to get more information about the available options for Magento.

  20. Reply August 5, 2015 / 13:35 KennySiteGround Team

    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.

    Am I making sense in this thinking?

    p.s. do most caching plug ins not work with ssl certificates?

    • Reply August 6, 2015 / 00:51 Hristo PandjarovSiteGround Team

      The plugin handles only caching. It will not minify or combine your JS and CSS files. You need additional plugins for that. As to the SSL it was a Varnish limitation which we are not using anymore.

  21. Reply October 12, 2015 / 00:31 DaveSiteGround Team

    With this new change, do you have a set of recommended Cloudflare settings that will work best with the new supercacher?

    • Reply October 12, 2015 / 03:15 Hristo PandjarovSiteGround Team

      You shouldn't have to make any changes πŸ™‚

  22. Reply March 6, 2016 / 01:40 samwardSiteGround Team

    Thanks for this info Hristo. After reading your post and few other articles we were convinced to switch to https. Unfortunately it made out site nearly 50% slower than the https version πŸ™

    As an optimization practice we were looking into OCSP stapling. Is it possible to enable OCSP stapling on the server for our account?

    We have a GrowBig plan. thanks.

    • Reply March 7, 2016 / 00:59 Hristo PandjarovSiteGround Team

      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 πŸ™‚

Reply to John Kent Cancel

* (Required)