We just released version 2.7 of our SWIS Performance plugin with the ability to integrate with two popular server-based page caches: LiteSpeed and Varnish. Short version, you can now use SWIS with just about any server-base cache, no additional plugins needed. As an added bonus, SWIS will automatically purge LiteSpeed and Varnish caches when you make updates to your site.
Now, you might be asking, “Wait, why would you want a plugin, in order to use server-based caching?” That’s a fantastic question, and is something I’ve asked also! So let’s see if we can put this fruit basket back together again.
First of all, let’s be clear what we are talking about here. There are a lot of caching systems that can be used on a website. I’ve covered those before, but today we’re talking about page caching. In short, it takes extra time and work to create the HTML for a given page from the PHP code used by WordPress, and your theme, and all your plugins…
So to make things more efficient, we can use a caching system to store the HTML and eliminate all that work (and delay) for faster page loads. The first time someone visits a page, WordPress generates the HTML, and the cache system stores it for later. Next time anyone visits the page, the cache delivers the pre-built HTML, and it’s way faster! You’re likely to see a minimum 5x speed boost, but it could be anywhere from 10x to 50x faster with page caching.
Server versus Plugin
There’s really no way a plugin-based cache could ever deliver cached pages faster than a server-based cache, despite what some might claim. But here’s the thing to keep in mind when using WordPress. Most server caches have no way to talk to WordPress… and so if you update a page or post, the cache will have outdated content. Thus, many hosts will use some sort of plugin to automatically purge the server cache when something gets updated/changed in WordPress.
Most of these plugins simply provide that interface between WordPress and the server cache. They aren’t doing any caching themselves, but some caching plugins have extra functionality as well. Two notable examples are the Breeze plugin from Cloudways and the LiteSpeed Cache plugin from, you guessed it, LiteSpeed. The latter has more options than you can shake a stick at, and Breeze is missing Critical CSS generation to fully optimize CSS loading. SWIS Performance is simpler, and includes all the tools I use for optimizing sites.
Server Caching Fails
But none of that is the point–what I really want to note is that Breeze also does it’s own page caching to supplement the server-side cache. Breeze will keep both in sync with changes in WordPress, but having its own cache serves two purposes. First, it allows it to work on web hosts that don’t have server-side page caching. Second, it helps avoid missing the cache in case the server cache is missing for a given page.
For example, query strings used for tracking marketing campaigns often get cached by servers under two different files (or more):
https://example.com/?utm_source=newsletter&utm_medium=social&utm_campaign=spring_2026If you’re setting up your own server, you can likely account for that. But for the rest of us, a plugin caching system can recognize query strings that don’t need a unique response and deliver a cached page all the same.
We’ve been using this same sort of dual-stack plugin/server cache ourselves due to a couple of these short-comings of server-based caches. One in particular might possibly be unique to WP Engine, but maybe not. Anyway, the main problem we have on this site, is that WP Engine ties the server cache expiration to the Cache-Control header.
That seems fine, until you realize browsers also use Cache-Control headers to determine how long to cache something. When you update content, you want your visitors to see the latest changes. Letting browsers cache pages for more than an hour or so is no good.
Case in point, I was helping someone figure out why their pages didn’t seem to update when they edited them. The culprit? Their browser was caching the pages, because the server had the Cache-Control setting configured for a full week… ugh! To prevent such issues, WPE sets the default cache lifetime to 10 minutes. Unless your site is super busy, that means someone is getting slower page loads than you want, double uggh!
Best of Both Worlds
In order to get the best performance then, we use the same dual-stack approach ourselves with SWIS Performance: server-based caching for more speed, and plugin-based to extend the cache lifetime without worrying about browsers caching pages for too long. This works on hosts like WP Engine, Kinsta, and Flywheel, because they have their own cache integration already. But there are a ton of LiteSpeed and Varnish hosts out there, and we want to be there for them too, to provide a simple and complete solution that works with the server-based cache.
Side note, if you don’t have a server-based cache, don’t sweat it too much. In my side-by-side testing with a local server (to eliminate network latency), SWIS is only about 2-3 ms slower than a server-based cache using Varnish. And they were both under 10ms, so…
Varnish
On Cloudways sites, you can use SWIS to integrate with their Varnish cache automatically. Simply enable Page Caching in the SWIS Performance settings, and you’ll benefit from the same dual-stack setup with automatic Varnish purging. If you’re using another Varnish setup that doesn’t have an integration plugin, we have filters and a drop-in plugin available to integrate with any Varnish cache. If you find a web host that uses Varnish but doesn’t have their own integration, give us a holler and we can look into making SWIS work automatically there too.
LiteSpeed
As I alluded to, the number of options in the LS Cache plugin is a bit overwhelming to me, and I’ve been doing performance and site optimization for over ten years. To be clear, I understand what the settings do, but it’s more than anyone should have to worry about.
To that end, SWIS 2.7 also includes full integration with the page caching provided by the LiteSpeed server. It uses a tagging system similar to the LS Cache plugin, so that the full cache can be purged with a single tag. LiteSpeed does have a wildcard (*) option to purge the entire cache, but that will affect all sites on a shared-hosting setup. Sometimes you might need that, and it’s available in SWIS, but should be used sparingly.
Other Hosts
As I mentioned, many web hosts have their own integration/plugin to auto-purge server-based caches. WP Engine, Kinsta, Pagely, SiteGround, and SpinupWP are ones that I’m aware of, but you can check with your web host if you’re not sure what sort of caching setup your site is using.
In all of these cases (and a few more), SWIS will also purge the server cache anytime you purge the SWIS cache to save you some time. Flywheel has a custom setup where the server-side cache recognizes changes in WordPress automatically, without any plugin or PHP integration. So you can use SWIS there also, but it won’t do a full purge on Flywheel.
Why SWIS?
Truthfully, as big as this might be (and it is), page caching is only one of the things SWIS does to make your site faster. It does the usual things, like deferring JS and CSS, as well as some unexpected things like optimizing and locally-hosting Google Fonts. Then it also gives you full-control over every JS/CSS file loaded by any plugin, your theme, and even WordPress core. Plugins often struggle to only load their files on relevant pages, but with SWIS you can pick and choose what loads where with the advanced controls in “Slim“.
Many plugins promise better speed testing scores, but few focus on making your site faster without cheating or shooting yourself in the foot. That’s our guiding light with SWIS, to give you the tools to do performance right. No hacks or shortcuts, just pushing your site to be the best it can.
