WordPress W3 Total Cache Configuration

Share this post

WordPress W3 Total Cache Configuration.

WordPress W3 Total Cache Configuration. In this post I’ll be covering how to configure the W3 Total Cache plugin in a WordPress installation, this post follows on from this post about WordPress and caching plugins. W3 Total Cache is also a good alternative to the Litespeed Caching Plugin if you don’t have the Litespeed Web Server available in your hosting.

Part of the configuration I’ll be covering involves configuring the W3 Total Cache plugin to use object caching, so it’s advisable to check to see if object caching is available in your hosting. I’ve covered how to check if object caching is available in this post dedicated to object caching.


Why Use a Caching Plugin?

Caching plugins are generally used to improve website performance.

The way they work is by “remembering” parts of your site or page output, so that this can be served in less time when the same part is requested in the future. Caching plugins often add configuration to tell a visitors browser to “remember” other parts of your site (such as static resources, like CSS, images and so on). Some caching plugins also employ techniques such as minifying to reduce to amount of data transferred when a page on your site is reqested.

I’ve gone in to a lot more depth about caching and how it works in this post about WordPress caching plugins.

The performance of a website plays a part in where it falls in search results displayed by search engines. As caching plugins help to improve performance, they can have a positive effect, or at least help, with your site being found more easily in search results.


Before You Begin.

One of the things that W3 Total Cache can be configured to make use of is object caching. It’s advisable to check to see if object caching is available in your hosting before you start cinfiguring W3 Total Cache. You can find guidance covering how to check if object caching is available in this post.

If you’ve read my post about WordPress and Caching plugins then you’ll know that it’s advantageous to optimise your site before getting started with configuring any caching plugin.

The reason it’s better to optimise your site before using a caching plugin is because the optimisation itself reduces the overhead of your site, and caching (when configured) will be more effective as it will then be caching only what needs to be cached, rather than caching resources that don’t really need to be present in your page output in the first place.

There’s no one size fits all answer or guide that covers exactly what you’ll need to do to optimise your site, but generally speaking, using a tool such as Page Speed Insights to analyse page output and then addressing issues flagged is the roughly what you’ll need to do to optimise your site.

A lot of information covering how to address some of the issues that may be flagged by analysis tools can be found in the optimisation category of this blog.


W3 Total Cache Setup Wizard.

You’d install and activate the W3 Total Cache plugin just like you would any other plugin.

After activating the W3 Total Cache plugin in your WordPress, you’ll then be presented with a wizard that walks you through a basic configuration.

The wizard’s purpose is to show what types of caching you have available, and allows you to choose which types of caching mechanism specific aspects (such as the page cache or the database cache) should use.

After activating the W3 Total Cache plugin, you’ll see a “Peformance” option appear in the menu on the left hand side of your WordPress dashboard. If you click on the word “Performance” you’ll be directed to the W3 Total Cache setup wizard:

Wordpress W3 Total Cache Configuration

On the first page of the setup wizard, you’re asked if you accept data being collected by W3 Total Cache. It’s completely up to you what you select here, this isn’t part of the caching configuration:

W3 total cache data collection options

After selecting one of the options above click “Next” in the bottom right hand corner of the page that’s subsequently displayed:

W3 Total Cache click next

After clicking next, you’ll then be presented with the “Page Cache” part of the setup Wizard. Click the “Test Page Cache” button to have W3 Total Cache check what’s available for page caching:

W3 Total Cache test page cache

W3 Total Cache will then test the caching options available, and show you the savings that each can make.

The higher the percentage, the more the saving, so you’re best to select the option with the greatest percentage reduction (in green) next to it:

For me, the greatest saving I can make is when using Memcached (this may differ for you), so I’m going to select this, then click next:

W3 Total Cache select page cache type

You’ll then be presented with a simlar test button, this time for the database cache, so go ahead and click the “Test Database Cache” button:

W3 Total cache test database cache

W3 Total Cache will again, test the caching options available, and show you the savings that each can make.

Again, choosing the caching mechanism that provides the greatest savings is the option to choose.

For me, it’s not completely obvious what I should choose here:

W3 Total Cache database cache test results

As you can see, the “Disk” storage engine gives me the highest saving, but there’s also this slightly worrying message at the bottom:

“By default, this feature is disabled. We recommend using Redis or Memcached, otherwise leave this feature disabled as the server database engine may be faster than using disk caching.”

