WP Super Cache is a free cache plugin by Automattic, but caching is really all it does.
I’ll show you how to set up the WP Super Cache settings including the Advanced settings, CDN, and plugin tabs. If you’re on the hunt for the best cache plugin to address core web vitals and improve load times as much as possible, look elsewhere (giving you a heads up before we start).
Some settings depend on whether your website is dynamic or eCommerce, whether you’re using shared vs. VPS hosting, and how often you update content and make changes to your site. Make sure you understand what each one does and configure the best settings for your website.
- Caching: On – the whole point of using the plugin.
- Test Cache: test the cache to make sure it’s actually working.
- Timestamps don’t match: if you get the error “The pages do not match! Timestamps differ or were not found!”, try disabling HTML minify in Cloudflare and purge the cache.
- Caching: Enable caching.
- Cache delivery method: Expert – this is faster than simple mode with less chance of CPU spikes since it bypasses PHP and requests are lighter (described on the plugin page). Once this is turned on, scroll down and click “Update Mod_Rewrite Rules.” WP Super Cache will automatically modify your .htaccess file and show you the message below. If it fails, you’ll need to edit the rules yourself which you can do directly in WP Super Cache. And if that fails, use simple mode. NGINX users will need to take a few extra steps to use Expert mode. Also note that some settings (such as dynamic caching) are only available in simple mode.
- Cache restrictions: Disable caching for logged in visitors – logged-in users need to see unique data, but if there’s caching, they may not see it. That’s why this is recommended.
- Don’t cache pages with GET parameters: On – same concept as above. When you have query strings such as ?country=sweden, don’t cache them since these pages are dynamic.
- Compress pages: On – uses GZIP to compress pages, although if your host supports Brotli, you should use that instead since it’s more effective at reducing the size of pages.
- Cache rebuild: On – if the cache is being rebuilt and is unavailable, the old cache file will be used until the new one is created. This not only ensures visitors get a cache HIT, but it prevents CPU spikes since uncached pages won’t be served (which use a lot of resources).
- Cache HTTP headers with page content: caches content using PHP scripts but is only available in simple mode (which is slower). If using simple mode, you should turn it On.
- 304 Browser caching: only available in simple mode. In this case, you’ll want to turn this On. Browser caching speeds up your site by storing common files in the visitor’s browser.
- Make known users anonymous so they’re served supercached static files: Off – this overrides “disable caching for logged-in visitors” and should generally be left disabled.
- Enable dynamic caching: only available in simple mode. In this case, you’ll want to turn this On since it keeps parts of your website dynamic (see more notes on the plugin page).
- Mobile device support: Off – serves a separate cached file for mobile users which isn’t needed if you have a responsive website. Only enable if you use a separate mobile theme.
- Remove UTF8/blog charset support from .htaccess file: Off – if you see weird characters on your website (Â â ¢), this should fix it. Otherwise, you should leave this setting disabled.
- Clear all cache files when a post or page is published or updated: On – when you publish or update content, this clears the cache so other parts of your website (like your blog page) shows the most recent post. I wish it gave you better control of which content gets cleared since clearing the entire cache uses resources, but that’s what they give you.
- Extra homepage checks: On – I’m guessing this checks the homepage more frequently before building the cache, or even during. WP Super Cache recommends turning this on.
- Only refresh current page when comments made: On – when someone leaves a blog comment, only that page is refreshed. Makes sense since no other pages were changed.
- List the newest cached pages on this page: Off – see that yellow box on the right side of your WP Super Cache dashboard? This just adds another section under “Rate this plugin” which shows all your newly cached pages. If you don’t want to see this, leave it disabled.
- Coarse file locking: Off – WP Super Cache clearly says this can slow down your website.
- Late init: Off – if you check your source code and see the error “Super cache dynamic page detected but late init not set”, enabling this setting will fix it. Otherwise, leave it off.
- Cache location: nothing to do here, it just shows you the directory of your cached files.
- Cache timeout: most websites should increase this from 1800 to around 7200 which is 2 hours. If you use the default settings (1800 seconds), this can easily overload your server since the cache is rebuilt every 30 minutes. The 2 main factors to consider when setting this number are how often you update your site, as well as how powerful your server is. If you’re on shared hosting and don’t update your site often, you can increase it even more. Large websites that publish lots of time-sensitive content would probably decrease this.
- Scheduler: Timer – this lets WP Super Cache check for stale cached files using intervals. “Clock” lets you set a specific time which is good if you don’t update your site often. Like the previous setting, the number depends on how often you make updates and the server.
- Accepted filenames & rejected URIs: dynamic pages (especially on WooCommerce sites) should be excluded from the cache while static content (pages/posts) should be cached.
- URL strings, cookies, filenames, tracking parameters, user agents: the previous setting should give you enough control over what’s cached and not, otherwise you can use these.
- Lock down: Disabled – only use if you expect a large traffic spike. This prevents the cache from being refreshed when new comments are made. Most sites shouldn’t need to use it.
The WP Super Cache CDN settings should only be used if you’re using a CDN URL (i.e. cdn.example.com). This is not for Cloudflare.
CDN URLs are used by BunnyCDN (what I use on top of Cloudflare), KeyCDN, StackPath, and most other CDNs besides Cloudflare. They usually require you to create a pull zone first, select which regions you want to use, then they assign you a CDN URL (also called a CDN Hostname).
Once you have the CDN URL, click “Enable CDN Support” in WP Super Cache and paste it into the “Off-site URL” field. There is usually no reason to configure any of the other CDN settings.
Purge your CDN cache and make sure files are being served from it:
The content tab shows cache vs. expired pages and has settings to delete the cache. This was set up on a demo website with no content, but yours should show your pages are being cached.
Preloading is good because it generates cached files for your posts, categories, and tags. Preloading is bad because it can use a lot of server resources. I recommend it if you’re on a VPS or higher, but leave it off if you’re on shared hosting. You can always test it and see for yourself.
To use it, select preload mode (garbage collection disabled). You probably don’t want to preload tags or categories unless those are important pages on your blog. I set the preload to refresh every 1440 minutes (1 day) so it won’t use as much CPU as the default (600 minutes).
Nothing to do here unless you use one of the plugins below.
Used for debugging, nothing to do here otherwise.
Hope this helped!
I set up this cache on one clients website and worked fantastic, got A’s (from D’s) – was nice to see it all green.
Another clients site, I gtmetrixed, and then installed and it stayed as a F (with and wihtout caching, no change)- did exactly same thing. Only difference is this client is not hosted on my servers and does not use the same themes I use with other clients. I also get errors when chaning the php to 8.1 from 7.4 both in EA and Alt versions.
I am just at a loss. I will attempt to clone their website to my servers to troubleshoot further – because I have a feeling it is something to do with their webhost (maybe) I dunno…
Just seeing if there is something else I should be doing.
You can email me the site if you want me to look: tom(at)onlinemediamasters.com.
Hosting/theme can definitely make a big difference but if you’ve crossed that off as a potential problem, I’m not sure without taking a look.
saya memaki plugin AMP, ketika aktifkan mobile device support, hasil test page speed malah turun di kisaran 75-80. tapi ketika di non aktifkan menjadi 99 performance hasil pagespeed. semnatra versi dekstop ini yang stagnan tidak ada perubahan, tetap dikisaran 75-77 Score Performance nya… pengaruh apa ya kira2?
saya pakai cyberpanel, server indo…
Saya sudah lama tidak menggunakan AMP jadi saya tidak tahu apa penyebabnya, tapi saya tidak kebanyakan orang mengatakan untuk menjauh dari AMP, termasuk Kinsta: https://kinsta.com/blog/google-amp/