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.
Table of Contents
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.
PERFORMANCE
Super speed and performance with WP Hummingbird
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.
Minify
Note: Hummingbird can be used to minify and combine JavaScript and CSS resources. In addition, Hummingbird is more user-friendly and provides a nicer experience overall (even if we do say so ourselves).
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.
Minify: General
The General settings in the Minify menu include three options.
- Rewrite URL structure should be enabled by default and you should leave it that way unless you’d rather have CSS and JS resources fetched using GET http headers rather than the normal URL structure.
- Disable minify for logged in users should be left unchecked. It isn’t generally advisable to provide logged in users with different CSS and JS files than users who are logged out.
- Minify error notification should be set to Admin notification at a minimum. That way site admins will be notified when there is a minification error.
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.
Minify: HTML & XML
The HTML & XML section of the Minify menu is straightforward. Checkboxes are provided to enable minification, inline CSS and JavaScript, omit feeds from minification, and enable line break removal.
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.
Minify: JS
If you have enabled the Auto method for JavaScript and CSS minification from the General Settings menu, you will only be able to work with all JavaScript resources at once and the menu you see will be a simplified version of the image below.
If you selected the Manual method, you need to scroll back to the top of the Minify menu, and select the help wizard button. This will display list of the JavaScript and CSS files that W3TC has detected. Select the option to check all boxes for both the JavaScript and CSS files and then click Apply & close. This will add the JavaScript and CSS files to the Minify menu so that you can work with them manually.
Look at the box labeled Operations in area. From this box you can control whether JavaScript resources are minified and combined with the Minify option, or just combined. The Embed type drop down provides a few options for how JavaScript resources are loaded. You may try each of the Non-blocking… options until you find one that doesn’t break your sites presentation, but if none of the options work stick with the Default (blocking) value.
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.
Minify: CSS
There are four CSS minify settings available:
- Enable: Turns on minfication and combination of CSS files.
- Combine only: Combines CSS files but does not minify them.
- Preserved comment removal: Removes comments from combined CSS files.
- Line break removal: Removes lines breaks in combined CSS files.
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.
Minify: Advanced
In most cases, the default settings in the Advanced section of the Minify menu are fine as-is. However, you can use them to adjust the frequency with which JavaScript and CSS files in the cache are updated, the frequency with which expired files are removed from the cache, and more.
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.
Database Cache
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: gdsr_, wp_rg_, and _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.
Object Cache
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.
Browser Cache
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.
Browser Cache: General
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.
- Both the Last-Modified header and eTag are stored by a browser and then used later to ask the server if new versions of the stored documents exist.
- Both the expires and cache control header limit the lifetime of the cached resource. The expires header does this by assigning a fixed expiration date to the cached resources. While cache control header is used to assign a lifetime duration that starts ticking down when the cached object is downloaded by the browser.
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 idea here is that static files (images, CSS files, and JavaScript resources) don’t need a cookie added to the HTTP header and adding them bulks up those files unnecessarily.
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.
Browser Cache: CSS & JS, HTML & XML, Media
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.
User Agent Groups
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.
Referrer Groups
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.
CDN
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.
CDN: General
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:
- Host attachments: Mirrors attachments, such as images, to the CDN.
- Host wp-includes/ files: Mirrors certain types of files from the wp-includes folder, such as CSS, JavaScript, and images, on the CDN. The exact types of files are specified in a field in the Advanced section of the CDN menu.
- Host theme files: Mirrors certain types of theme files, such as CSS, JavaScript, and images, on the CDN. The exact types of files are specified in a field in the Advanced section of the CDN menu.
- Host minified CSS and JS files: Only select this option if you are using W3TC’s minification feature. This option mirrors minified JS and CSS files created in the Minify menu on the CDN.
- Host custom files: If you add any file names or paths to the Custom file list field in the Advanced section of the CDN menu, this option hosts those files on the CDN. By default, a few files are already added to this field, so leave it selected.
- Import external media library attachments: Does the same thing as the button at the top of the screen but automates the process so that it happens on an ongoing basis as pages and posts are published.
- Add canonical header: Adds your site URL as the canonical header of attachment files hosted on the CDN. Select this option to ensure that attachments list your URL and not the CDN URL as canonical.
CDN: Advanced
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 next four text fields work in conjunction with the checkboxes in the General section of the CDN menu. Use them to specify the types of files to host from the CDN. By default, certain types of static files such as CSS, JavaScript, and image files are listed.
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.
Monitoring
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.
Extensions
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.
Extensions: Cloudflare
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.
FAQ
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:
- First, as an educational resource when setting up the plugin. Set aside some time to read through the FAQ sequentially and you’ll learn a lot about caching and W3TC.
- Second, as a troubleshooting resource. If you have a specific question use the search feature in your browser to search for keywords related to your question and read the FAQs that address the topic.
Support
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.
Install
The Install menu provides a variety of installation and setup instructions.
Install: All Servers
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.
Install: Private Servers
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.
About
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.
Wrap Up & Next Steps
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.
0 Comments