The results may differ for you, and you may be faced with the same as I have, but I’d suggest selecting the option with the greatest saving unless there’s a minimal difference between “none” and the option with the greatest saving.

I’m going to choose Disk caching anyway, as I can always reconfigure this later if I need to.

The main reason I’m going to choose disk caching (despite the warning) is due to what’s in the “Time (ms)” column. The value displayed in this column for “Disk” is 739ms less than the value for “None”, which is about 3/4 of a second.

I’m going to select “Disk” and click “Next”:

W3 Total Cache select database caching option

After clicking next, you’ll then be presented with a button that allows you to test for oject caching. Click the “Test Object Cache” button:

W3 Total Cache test object cache

As you’ve probably guessed, W3 Total Cache will then test the object caching mechanisms and show you which will give the greatest saving. Selecting the option that provides the greatest saving is advisabled.

This time, for me, it’s quite obvious which provides the greatest saving, so I’m going to select Redis, then click “Next”:

W3 Total Cache object cache test results

You’ll then be presented with a “Test Browser Cache” button. Click this to test caching mechanisms available for Browser caching:

W3 Total Cache test browser cache

The following page looks a bit different to the ones that have come before it, as it doesn’t display potential savings, and only really gives you an “enabled” and “disabled” option. Browser caching should be enabled (as this addresses the “serve static assets with an efficient cache policy” as flagged by page pseed insights), so after selecting this, click Next:

W3 Total Cache enable browser cache

The next page covers image optimistation. Again, there’s no “test” option with this, just the option to “Enable WebP Converter”. It’s a good idea to enable this option (as it helps with “Serve images in next-gen formats” as flagged by page speed insights), so tick the option, then click next:

W3 Total Cache image optimisation selection

The following page covers enabling lazy loading. If you don’t have anythign else lazy loading images in your WordPress you’d be best to turn this on, but if something else is being used to make images load lazily, you can leave this turned off. I’m going to turn it on and click next:

W3 Total Cache lazy load selection

On the following page, it’s only information that’s displayed as you’ve completed the setup Wizard. You can simply click “Dashboard” to go to the W3 Total Cache dashboard to configure more caching options.

The additional caching options available in the dashboard aren’t covered by the setup wizard as they’re less generic and more specific to your site. I’ll be working through these in the next section.

For now, click “Dashboard” to exit the setup wizard:

W3 Total Cache setup wizard complete

W3 Total Cache General Settings.

To access the W3 Total Cache general settings, hover over “Performance” in the menu on the left hand side of the WordPress dashboard, then click on “General Settings”:

W3 Total cache access general settings

The General Settings section of W3 Total Cache mostly shows you the options that you set when working through the setup wizard, but there are some additional sections that need to be configured here:

W3 Total Cache General Settings – Minify

W3 Total Cache general settings minify

What minifying does is strip out all the whitespace, comments and line breaks from files. This reduces the total size of the file, and results in less data being transferred when a page of your site is requested.

It’s a good idea to set:
Minify: Enabled
Minify mode: Automatic (you might need to set this to manual if Automatic breaks your site, you’ll need to manually specify wich files to minify if you select Manual here)
Minfiy Cache Method: Disk
HTML Minifier: Minify (default)
JS Minifier: JSMin (default)
CSS Minifier: Minify (default)

W3 Total Cache General Settings – Opcode Cache:

W3 Total Cache General settings Opcode Cache

Opcode cache is used to store precompiled PHP code in memory, which saves on the resources needed to execute PHP code. This can have a positive effect on page load times, and server response times. If you don’t have Opcode available in your hosting W3 Total Cache won’t let you select this option, but if you do have have this available it’s advisable to set:
Opcode Cache: Opcode: Zend Opcache

W3 Total Cache General Settings – Browser Cache:

W3 Total Cache general settings browser cache

In the Broswer Cache settings there’s an additional optionn to enable HTTP copression. This compresses page output so less data is transferred over the wire when a page of your site is requested, so it’s a good idea to enable this option.

W3 Total Cache General Settings – The other options.

You can use the General Settings page to do other things such es export your settings, and there are also some debugging options as well (you’ll only need these if any of the options you set break your site), but there’s also a CDN section.

CDN’s are Content Delivery Networks. They effectively read a copy of your site, then serve it on behalf of your hosting. The idea is that they speed up the delivery of your site.

