ATM, this tutorial is a raw copy-paste of an original article by Dave Clements
I will update the screenshots and modify it a little bit ASAP.
W3 Total Cache is one of the most useful WordPress plugin you can own. It can cache your pages, objects, database queries, pair up with a CDN and more.
It is a very powerful tool, but it can be difficult to configure.
When you install and activate the plugin, you’ll get a new icon the menu of the left hand side of your admin area. Click on that icon to bring up the general settings page for the plugin. You’ll want to start here.
Bear in mind that this page is where you “turn on” several of the functions of the plugin and it may be worthwhile keeping them disabled until you have configured the individual components and then returning here at the end to turn everything on.
You may be prompted to allow W3 Total Cache to install lines of code in your .htaccess file upfront and throughout the configuration process. Make sure you have a backup first, and then have it auto-install the code.
Some of my themes have already a “minify” option, so I don’t recommend using the minify settings. It could simply break your front end layout.
The page cache creates static pages from your dynamic content and serves them up to your users, instead of creating pages on-demand, which massively reduces your server load. You’ll likely find that the only option you have here is to select Disk: Enhanced, which is more than likely adequate for what you need.
Minify is the process of removing line breaks, comments and spaces from CSS and HTML files to reduce their size (thus delivering them quicker to the user). Again your only option may be Disk, which it is for me, but that will serve you well. You should be able to select Auto for your Minify Mode and the default settings for all the minifiers unless you have reason to choose something else.
The database cache saves the results of database queries instead of looking to the database every time the request is made, which significantly reduces the impact on your SQL server. Since WordPress is entirely database driven, nearly every page will make several requests to the database, such as displaying your 10 most recent posts on the front page, or recent comments in your widgets. Use the Disk option.
The object cache stores numerous objects from the database. It may or may not speed up your site, depending on the speed of your disk. You can do a comparison before and after turning it on to see whether there is a reduction in load time and if there isn’t, you might as well leave it turned off. If you are to turn it on however, use the Disk option.
The browser cache works by “telling” your visitors’ browsers how long to keep using the same version of an object. For example, it is unlikely that you will change an image once it has been uploaded, so there is no sense in downloading the image every time a user visits a page – it can just keep the original version and use it over and over again. This will cut a big chunk out of the amount of data needed to download every page, since much of it can be stored on the user’s computer after the first visit. There’s no options here, but you’ll need to enable it here once you’ve set the specific settings in a short while.
CDN stands for Content Delivery Network, which hosts static parts of your site on servers all over the world so that users can download them from their closest server, instead of potentially requesting it from halfway across the world, reducing latency and load on your server. They’re fairly cheap to use and I recommend it. I personally use Amazon Cloudfront, though there are a number of alternatives supported by W3 Total Cache. I wrote a tutorial detailing how to set up Amazon Cloudfront as your CDN with W3 Total Cache, which will be useful for guiding you through that process.
Varnish and Cloudflare
You can generally ignore these two sections, unless you know that you have a need for them.
With the miscellaneous settings, I recommend verifying the rewrite rules; I have found that on numerous occasions, other plugins that interfere with .htaccess can mess up the W3 Total Cache settings, so enabling this will tell you when there’s a problem that needs resolving. Else, your site could be running with several parts of the plugin not in effect and you wouldn’t know it.
I also recommend using the Google Page Speed dashboard widget for tracking your page speed.
Also, consider making a donation through the support section. I don’t blame you for wanting to wait to see the results, but if you’re impressed, consider a small donation; support WordPress developers, especially when they work for free.
Page cache settings
Now move on to the page cache settings page. Here is where you set the specific settings for how the page cache should operate. Here’s the settings that I recommend:
Enable caching of the home page, SSL requests and requests only for your domain. Also check the box to disable caching pages for logged-in users. I don’t recommend caching feeds because if you make changes, you want it be reflected in your RSS feed, which I have had issues with before, when I had this option enabled. I also don’t recommend caching 404 pages because they shouldn’t be used very often and they will return an error code of 200 (OK) rather than 404 (not found), which is undesirable, so they’re not worth caching.
For most users, you won’t really need to touch the Advanced settings, but you can reduce the Garbage Collection Time, which is how long the cache holds a version of a page before building a new one (the default 3600 seconds – 1 hour should be sufficient). You can also set specific user agents (like bots) that shouldn’t be served pages from the cache, or set specific files which should never be included in the cache.
These options allow the cache to be pre-built (i.e. it builds the pages in the background rather than waiting for someone to view a page and build it on-the-fly. This helps to spread your server load more evenly and reduces load times for those who are trying to view a page that hasn’t yet been viewed, or has expired in the cache. I use an interval of 600 seconds and build 10 pages at a time. You’ll need to adjust this based on your server and the number of pages on your site. If you have 1000 pages and you’re only building 10 every 10 minutes and your cache expires every hour, then you’ll only be able to build 60 out of your 1000 pages before it needs to start over again. Be sure to insert your sitemap address and enable to the preload function.
The purge policy dictates which pages should be rebuilt in the cache when a new post is published. For example, your front page likely has a list of your most recent posts, but if you don’t purge it from the cache when you publish the post, it won’t show on the front page until the cached page expires and it gets rebuilt with the new information (your new post). For me, I purge the home page, post page and blog feed (all feed types). The other pages are so infrequently used that it wouldn’t really matter if they have slightly outdated information – this might not be the case for busier sites.
In the General section, enable the Rewrite option and disable minify for logged-in users. Also set how you want to notified if there’s a problem with minifying your code.
HTML & XML
I recommend enabling all aspects of HTML minifying. This includes leaving the box for not minifying feeds unchecked (so that feeds get minified too).
For the CSS section, you want to be sure to set it up as I’ve shown in the image, by processing @import files (these are files that are imported into other CSS files by using the @import function – we want to minify those as well) and removing comments and line breaks. Leave Combine only unchecked, because we want to take it further than just combining the CSS files (we want to minify them as well).
Again, you don’t need to fiddle around too much with this. You can fiddle with the garbage collection time if you want something more or less frequent than the default 86400 seconds (1 day) or specify rejected user agents or pages that shouldn’t be minified.
Database cache settings
In the general section, make sure that the option to not cache queries for logged-in users is checked. You want to be sure to have the latest version of your site every time it’s loaded.
Again, there’s not too much to fiddle with here unless you have good reason to. As with other caches, you can set garbage collection times, expiration times and pages that shouldn’t be cached.
Object cache settings
As I mentioned earlier, it’s debatable whether this will even do you any good, but if you do enable it, you can pretty much leave the default settings as is. Not much else to say on that one!
Browser cache settings
This section is a bit more important and involved. It tells visitors’ browsers how long to hold on to files it downloads. Here’s how I recommend setting it up:
Essentially, you want to ensure that you set every option for including information in the page header. However, you can leave the options for preventing caching objects after changing settings and not letting WordPress process 404s. It should look like it does in the image to the right.
CSS & JS, HTML & XML, Media & Other Files
All of these sections will essentially look exactly the same, making use of all the header information available. The only thing you’ll want to change is the expiration time in each section. I would set the expiration time for CSS and JS to 2,628,000 seconds (1 month), HTML and XML to 3600 seconds (1 hour) and Media & Other Files to 31,536,000 seconds (1 year). You can adjust these based on how frequently you think these types of files are likely to change on your own site.
The Content Delivery Network section will depend on your specific CDN provider, but I have already created a separate tutorial for setting up W3 Total Cache with a CDN(Amazon Cloudfront in the example). Regardless of your provider though, the long and short of it is that you want to serve as much static content as possible from your CDN rather than your own server.
Once you set up your CDN (if you’re going to use one), you can head back to the General Settings page and enable all the components that you’re going to use. Then log out (since some components have purposely been disabled if you’re logged in) and browse your site. It should be immediately apparent how much faster your site is, but you can also perform some tests using Pingdom Tools, which is very useful for showing your page load speed.
Original article by Dave Clements
Find this useful ? 3