Setting up W3 Total Cache can be overwhelming. The popular and powerful caching plugin has 16 menus to contend with and offers a dizzying array of options to configure. However, get through all of them and a significant boost in website performance awaits you.
This post is the second installment in a four-part series about W3 Total Cache (W3TC).
Part 1: Introduction to Caching – How caching can speed up WordPress and an overview of what W3TC does.
Part 2: How to Set it Up – A detailed walk through W3TC’s 16 menus so you can set up W3TC like a pro.
Part 3: All Your Questions Answered – How to fix the most common headaches and roadblocks encountered when setting up W3TC.
Part 4: Works-Every-Time Settings for Shared Web Hosting – Run WordPress on a shared server? Here are set-them-and-forget-them settings you can use that will work 99.9% of the time and produce a measurable boost in website performance.
In this post we’ll walk through each of W3TC’s 16 menus one at a time, and explore all of the configuration options available in W3TC. Once you’ve finished this post you’ll be ready to tackle setting up W3TC like a pro.
This article is 100% affiliate-free!
We will never take money to promote others, everything you read is genuine. Learn more.
Setting Up W3 Total Cache
W3TC is in the WordPress Plugin Directory so installation is super simple. Access the plugin installation menu by going to Plugins > Add New in the WordPress admin dashboard. Then search for “W3 Total Cache,” find the plugin from the list of available options, and select Install Now.
After installation, activate the plugin, and you’ll see Performance added as a new top-level item in the admin menu. Select Performance and you’ll be taken to the W3TC Dashboard and you’ll see a list of W3TC menu items that includes the following pages:
Dashboard
General Settings
Page Cache
Minify
Database Cache
Object Cache
Browser Cache
User Agent Groups
Referrer Groups
CDN
Monitoring
Extensions
FAQ
Support
Install
About
Let’s walk through each menu in order.
Dashboard
The primary purpose of the Dashboard is to serve as a place to clear the various caching modules, check compatibility between the plugin and server, and monitor server performance.
The first item displayed on the Dashboard is a series of buttons.
Compatibility check: Tests the server to determine which features can be enabled.
Empty all caches: Deletes all cached resources.
Empty only the memcached cache(s): Deletes all resources cached using the memcached method.
Empty only the opcode cache: Deletes all resources cached using any of the opcode cache methods.
Empty only the disk cache(s): Deletes all resources cached using the disk, disk:basic, or disk:enhanced methods.
Update Media Query String: W3TC attaches a string to the end of media resources (CSS, JS, and image files). Select this button to update that string to ensure that the browsers download an updated version of these resources.
Many of these functions can also be completed from any page of your website by accessing the Performance menu item from the admin menu bar at the top of the page.
Compatibility Test
The information generated by the compatibility check button can be very helpful. It will test your server configuration for support of all W3TC features. Review the results and you’ll know what features you can enable and what features will require additional server configuration work to be supported.
If you’re setting up W3TC for the first time, click the compatibility check button so that you know which features you will and won’t be able to implement.
Dashboard: Support, Marketing Offers, PageSpeed, and Server Monitoring
Below the row of buttons you’ll find a few additional sections:
Premium services: Purchase premium support from W3-Edge.
Spread the word: Share W3TC on social media, review and rate the plugin at WordPress.org, and add a link to W3 EDGE to your site’s footer.
Sign up for MaxCDN.
Server monitoring by New Relic and Google PageSpeed Insights monitoring. Note that additional configuration in the General Settings and Monitoring menus, a PageSpeed API key, as well as account signup and installation of New Relic, are required to enable these features.
All of these sections are optional and do not affect website optimization.
General Settings
The General Settings menu is the most important W3TC menu. All of the caching options offered by W3TC are enabled and disabled from this menu and then refined by adjusting settings at subsequent menus.
First, take a look at the list of link at the top of the page.
Each of these links connects directly to a section further down on the General Settings menu. Clicking on them just saves you some scrolling.
It is common for first-time W3TC user to confuse these links and the W3TC menu items in the admin menu. It’s important to realize that the links in the admin menu go to different menu pages entirely where features are refined. The links at the top of the page link to sections of the General Settings menu where these features are enabled or disabled.
General Settings: General
Below the list of links is the General panel. There are two options in this panel:
Selecting the checkbox to Toggle all caching types on or off (at once) is not usually a good idea and tends to produce admin notice overload.
Very few sites will actually use all of the caching modules, so it makes more sense to go through the caching options one at a time, enabling only those that you actually plan on using.
General Settings: Preview Mode
Preview mode is a valuable tool built into W3TC, but it does take some getting used to.
Enable Preview Mode if you’re adjusting W3TC settings on a live website. Once enabled, a dialog will be displayed at the top of the screen letting you know that any changes made won’t affect user experience unless you select the button to deploy the changes.
What preview mode does is create a seperate container for site settings. Any changes made to W3TC settings with preview mode enabled are saved separately from the deployed settings. This lets you work with W3TC settings without affecting user experience.
With preview mode enabled, you will see three buttons:
Disable: Turns off preview mode and simultaneously deploys any changes made and saved while in preview mode.
Deploy: Pushes changes made and saved in preview mode to the live site but keeps preview mode enabled.
Preview: Launches a new browser window where you can see the results of the changes made without deploying them for all site visitors to see.
After selecting Preview and refreshing the window the button will change to Stop previewing. Select Stop previewing to view the site as visitors see it while they aren’t logged in.
Take the time to get comfortable with preview mode. Some of the changes that W3TC can make to your site — most notably, minification of CSS and JavaScript — can break your site. Playing with those settings on a public-facing site is a really bad idea. With preview mode enabled, you can work on those settings without displaying the results until you’re happy with them.
Clear the Cache
One type of admin notice you will see on an ongoing basis while working with W3TC is a recommendation to clear the cache.
What this notice is telling you is that changes you’ve made have invalidated the version of site resources in the cache.
Anytime you see an admin notice adiving you to clear cached data, select the button to empty the relevant cache.
General Settings: Page Cache
The next section in the General Settings is the Page Cache. This is arguably the most important feature offered by W3TC. If you do nothing but enable page caching you should see a measurable boost in site performance. Thankfully, it’s also easy to set up.
W3TC can use a variety of different caching methods to cache static copies of your sites pages and posts (all referred to generically as pages by W3TC). The default choice in most cases should be the Disk: Enhanced method. However, shared server users may have to use Disk: Basic instead if their host complains of excessive resource usage or if the compatibility check test reveals that the server is not compatible with enhanced disk caching.
Dedicated or virtual private server users can opt for one of the Opcode cache methods. If you manage the server yourself, you can install the opcode cache method you prefer. If your server is a Windows machine you’ll need to go with Opcode: WinCache instead.
Memcache is designed for use in multi-server hosting environments. As a result, it may be available if you’re using cloud-based hosting and even from some shared hosting providers. If it’s available in your hosting environment, use it.
With your preferred page caching method selected – most likely Disk: Enhanced – select Save all changes.
General Settings: Minify
Note: Minification of CSS and JavaScript can also be done with Hummingbird. If you use Hummingbird for minification, leave this option disabled in W3TC.
Minification of JavaScript and CSS can break sites, whether you’re using W3TC or another plugin. So proceed with caution when enabling the Minify module.
The Auto option will combine and minify all JavaScript and CSS resources. However, selecting it means that you won’t be able to work with each resource individuall from the Minify menu. The only way to know how things will go is to try Auto, fine tune the settings in the Minify menu, and see how your site loads. If doing this breaks your site, switch to Manual.
Select Disk caching method if you use shared hosting. Otherwise, select the same caching method as you selected for the page cache method.
General Settings: Database Cache
If your site is on a shared server leave database caching disabled. Database caching is a resource intensive process. Unless your server is powerful enough to handle the processing and storage load, database caching may actually slow down your site rather than speed it up.
Database caching is simple to set up. Just select Enable and match the method to the caching method you’ve been using so far.
You have to think about the bottlenecks that can affect website performance to understand why database caching can slow down your site. If the process of querying the database is slowing down your site, then database caching can speed up your site by reducing the number of times the database has to be queried. However, if a lack of server memory is slowing down your site, then asking the server to cache the database give an overloaded server more work to do and slows it down further.
So, how do you know whether or not database caching should be enabled?
If your site is hosted on a shared server you will probably be better off with database caching disabled.
If your site has dedicated resources – such as a VPS or dedicated server – enable it from the General Settings menu. Then test the site with and without database caching enabled and go with the setting that gets better results.
General Settings: Object Cache
Object caching is built into the WordPress core. The Object Cache module caches objects from the Object Cache API to cut down on the number of complex database queries performed by the server. Like database caching, object caching is easy to set up, but may or may not actually help the performance of your website.
Object caching has the greatest potential to help highly dynamic sites — BuddyPress sites, bbPress sites, and so forth — hosted from a private environment. If you’re running a blog or business website from a shared server, you can give it a try but are almost certainly better off leaving it disabled.
To enable object caching select the Enable checkbox and matching the caching method to the method you’ve been using thus far.
General Settings: Browser Cache
Note: Browser caching can also be accomplished with Hummingbird. If you use Hummingbird for browser caching leave this option disabled in W3TC.
Enabling browser caching is as easy as selecting a single checkbox and clicking Save all changes.
With browser caching enabled, website resources will be cached by website visitor browsers. That way, when a page is viewed a second time it can be loaded from the browser cache.
General Settings: CDN
If you use a content delivery network (CDN) you can integrate your CDN service with W3TC. This will mirror cached files from your web server to the CDN so that you have the full benefit of both caching and distributed content delivery.
To enable CDN integration select the Enable checkbox, pick your CDN service provider from the list of CDN types, and click Save all settings.
You will also need to visit the CDN menu to add your CDN credentials to W3TC before integration between W3TC and the CDN will be complete.
You will may notice that Cloudflare is absent from the list of CDN services. To use Cloudflare with W3TC visit the Extensions menu, activate the Cloudflare extension, and then navigate back to the General Settings menu to complete Cloudflare integration.
General Settings: Reverse Proxy
To use this option you will need to install Varnish on your server and go through some advanced server configuration steps. This is only the sort of thing you will want to do if you are hosting in a private environment with root access to the server. If you are interested in setting up varnish to work with W3TC, Tuts Plus has a tutorial that walks through the process.
General Settings: Monitoring
New Relic server monitoring can be integrated with W3TC. To use this service you have to install New Relic on the server and sign up for a New Relic account. Since New Relic has to be installed on the server, it isn’t compatible with shared hosting.
If New Relic is installed on your server and you have a New Relic account, enter your account credentials in this section to add server statistics to your W3TC Dashboard.
General Settings: Miscellaneous
The first option in the Miscellaneous section in the General Settings is used to enable a Google PageSpeed widget in the W3TC dashboard. To do this you will need to first set up an API key.
In most cases, you will want to leave all of the other settings in the Miscellaneous section alone.
Verify rewrite rules is checked by default. Uncheck it to prevent W3TC from letting you know that there’s something wrong with your rewrite rules. Leave it alone.
Enable file locking is disabled by default. File locking isn’t compatible with most shared hosting. However, if hosting from a private environment, you can enable it and see if it improves site performance.
Optimize disk enhanced page and minify disk caching for NFS is disabled by default. This is an option that may provide a modest boost in performance. Test with and without the option enabled to judge for yourself if it should be enabled.
Enable Edge Mode should be disabled on production sites. However, if you’d like to play with the latest caching features in a testing environment, select this option.
General Settings: Debug
Debug Mode should remain disabled unless you are actively using it.
With the debug mode enabled, debugging information will be added at the very end of the page source.
It’s worth noting that only the cache modules that are enabled in the General Settings menu will be available in Debug Mode. In the image above you can see that only Page Cache and Minify are available. This is because the other cache features were disabled at the time the image was captured.
General Settings: Import/Export Settings
If you use W3TC on a number of sites and want to duplicate plugin settings between multiple sites, this section will make that easy.
Select Download to export the current settings. Then use the Choose File option on another site to upload the same configuration. You can also use this option to create a backup file to use as a restore point when configuring W3TC.
Lastly, if you want a fresh start configuring W3TC, the option to Restore Default Settings will let you do that.
Page Cache
With page caching enabled from the General Settings menu, use the Page Cache menu to fine tune page caching behavior.
When selecting pages to cache be as inclusive as possible. In most cases, you will want to cache virtually all pages.
If you site resolves using https, then you will want to enable Cache SSL (https) requests.
Most sites will not benefit from selecting Cache URIs with query string variables. Enabling this option can produce unexpected results by caching unanticipated strings. So, unless your site search feature is used heavily for searching the same terms, leave this option disabled.
Finally, it is not advisable to cache 404 pages. Visitors shouldn’t see them very often anyway, and you don’t want Google to index a 4040 page as a regular page which can happen if you enable this option.
The next option, Cache requests only for (your domain) site address is left unchecked by default, but the universal recommendation is to check this option.
The next two options look quite similar but the fine print explanation provided under each makes it clear that they are quite different.
Don’t cache pages for logged in users should always remain checked. If you leave it unchecked and view your site while logged in, your admin-privileged view may be cached and then displayed to users who aren’t logged in.
Don’t cache pages for the following user roles means that logged in users that fit the selected role will not receive cached pages and will see an uncached version of the site.
It’s not usually a good idea to obscure the cached version of the site away from logged in admins who may inadvertently change the cached version without realizing it. So you should leave the section option unchecked.
The next section, Cache Preload, is used to build the page cache before the pages are accessed.
It’s a good idea to select the option to Automatically prime the page cache. The default update interval and pages per interval values are good presets for shared servers. However, if you have a more powerful hosting environment feel free to reduce the update interval and cache pages in larger batches.
You will want to add a Sitemap URL to the appropriate field as W3TC will use the sitemap to identify the pages that should be cached.
Lastly, in most cases you’ll want to select the option to Preload the post cache upon publish events. This will ensure that the cached version of your posts page is updated every time you publish a new post.
The Purge Policy section is used to specify the pages to purge from the page cache whenever a post is published, edited, or commented on.
You will probably want to leave the Purge Policy: Page Cache default settings alone unless you know that you want one of the additional pages purged when any of these events occurs.
The purge limit determines how many archived pages should be purged. For example, if your posts archive is 20 pages deep, and you set the purge limit to 15, then the 15 newest pages will be purged while the five oldest pages won’t be purged until the cached pages reach their preset expiration date.
Setting the value to 0 to purge all pages is a good idea unless some of your archives are very large. In that case, you may want to stick with the default value of 10 or something similar.
If you’ve built custom pages that need to be purged whenever posts are edited and published, add them manually to the Additional pages field (not shown in the image, but appearing below Purge Limit field).
The Advanced section is used to:
Control how W3TC handles specific query strings,
Exclude certain user agents (devices, browsers) from receiving cached versions of the site,
Identify cookies that will tell W3TC not to cache the page, and
Set up additional specific exceptions.
Take a minute to look at the settings at the beginning of the Advanced.
Late initialization: This advanced feature makes it possible to implement page fragment caching. You can safely ignore this option in most cases. To learn more, take a look at the FAQ titled “How do I implement page fragment caching?” and this brief fragment caching tutorial by Justin Silver.
Compatibility mode: The plugin author recommends enabling compatibility mode to minimize the occurrence of errors.
Charset: If you notice odd characters appearing in cached pages, enable this option.
Reject HEAD requests: Leave this option disabled. The information in a HEAD http request is sometimes needed to build the resulting page. If you disable this option, the data from the HEAD requests won’t be cached and that may break pages that are built using this information.
Garbage collection interval: Specify how frequently expired cache data is deleted. Removing cache data takes server resources, so don’t do this too frequently if your site is busy or if your server is overtaxed. The default value is appropriate for almost all servers.
Comment cookie lifetime: Reducing this value will reduce the load on the server as the session cookies used to authenticate commenters expire more quickly. However, set it to a value that is too short and users will have to deal with repeat logins. Leave the value as-is unless commenters complain, in which case, increase the value.
The rest of the fields in the Advanced section should be left alone unless you know you want to override W3TC behavior for a specific cookie, user agent, or page.