Some CDN’s are better than others. Cloudflare is generally the one that’s industry proven as delivering faster page load times, but you usually have to pay for a Cloudflare service. You might consider purchasing a Cloudflare service if you feel that your site still needs improved performance after setting up the caching in full.

I’m deliberately not going to cover the CDN side of things, as this is more how to integrate an external service with W3 Total Cache, rather than being specific to W3 Total Cache alone.


W3 Total Cache – Page Cache

Permformance > Page cache

Shows W3 Total Cache’s page cache options. I’ll be working through these section by section.

W3 Total Cache – Page Cache – General:

W3 Total Cache page cache general settings

It’s advisable to set:
Cache posts page: Enable
Don’t cache front page: Disable
Cache feeds: site, categories, tags, comments: Enable
Cache SSL (HTTPS) requests: Enable
Cache URIs with query string variables: Disable (unless your site uses query strings in URLs, and if it does enable)
Cache 404 (not found) pages: Enable (but test and disable if this causes issues with your site)
Don’t cache pages for logged in users: Enable (unless you allow users to log in to your site)
Don’t cache pages for following user roles: Disable (although you may want to enable this for certain roles if they want to see live fresh updates, rather than cached content when making changes to the site)

W3 Total Cache – Page Cache – Aliases:

W3 Total Cache page cache aliases

You’ll only need to enable this option if your caching identical content across different domains. If you’re not doing this leave this option disabled. If you are doing this, enable and enter the additional URLs of where the identical contnent is held in the “additional home URLs” field.

W3 Total Cache – Page Cache – Cache Preload:

W3 Total Cache page cache preload

Preloading is when a cache is generated in advance of a visitro accessing a site, as opposed to a cache being generated upon the first visit. Enabling the cache preload means that the first visit is faster (because the page is already cached due to the preloading), rather than the first visit being slow and subsequent visits beign faster.

It’s best to set:
Automatically prime the page cache: Enable
Update interval: 900 is fine (you may need to adjust this according to how big your site is in pages)
Pages per interval: 10 (you may need to adjust this according to how many pages your site has)
Sitemap URL: The URL of your site’s sitemap (this is used to define the pages that should be prelaoded in the cache)
Preload the post cache upon publish events: Enable (the cache will be cleared when a post is published, and you’ll want the cache preloaded after it’s been cleared).

W3 Total Cache – Page Cache – Purge Policy:

W3 Total Cache page cache purge policy

The Purge Policy allows you to define which caches should be purged when a post is created, updated or commented on. Ticking too much here isn’t the best of ideas as it will flush a lot of the cache. Its best to aim to tick as little as possible, but allow for new or updated content to be seen as and when it’s published.

The default options are OK for most sites, but you may need to tick more depending on your site. For example, if you allow comments on your blog posts, and want these to be seen immediately, you’d need to tick the “post comments page” option.

W3 Total Cache – Page Cache – Rest API:

W3 Total Cache page cache Rest API

Unless you’re paying for the paid version of W3 Total Cache you only have the option to either not cache the Rest API or disable it. If your site doesn’t use the Rest API you might as well disable it (maybe disable, then test your site if you’re not sure), otherwise leave it as “don’t cache”.

W3 Total Cache – Page Cache – Advanced:

What’s enabled by default in the Advanced section of the Page Cache options is usually fine by default. You won’t generally need to change anything here. If you do need to change any settings here it would be advisable to check the W3 Total Cache documentation accoridngly.


W3 Total Cache – Minify:

Permformance > Minify

Shows W3 Total Cache’s Minify options in full. I’ll be working through these section by section.

W3 Total Cache – Minify – General:

W3 total cache minify general settings

In this section it’s best to set:
Rewrite URL structure: Enable
Disable minify for logged in users: Leave this disabled (unless logged in users are having issues, and caching for logged in users is enabled, in which case enable).
Minify error notification: Admin Notification (so you’ll be emailed if minify errors occur)

W3 Total Cache – Minify – HTML & XML:

W3 Total cache minify html and XML options

In this section it’s best to set:
Enable: Enable this
Inline CSS minification: Enable
Inline JS minification: Enable
Don’t minify feeds: Enable (they’re small as it is)
Line break removal: Enabling this might break your site, you could enable then test your site, and leave it enabled if there’s no adverse affect.

W3 Total Cache – Minify – JS:

W3 Total Cache minify js options

