Page caching is important for the performance of your WordPress website. Here’s how to configure WP Super Cache to serve up your site’s content from the cache, without bogging down your server.
Caching improves performance by serving up content that has been already assembled. There’s a few different levels of caching — browser caching of static files like images and scripts; a CDN like Cloudflare or CloudFront; object caches like memcached or redis that remember data pulled from databases; and page caching where the HTML content of a page is stored so that it can be served up again quickly.
WordPress can do quite a bit of work creating a page, from making a bunch of database queries for the content on the page, to loading and processing the templates that pull the whole page together. A page cache takes the HTML generated by that process and stores it so that it can be given to the next visitor to the page. That frees up the server to handle more requests for pages that haven’t been cached.
There’s a bunch of different options for page caching in WordPress. Some servers offer caching through a reverse proxy like Varnish or nginx, handling the page cache completely outside of WordPress. The simplest way to get page caching on WordPress, however, is with a plugin. There’s a bunch of them too, but I like the simplicity and speed of WP Super Cache. It doesn’t try to be everything, and so it’s pretty easy to set up effectively without breaking your site!
As soon as you install the plugin and enable caching, it starts making your website faster for anonymous visitors. That last bit means website visitors who are not logged in; logged-in visitors (which are called “known users” by the plugin) don’t get cached pages, which is usually what you want.
To get the most out of WP Super Cache, you need to change a few settings. Most of these are on the Advanced settings page for the plugin. If you’re ready to turn up the power, go to the Advanced tab and change the Cache Delivery Method to Expert.
Delivery method: fast or super-fast
The plugin has two different delivery methods for serving up cached files:
- PHP: a small piece of WordPress is loaded to determine which cached file to serve the visitor
- static: some web server rules serve the cached file without any PHP running
Which method you get depends on how you set up the plugin. The first method handles lots of special conditions that you can enable in the settings. The second method only handles simple anonymous visitors, but it’s a lot faster.
When you leave the Cache Delivery Method set to Simple, cached files are served from PHP. It already handles some special conditions, so you don’t need to worry about the performance trade-offs you get when you change the advanced settings. But that’s not why you’re here, is it?
Go ahead and change it to Expert. I’ll run through the important settings that will get you that faster website very simply.
You should tick the following options:
- Don’t cache pages for known users
- Don’t cache pages with GET parameters
- Cache rebuild
You can safely leave the other settings unticked for most websites. With these settings, your site should be ready to serve files using the static method, which is the fastest method.
Updating the rewrite rules for static delivery
After changing these settings, and some of the other settings, you’ll need to update your rewrite rules. These are web server rules that tell the server where to find your cached files so that it can serve them up without loading any of WordPress.
Most websites are running Apache and can use website rules in a .htaccess file in the root of the website. The plugin can automatically update the rules for you; you just need to press the button!
If your site is running something else like nginx, the plugin won’t show you that button and you’ll need to update your static cache rules yourself. There’s some example nginx rules for WP Super Cache in the WordPress Codex.
The gory details: known users
If some of your visitors can log in, you probably show content a little different for each user. For example, some pages might show the visitor’s name or some other details specific to them. It can even be as innocuous as a Login link that changes to a Log Out link when a visitor logs in; anonymous visitors will see a Login link in the cached pages served to them, but logged-in visitors won’t get that cached page. There are other options that let you customise how logged-in users are treated, if you have a good understanding of how your site works. Most sites work best if you don’t cache pages for known users though.
The gory details: GET parameters
If you have a search form or product selectors that add search keys to the end of your site URL, you can get a lot of cached files unless you tick this option. It can still be useful to cache those files, because visitors who search for the same things will get served the cached files. However, if you allow searches to be cached, you’ll probably find that most of what gets cached is stuff that search bots and other robot scripts have requested. That chews up server resources, both file space and the memory and CPU required to build the files. In most cases, it’s best to turn off caching for requests with GET parameters.
The gory details: compress pages
This setting is a recommend setting in the plugin, but I’d suggest you turn it off. Compression takes time and CPU. Wherever it happens, and you want it to happen, you want it to use the least resources. When you’ve set up WP Super Cache to make use of static files, using rewrite rules to deliver cached pages, Apache or nginx can handle the compression for you if it’s been configured to compress HTML content with gzip. If you let the plugin do the compression, that will keep WordPress loaded in memory a little longer for each uncached page, and memory is a precious resource on a server. Let the web server deal with compression, so that WordPress can release its memory sooner and reduce the load on the server.
The gory details: HTTP headers
When the plugin caches HTTP headers as well as the page content, it can’t use static file delivery and has to use PHP delivery. This is a trade-off between faster cached pages and additional headers added by plugins. If you use plugins that send extra headers, e.g. for additional security options or functionality, you should tick the option for caching HTTP headers. Otherwise, leave it unticked and enjoy faster cached pages.
In the Advanced settings section, you can safely leave them all unticked on most websites, except for one of the following two settings:
- Clear all cache files when a post or page is published or updated
- Extra homepage checks
On sites with not too many posts and pages, I recommend the first option, clearing all cache files when there’s a change to any content. This will ensure that menus and widgets on all pages will show changes to the website. When I’m setting up a site for a new client that isn’t familiar with WordPress, I usually pick that setting.
On sites with lots of posts or pages, I recommend the second option, extra homepage checks. I make sure that the people editing the website understand what the page cache does and how to clear all pages from the cache, but generally it’s best to let the cache update in its own time and keep the page cache full. Removing all pages from the cache every time there’s an update can mean there’s often nothing in the page cache, which is pointless.
The gory details: mobile device support
If you tick this option, some extra rules are added to the .htaccess rewrite rules that stop static files being delivered to mobile devices, forcing PHP delivery. If your website’s theme and plugins use responsive CSS to accommodate mobile devices like phones and tablets, you don’t need to tick this setting because the content for desktop and mobile devices is the same. If your theme or one of your plugins sends different content to mobile devices, then you need to tick this setting so that WP Super Cache doesn’t send desktop content to mobile devices.
- responsive CSS theme? leave it unticked
- different content for mobile devices? tick it
You can generally accept whatever WP Super Cache has detected for your website. You need to have a good reason to change this setting!
Expiry time and garbage collection
You want pages to be cached for as long as possible, but you also want your pages to reflect any changes made to the website. When you edit a page or post, its cache is deleted, but all of the other pages and posts that have been cached will stay cached — unless you ticked the setting for clearing all cached files on updates. If there’s a plugin update, generally the cache is not cleared, so any changes from that update won’t be seen on cached pages.
To handle that, WP Super Cache will expire cached pages after a while, and delete the expired ones periodically (at least daily). The expiry time is in seconds, and by default it’s pretty short. I recommend setting a longer expiry time, at least two days (172800 seconds). You can make it even longer, like ten days if you like. If you ticked the setting for clearing all cached files on update, you might as well make the expiry date longer.
Next, you should set a time for the plugin to check for expired cached pages. I recommend making it daily, in the wee hours of your site’s operation. To do that, change the Scheduler setting to Clock and set a time in UTC, then change the interval to Once Daily.
Accepted filenames and rejected URIs
There might be some pages on your website that you don’t want cached. For example, the shopping cart, checkout, and account summary pages on an ecommerce site must not be cached so that any changes are reflected for each customer — and customers can’t accidentally see each others’ purchases and account details.
You can use the settings in this section to stop certain post types, archive pages, feeds, etc. from being cached, or specify parts of their URL to prevent caching. The plugin comes with some basic sensible defaults, and many plugins already tell WP Super Cache which pages not to cache, so you might never need to change this section. For example, WooCommerce and Easy Digital Downloads prevent WP Super Cache from caching the cart, checkout, and account details pages already, and many cart widgets use Ajax to keep up to date even on cached pages.
I recommend that you check your site for pages that should not be cached, and then check to see whether they are being cached or skipped. If you have debugging turned on, you can view the page source in your browser (Control-U / Command-U) and it won’t have a WP Super Cache at the bottom if it wasn’t cached. And don’t forget to be logged out when you do your tests!
Rejected user agents
By default, WP Super Cache won’t cache pages requested by search engine spiders and other robot scripts that scan your website. I guess that makes sense in some situations, where creating a page cache can take time and resources, like sites with files on network drives.
For most sites, however, those bot requests would be a wasted resource if they didn’t cache your pages for you. Bots hit sites all the time, and many will scan every single page and post on your website, every time they visit. If one bot scans your whole website and doesn’t create cached pages, the next bot that visits will work your website just as hard doing the same thing. It makes more sense to let WP Super Cache create cached pages when bots visit.
Delete everything in the rejected user agents field and save. Let the bots keep your cache full and take some pressure off your website. Make sure that your site has an XML sitemap to tell the bots where all of your pages and posts are — most good SEO plugins provide an XML sitemap, or you can add a plugin for that specifically.
The plugin can regularly scan all the pages and posts on your website to try to keep your cache full, ready for when your visitors get there. That’s a worthy effort, but I’ve already recommended that you let your bot visitors do that for you. They can chew up some CPU and memory churning through the list of your pages and posts for you, so why have your website do that too?
I recommend turning preload off. Set the refresh period to 0 minutes and it won’t run a preload scan.
The plugin adds a few comments into your pages’ HTML, right at the bottom, to tell you whether it cached each page and how long it took to generate it. That’s great when you’re configuring the plugin, but you don’t need it there otherwise. You can turn this setting off, and turn it on only when you need it.
You’ll have probably noticed that I skipped a bunch of settings in the plugin. For most websites, the settings covered here should be enough to get you a nice, fast website for anonymous visitors. That covers the majority of hits for most websites, even for many ecommerce shops. I recommend not making changes to any other settings unless you understand how your website works, and have taken measurements so that you can ensure your changes are worthwhile. Otherwise, stick with the simple settings above.
This post was inspired by the 100 or so websites that moved from one host to a better one just before Christmas, requiring a check of their WP Super Cache configurations. They all now have settings similar to the recommendations above. The bots scanned their pages, the caches have been rebuilt, and job is done.