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).
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.
We will never take money to promote others, everything you read is genuine. Learn more.
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:
Let’s walk through each menu in order.
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.
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.
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.
Below the row of buttons you’ll find a few additional sections:
All of these sections are optional and do not affect website optimization.
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.
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.
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:
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.
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.
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.
Select Disk caching method if you use shared hosting. Otherwise, select the same caching method as you selected for the page cache method.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Take a minute to look at the settings at the beginning of the Advanced.
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.
Lightweight and fast, Hummingbird caches, minifies, combines, defers and compresses, making optimizations in line with Google PageSpeed, and turning your website into a lean, mean, speed machine.
Before visiting the Minify menu, first enable Minify in the General Settings menu. If you enabled Auto minify mode, and it didn’t break your site, then the minification settings you see in this menu will be a simplified version of what is shown in the screenshots below.
In this tutorial, we cover the process of minifying with W3TC. Minification and combination of JS and CSS resources is a big topic that we won’t cover in this tutorial. To learn more about minification, read our article How to Eliminate Render-Blocking Issues with Hummingbird for WordPress.
The General settings in the Minify menu include three options.
The following sections all minify, combine, and move page components. This can break presentation of your site. You should enable preview mode and keep an eye on your site as you make changes to ensure you don’t break the presentation of your site.
With the exception of the Don’t minify feeds option, which should remain unchecked, your site speed should improve by checking off all of these options.
The Ignored comment stems text area is used to identify HTML comments that should not be removed when the HTML is minified. Certain comment stems will be in this field by default and ensure that comments associated with Google AdWords and screen readers aren’t removed. If your HTML contains any additional comments that you want to remain in the minified version of the HTML, add a comment stem to this box to ensure that they aren’t removed.
If you selected the Manual minify method from the General Settings menu, then you can work with each file individually by assigning it to just a single template or all templates and by moving it to the head, body, or below the body element for granular control of where each file appears in the HTML document and how it is loaded. You can also drag-and-drop the files to rearrange the order in which they are loaded in case some files depend on previous files to load properly (such as jQuery files requiring that jquery.js load before they are loaded).
The optimal setting is to move files out of the head and to load them with one of the Non-blocking… options. However, there is a very good chance that doing this will mess up how your site renders.
There really is no way around going through each file one a time, testing it at different locations, and making sure that the site loads properly.
There are four CSS minify settings available:
Start by selecting all options except for Combine only. If that breaks site presentation uncheck Preserved comment removal and Line break removal. If that does not fix the site, then switch from Enable to Combine only.
From the @import handling drop-down, select Process.
If you selected the Auto minification method from the General Settings menu, when you will only see the first two sections of this menu. However, If you selected the Manual minification method, then you will see an additional CSS file management section.
If you didn’t already add the CSS files to the CSS file management area head up to the top of the Minify menu, select the help wizard, and select all of your themes CSS files. Next, rearrange the order of the files so that the most critical files are loaded first.
The Advanced section includes three text input fields to exclude specific pages, JS files, and CSS files from minification. If you find that certain JS or CSS resources should not ever be minified (jquery.js and style.css sometimes break websites when minified or moved) you can single them out by adding them to these fields. If you need help with proper syntax, refer to the Usage: General: section of the FAQ menu for instructions.
The Database Cache menu has two sections: General and Advanced.
The General section has just one option: a checkbox, checked by default, that states Don’t cache queries for logged in users. What this means is that if a user is logged in they will not be served cached database values. The reason for this is that logged in users – such a commenters – will modify and interact with the database during their session. So they need to be served web pages that directly query the database rather than cached database values.
One exception to this would be where content is hidden behind a paywall but doesn’t change with user input. In that case, database caching is fine since users are logged in just to access the content and not to actually interact with or change any site content.
The Advanced section in the Database menu allows you to fine tune the database cache. You can assign a life to objects in the cache with the default value being 180 seconds, and determine how frequently expired cache objects should be removed.
If you do use database caching, stick to the default values unless the database cache grows too large. If that happens, trim down the lifetime of cache objects or reduce the garbage collection interval to reduce the amount of space taken up by the database cache.
You can also specify specific pages where cached database data will not be used in the Never cache the following pages field. This is particularly useful if you do cache queries for logged in users but have some pages where you don’t want cached database queries used.
The next field in the Advanced section allows you to specify database query stems that will be ignored — that is, not cached by the database cache. Use this field if you are using any plugins that depend on querying the database.
For example, the field is prefilled with three values:
_wp_session. Those three query stems correspond to the GD Rating System, Gravity Forms, and WP Session Manager. Those are three common plugins that need to directly query the database every time a page is loaded, not a cached version of the database. So adding those query stems to the ignored list ensure that those queries aren’t cached by W3TC.
If you have database caching enabled and notice that a specific plugin is misbehaving, you will need to identify the related query stem either by digging into the plugin code or asking the plugin author which stems to add to the Ignored query stems field.
The field titled Reject query words is used identify specific types of queries that should not be cached. Unless you are a database administrator, leave this field alone.
The Object Cache menu has just a single section of Advanced setting options.
The first two fields in the menu, Default lifetime of cache objects and Garbage collection interval, are used to set the lifetime of cache objects and the frequency with which expired cache objects are removed. You can decrease the object lifetime or garbage collection interval if the object cache grows too large. Alternatively, if you want to decrease the load on the server and don’t mind a larger object cache, you can increase both values. In most cases, the default values are fine.
The next field, Global groups is used to identify object groupings that are shared between sites when a WordPress installation is a multisite network. The idea is that some of those objects can be cached and reused across the network.
Leave the Global groups alone unless you’re an experienced WordPress developer and are familiar with how these groups work.
Finally, the Non-persistent groups field is used to identify object fields that should never be cached in the object cache. Once again, unless you are familiar with object groups leave this field alone.
Note: Hummingbird can be used to enable browser caching and gzip compression. In addition, Hummingbird is easier to use and provides a nicer experience overall (even if we do say so ourselves).
This menu has four sections to fine-tune browser caching: General, CSS & JS, HTML & XML, Media & Other Files. The fields presented in each section are nearly identical. As you adjust settings in the General section, those same settings will be applied to all subsequent sections. Then you can override specific settings in the latter sections after you’ve finished configuring the General section. Because of this behavior, configure the General section first, and then, if necessary, proceed to fine tune each subsequent section.
The first four options in the General section are all similar to each other. In essence, all four do the same thing: make sure that the data stored in the cache is still valid. However, each does so in a different way.
At a minimum, enable the first option to Set Last-Modified header. If you want to be more careful about making sure your visitors are served the most up-to-date version of your site, enable additional options.
Enable the option to Set W3 Total Cache header if you want to be able to look at the HTTP header of a document to determine if it was cached by W3TC. If you don’t know how to look at HTTP headers or don’t care to see W3TC in the header, just leave this option disabled. It does not affect performance.
Leave Enable HTTP (gzip) compression checked. This reduces the size of text files and can have a significant impact on site performance.
Leave the option to Prevent caching of objects after settings change selected. This ensures that every time settings are changed a new string is generated and attached to all cached items so that browsers know to discard the old cached files and download the new ones.
There are certain website resources you will not want user browsers to cache. One example might be a flash media player. Add the path to those resources to the field titled Prevent caching exception list.
Select the option for Don’t set cookies for static files.
The next checkbox, Do not process 404 errors for static objects with WordPress, will reduce server load by allowing the server to handle static file 404s rather than having the WordPress core process and notify the 404.
Unless you expect a large load of 404s, selecting or leaving this box unselected won’t make a huge difference. Best practice would be to select it, but doing so may cause some plugins to generate a bunch of 404s. If that happens you’ll need to manually add the URLs for the offending resources to the field labeled 404 error exception list.
Each of these sections will inherit the values added to the General section. However, you can use each of these sections to fine tune how each type of resources is handled in the browser cache.
The User Agent Groups menu lets you handle users based on the user agent (device) they are using. The most common use of this module is to redirect mobile device users to a mobile-optimized version of a site.
The first section of the User Agent Groups menu is a self-explanatory button you can use to Create a group of users. You can create multiple groups. If you do, make sure to put them in order with the most important group at the top and the least important group at the bottom. Users will be sorted into groups based on this order.
By default, two groups are pre-populated. These groups are designed to group mobile users into two groups: smartphones (the high group) and other internet-enabled mobile devices (the low group).
To activate a group, select the Enabled checkbox. If you have a second theme installed that should be used for specific groups of users, you can select it from the Theme drop-down menu. However, if you have an entirely different site that mobile users should be redirected to, add that URL to the Redirect users to field. If you want to adjust the list of devices associated with a group, you can do that by manually adding them to the User agents text area.
The Referrer Groups menu is used to specify how users referred by certain sources should be handled. Users referred from specific sources can be served a different theme or redirected to a different URL. A different cache will be created for each referrer group to ensure that users in that group aren’t presented with cached resources that don’t pertain to the group.
One group is pre-populated upon installation and includes five major search engines. You can see them listed in the text field labeled Referrers.
To enable the group, select the Enabled checkbox.
The CDN menu is used to mirror cached resources from your server to a CDN. Prior to visiting this menu, you have to select the CDN you wish to use in the General Settings menu. Then navigate to the CDN menu to establish a connection between W3TC and the CDN you have chosen.
Note that if you are using Cloudflare the process is a bit different. Head to the Extensions menu for details.
Scroll down to the Configuration section of the CDN menu to set up a connection between W3TC and the CDN. The specific details of the Configuration section vary from one CDN service to the next. Once you’ve successfully established a connection, you can proceed to set up the rest of the CDN menu.
At the top of the CDN menu are several buttons.
The first one on the menu, modify attachment URLs is explained in the FAQ menu. It is used to fix attachment URLs if the site URL has been changed at some point in the past and attachments are no longer loading. The next button is for importing attachments into the Media Library. Use this button if images in posts and pages aren’t in the WordPress media library. If they aren’t in the library, they won’t be cached on the CDN. Use this button to remedy that situation.
The next three button ensure that the CDN is hosting up-to-date files. Use them to purge files from the CDN if you find that the CDN is delivering out-dated content.
In most cases, you will want to select all of the available options from the General section of the CDN menu.
Here is what each option does:
If you run into mixed-content warnings use the checkbox to Disable CDN on SSL pages to resolve the mixed content issue. You can also disable the CDN for certain types of logged-in users with the option to Disable CDN for the following roles.
The File types to import field is used to filter through externally hosted media to select the types of media files that should be imported into the Media Library. By default, the field is empty. To add file types, copy the syntax used in the preceding fields. You will probably want to add something like
*.gif;*.png;*.jpg; to this field.
Use the Custom file list to specify any additional files that should be hosted on the CDN. In general, you will want to leave the preset values alone, and just add additional values to the list if you know of additional files that should be mirrored on the CDN.
The Rejected user agents field is used to specify user agents (devices) that should not be served content from the CDN. If your site uses a secondary theme for mobile devices, such as WP Touch, you may need to add user agents to this field to ensure they are served the mobile content rather than the cached standard version of the site.
The Rejected files field is used to specify types of files that should never be cached on the CDN. Several default file types are specified and you should leave the existing values alone. Add additional files to the list if you find that caching is messing up features such as captchas.
The final checkbox, Set cookie domain to “Site URL,”, should only be selected if you have configured your CDN service to work with a subdomain.
The Monitoring menu is used integrate New Relic server monitoring with W3TC. However, New Relic is not compatible with shared hosting, so integration with New Relic is not an option for many WordPress websites.
If you do plan to use New Relic to monitor WordPress and wish to integrate with W3TC, New Relic and Envato Tuts+ have put together a detailed tutorial to get New Relic and W3TC working together.
The extensions menu includes add-ons that allow third party products and services to integrate with W3TC. Extensions are available for integration with CloudFlare, FeedBurner, the Genesis Framework, and the WordPress SEO plugin. If an extension is available for a service or product you are using activate and configure the appropriate extension(s) from this menu.
One extension many websites will want to enable is CloudFlare. To activate the extension just click Activate. Doing so adds a CloudFlare section to the General Settings menu.
The Cloudflare section added to the General Settings menu is pretty self-explanatory. If you need additional assistance setting up CloudFlare with W3TC, CloudFlare offers support documentation you can refer to for detailed instructions.
The FAQ menu answers many configuration and setup questions. Unfortunately, the page is a bit of a mess with useful information (“Which web servers do you support?”) buried in with unimportant information (“But even Matt Mullenweg doesn’t agree that additional caching is so important, why bother?”). In addition, many of the FAQ titles aren’t very enlightening (“Umm, why?”).
There are two good ways to use the FAQ:
The Support menu can be used to initiate support requests. Free support options include bug reports and feature suggestions. Premium (paid) support options mirror the options available from plugin Dashboard.
To initiate any type of support request, select an option from the list and a new dialog will appear to submit the support request details and to pay for support if applicable.
The Install menu provides a variety of installation and setup instructions.
The first section of instructions on the page are general installation instructions that walk through basic steps of setting up the plugin. If you’re setting up the plugin for the first time, it isn’t a bad idea to read through these instructions.
Below the installation instructions is a bit of text that needs to be added to appear in .htaccess files. W3TC will try to add this text automatically, but there are instances where it must be added manually. If you see an admin notification letting you know that W3TC was unable to set the rewrite rules, copy the text from this location and paste it into the appropriate locations.
The rest of the information provided by the Install menu is intended for site’s hosted in a private environment, such as a dedicated or virtual private server, running 32-bit CentOS. Instructions are provided to install Yum, memcache modules, various opcode cache modules, and New Relic.
Refer to these instructions if you need help installing any of these tools.
The About menu provides a short, high-level overview of what W3TC can do. The most interesting part of the page is the list of people who contributed code, ideas, and experience to the development the plugin.
Well, that’s it: all 16 W3TC menus in detail. With this tutorial and the W3TC FAQ and Install menus in hand, you’re ready to set up W3TC on any WordPress website.
In my next post in this series, I’ll tackle some of the common challenges and headaches that WordPress users run into while setting up W3TC. So if you get stuck setting up W3TC, keep an eye out for that post so that we can help you get unstuck.