In this section it’s best to set:
JS minify settings: Enable
Minify method: Minify only (unless you have a very large number of individual JS files, it’s better to have a number of minified files than one big combined file).
Minify engine settings: before </head> Non-blocking using defer, After <body> default (this doesn’t cause issues to be flagged in Page Speed insights, as this only flags scripts in <head> due to them being loaded as a priority).
Preserved comment removal: Enable (so that comments are removed)
Line break removal: Enabling this might break your site, you could enable then test your site, and leave it enabled if there’s no adverse affect.
HTTP/2 push: It’s advisable to have this enabled if it’s supported by your hosting, and doesn’t have an adverse effect on your site as it can improve performance, but you may need to disable this if it causes issues with your site.

W3 Total Cache – Minify – CSS:

W3 Total Cache page cashe CSS options

In this section it’s best to set:
CSS minify settings: Enable
Minify method: Minify only (unless you have a very large number of individual CSS files, it’s better to have a number of minified files than one big combined file).
Preserved comment removal: Enable (so that comments are removed)
Line break removal: Enabling this might possibly break your site, so it may be best to enable then test your site, and leave it enabled if there’s no adverse affect.
@import hansling: Process
HTTP/2 push: It’s advisable to have this enabled if it’s supported by your hosting, and doesn’t have an adverse effect on your site. Disable this if it causes issues with your site.

W3 Total Cache – Minify – Advanced:

You shouldn’t need to change much here, unelss minifying HTML, CSS or JS breaks your site.

You can use the boxes that start with “Never minify the following…” to exclude JS, CSS and page from minification:

W3 Total Cache minify advanced options

W3 Total Cache – Database Cache:

Permformance > Database Cache

Shows W3 Total Cache’s database cache options in full. I’ll be working through these section by section.

W3 Total Cache – Database Cache – General:

W3 Total Cache databse cache general options

You’ll need to enable the option seen above so that WordPress functions as it should for logged in users. Disablign this might be an option if you don’t allow your visitors to log in to your site but it’s HIGHLY recommended that your WordPress backend/dashboard functions as it should after doing so.

Don’t cache queries for logged in users: Enable

W3 Total Cache database cache advanced options

You shouldn’t really need to change much in this section. You might possibly want to adjust “Maximum lifetime of cache objects” and “Garbage collection interval” if you want objects to be cached for longer or shorter periods of time or if you would like the object cache garbage disposed of more frequently (respectively). I’d suggest leaving these as default and tune them only tune them if it’s required.


W3 Total Cache – Object Cache:

Permformance > Object Cache

Shows W3 Total Cache’s object cache options in full. There’s only one section here, and you generally won’t need to change much, if anything at all.

W3 Total Cache – Object Cache – Advanced:

W3 Total Cache object cache advanced options

You won’t usually need to change anything here, but if you’d like to do so it would be worth reading the documentation that covers object caching for W3 Total Cache.


W3 Total Cache – Browser Cache:

Permformance > Browser Cache

Shows W3 Total Cache’s browser cache options in full. I’ll be working through these section by section.

W3 Total Cache – Browser Cache – General:

W3 Total Cache Browser general options

In the browser caching general settings it’s best to set:
Set Last-Modified header: Enable (this details when a resource was last modified, so helps browser establish if they should obtain a new copy or use a cached copy, related to cache-control header).
Set expires header: Enable
Set entity tag (ETag): Enable (this is similar to “set last-modified header” but more reliable)
Set W3 Total Cache header: Disable, this only really needs to be on if you’re debugging.
Enable HTTP (gzip) compression: Enable (if brotli isn’t available), disable (if brotli is available)
Enable HTTP (brotli) compression: Enable (if brotli is available), disable (if brotli isn’t available)
Prevent caching of objects after settings change: Enable (this forces the browser to relaod recently updated assets)
Remove query strings from static resources: Disable (deprecated)
Prevent caching exception list: Leave this empty unless you have URLs containing query strings that should be cached after a settings change.
Don’t set cookies for static files: On
Do not process 404 errors for static objects with WordPress: Off (better plugin compatibility)
404 error exception list: Leave blank (due to the setting above)
Rewrite URL structure of objects: Leave disabled.

W3 Total Cache – Browser Cache – CSS and JS:

W3 Total Cache browser cache CSS and JS options

In the browser caching CSS and JS settings it’s best to set:
Set Last-Modified header: Enable (this details when a resource was last modified, so helps browser establish if they should obtain a new copy or use a cached copy, related to cache-control header).
Set expires header: Enable
Expires header lifetime: 31536000 (Google recommendation)
Set cache control header: Enable:
Cache Control policy: Cache with max age public (“public, max-age=EXPIRES SECONDS”)
Set entity tag (ETag): Enable (this is similar to “set last-modified header” but more reliable)
Set W3 Total Cache header: Disable, this only really needs to be on if you’re debugging.
Enable HTTP (gzip) compression: Enable (if brotli isn’t available), disable (if brotli is available)
Enable HTTP (brotli) compression: Enable (if brotli is available), disable (if brotli isn’t available)
Prevent caching of objects after settings change: Enable (this forces the browser to relaod recently updated assets)
Remove query strings from static resources: Disable (deprecated)
Don’t set cookies for static files: On

W3 Total Cache – Browser Cache – HTML & XML:

W3 Total Cache browser HTML and XML options

In the browser caching HTML and XML settings it’s best to set:
Set Last-Modified header: Enable (this details when a resource was last modified, so helps browser establish if they should obtain a new copy or use a cached copy, related to cache-control header).
Set expires header: Disable (only enable if there’s too much HTML traffic as this can cause visitors to see outdated content)
Expires header lifetime: 3600 (Although this doesn’t really matter due to the option above being disabled)
Set cache control header: Enable:
Cache Control policy: Cache with max age public (“public, max-age=EXPIRES SECONDS”)
Set entity tag (ETag): Enable (this is similar to “set last-modified header” but more reliable)
Set W3 Total Cache header: Disable, this only really needs to be on if you’re debugging.
Enable HTTP (gzip) compression: Enable (if brotli isn’t available), disable (if brotli is available)
Enable HTTP (brotli) compression: Enable (if brotli is available), disable (if brotli isn’t available)

W3 Total Cache – Browser Cache – Media And Other Files:

W3 Total Cache browser Media and Other files options

In the browser caching media and other files settings it’s best to set:
Set Last-Modified header: Enable (this details when a resource was last modified, so helps browser establish if they should obtain a new copy or use a cached copy, related to cache-control header).
Set expires header: Enable
Expires header lifetime: 31536000 (Google recommendation)
Set cache control header: Enable:
Cache Control policy: Cache with max age public (“public, max-age=EXPIRES SECONDS”)
Set entity tag (ETag): Enable (this is similar to “set last-modified header” but more reliable)
Set W3 Total Cache header: Disable, this only really needs to be on if you’re debugging.
Enable HTTP (gzip) compression: Enable (if brotli isn’t available), disable (if brotli is available)
Enable HTTP (brotli) compression: Enable (if brotli is available), disable (if brotli isn’t available)
Prevent caching of objects after settings change: Enable (this forces the browser to relaod recently updated assets)
Remove query strings from static resources: Disable (deprecated)
Don’t set cookies for static files: On

W3 Total Cache – Browser Cache – Security Headers:

This section of W3 Total Cache isn’t that easy to configure and there are security headers plugins that are a lot easier to use than this part of W3 Total Cache, such as Headers Security Advanced & HSTS WP (very easy to use), Security Header Generator and HTTP Headers. I’d suggest leaving these options in W3 Total Cahce either disabled or set to defualt, and using one of the mentioned plugins instead.


W3 Total Cache – Cache Groups:

You’ll only really need to use this section if:

  • You’re not using a responsive theme and use a plugin to generate the mobil version of your site.
  • You want to serve a unique cached version of your site to visitors from specific sources (search engine bots for example)
  • You want to serve a unique cached version of your site to visitors with specific cookies (search engine bots for example)

All of the above are quite unique situation so will only apply to a small amount of sites ro scenarios. Check the documentation for W3 Total Cache if you want to configure any of these.


W3 Total Cache – CDN:

As I’ve already mentioned, most CDNs that are worth using you have to pay for, so it’s worth seeing how you get on without using a CDN.

If you do want to use a CDN and have full site delivery handled by the CDN there’s some W3 Total Cache documentation covering how to configure this here.

It woudl be worth seeing if the configuration detaield above provides a suitable amoutn of caching and performance benefit before paying to be able to use a CDN, as you could potentially save yourself an additional cost.

There are also some implications to using a CDN, such as you needing to know how to adminsiter DNS.


Share this post

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top