What is W3 Total Cache?
W3 Total Cache is one of the most popular caching plugins available for WordPress users. In fact, it is one of the first caching plugins that came into existence along with WP Super Cache. Many other followed.
W3 Total Cache, despite not providing true server-side caching, happens to be one of the most powerful caching plugins available. Configuring the plugin is quite difficult, and hence, I don’t usually recommend it to rookies. For rookies, WP Fastest Cache or WP Rocket Cache that are much easier to configure and offer the same desired result.
In this W3 Total Cache review, I am going to show you the test results without and without caching plugin installed (albeit, without a CDN), and then walk you through the setup process. You ready for that? Of course, you are!
Site Speed with and Without W3 Total Cache
The most important thing is to know how the speed of your site improve after you install this cache plugin. If you can find that out, you can quickly go ahead and decide whether to read this W3 Total Cache review in its entirety or not.
So, here are the results:
Mobile Speed After Installing W3 Total Cache
Desktop Speed After Installing W3 Total Cache
Note that the speed you see above is without:
- A CDN
- Google ads or ads from any ad network
- No Google Analytics
When you start using ads or add Google Analytics and other scripts, there will be a drop in speed. This is where CDN can help a bit.
Okay, now that you know what W3 Total Cache can offer in terms of speed boost, let’s go through the setup and walkthrough as a part of this W3 Total Cache review.
W3 Total Cache Review – Setup and Walkthrough
W3 Total Cache, in its core form, is a free plugin. However, you can always go for their free version if you want. That however, doesn’t mean that the free version is not going to give you the desired result.
In fact, the free version is extremely powerful! To install W3 Total Cache, you must head over to the WordPress plugin repository from your website’s dashboard and search for W3TC. The first result you see is the one that you need to install. Click on the Install button, and then on the Activate button.
Once you activate the plugin, you will see the list of plugins and the dashboard menu for accessing the plugin settings. Here is what you will notice:
Take a close look at the image above. You will see the plugin access menu on the left (highlighted in yellow). You will also notice (on the top) that it asks to activate Yoast SEO extension for W3 Total Cache.
You will see that notice only if you have Yoast SEO installed on your website. We will get to this segment later.
Also, you can see W3 Total Cache installed on the site with a quick link to Settings.
If you click on the Settings link, you will receive the following screen:
You will also notice that the dashboard menu expands with various options showing up. This is what you will see in the dashboard menu:
That’s an awful lot of options and it can be very intimidating for the first-time users. That’s one of the reasons why I stated that I don’t recommend this plugin to rookies.
However, if you still want to carry on with W3 Total Cache, I will go ahead and explain everything in this review. Read on…
Clicking on the next button will show you a new screen where you can test the page cache. Don’t be shy. Just click on it! Nothing disastrous is going to happen.
Once you click on the Test Page Cache button, it will show you the results for the Time to First Byte under several conditions. The first option is with no caching enabled and the next options are with different caching engines.
This is what you will see:
You will notice the type of storage engines available and the one that is most recommended for your website. You can select the recommended caching type or select something else. In the image above, you can see that Disk: Enhanced is the recommended caching type.
If you have Redis or Memcached or APC or other forms of storage engines available, you can see the reduction value. If other engines are not available, W3 Total Cache will simply show that they are not available.
Once you select the one you prefer, click on the next button again.
Now, the plugin will test the database cache.
You can hit the Test Database Cache button without fearing anything. Hitting the test button is not going to drop an A-bomb on your website. Just hit it and see what happens.
Once you hit the button, this is what you will see:
If you have Redis or Memcached enabled (which you won’t have in most of the shared servers), W3 Total Cache would have recommended either of the two. However, if they are not available, it is recommended that you DO NOT use Disk cache because the default server database engine might be faster (true in the example above).
Redis or Memcached is usually available in cloud hosting by default. If you have VPS or dedicated hosting, you can enable them by yourself. If you are on shared hosting, you may be out of luck.
Do not select something else, because that might cause problems with your website. So, leave database cache disabled (that is selected as None) and click on the next button.
This will give you the option of testing Object cache.
As before, click on the button without any fear. Once you click on it, this is what you will notice:
What exactly is object cache?
Object cache allows caching database query results so that when someone makes the same query that needs to return the same result, it is served from the cache, instead of querying the database.
This helps to reduce the number of database queries and prevents the server from becoming overwhelmed quickly. This feature is particularly helpful for high-traffic sites.
WordPress has a built-in object cache mechanism since 2005. Unfortunately, it is not a very efficient one. WordPress’ default object cache stores objects only for a single page load. This means that at the end of each request, the objects will be discarded. Once discarded, a page has to be built from scratch the next time a request comes in.
This is where persistent object caching is required. The most popular choice for that has been Memcached. But Redis came in later with the capability of doing everything that Memcached can do, but with extra set of features.
So, as of now, Redis has become a popular choice.
Some shared hosting providers will not have support for Redis or Memcached (as shown in the example above). You don’t have to bother about anything else. If you don’t find Redis or Memcached, ask you hosting provider.
If your hosting package is not offering it, either move on to a better hosting, or if that is not a feasible option for now, simply stick to what you have. You can either disable object cache completely (select None), or you can use the Disk method. I will recommend that you use Disk.
Once you have selected Disk, click on the next button again to test Browser Cache:
Be the fearless fellow you have been so far and click on the Test Browser Cache button. Once you do that, you can see this:
Leave it enabled and move on! Click on the next button again, and select lazy loading of images. This is what you will see:
By default, the check box will be unchecked. Select that option and move on to click the next button.
This is where you will see the initial results and the list of things you should do next. This is what you will see:
Now, click on the dashboard link to reach the actual plugin dashboard where you can fine-tune the rest of the settings.
W3 Total Cache – Walkthrough
Once you click on the dashboard button you see above, you will see a frightening sight!
This is the dashboard you will see:
Yes, the dashboard looks extremely busy and frightening! You will have options of running compatibility checks, emptying caches, and more. As you scroll down, you will see more! There will be options of setting up StackPath CDN, and you will see the overview of options available when you upgrade to the premium version and so on!
I will not focus on the premium version in this review. Just to let you know, the premium version will give you access to premium support, plugin setup, etc.
You can ignore all of them for now and move on to the next tab in the menu, which is the Feature Showcase tab.
The Feature Showcase Tab
This is what you will see when you switch to this tab:
As the name suggests, it is a showcase of all the features available with W3 Total Cache. Several of these features are premium features that will be available only when you opt to purchase their pro version.
Other features you see on this showcase are available with the free option. You can safely ignore this tab and move on to the next tab.
The General Settings Tab
This is where everything starts. You need to fine-tune the settings from here.
Here are the options you will find in this tab:
General: This segment will allow you to enable a preview mode in which you can preview the impact of different settings of the caching plugin before you roll it to the production site. I will suggest that you enable this feature. If something goes wrong with the settings you implement, you can change them to fix your site before publishing the new settings.
Do remember that the preview mode will remain active even if you publish your settings. You must manually turn off the preview mode.
Page Cache: You defined this during the initial automated setup process. So, leave it untouched.
Minify: This is where you need to make changes. Enable minify and set the process to ‘Auto,’ unless you want to manually decide which files you want to minify and which ones you want to exclude from minification.
When you enable minify, you will get a warning. Usually minification is safe, but in rare cases, minification may break your site. Minification simply means clearing up white spaces, and comments that are not needed for proper functioning of the files.
You can minify HTML, JS, and CSS files. Choose the default method. No need to try out the other methods as they have a high potential of breaking your site.
Remember, everytime you are changing something, click on the Save Settings & Purge Caches button instead of Save all settings. This will ensure that the proper cached files are available.
Opcode Cache: Leave it as is! No need to change anything.
Opcache is a type of Opcode caching in which the human-readable PHP code is compiled into a code that your web server can understand. This code is called Opcode. Opcode caching occurs when a PHP file loads on a particular webpage for the very first time. The Opcode is then cached in the memory of the server so that for every subsequent visit, the Opcache doesn’t need to be translated into Opcode. It will be served from the server’s memory. This increases the page speed.
The default of Opcode: Zend Opcachde is perfectly fine. Don’t fiddle with it!
Database Cache: Remember, you had set this during the initial setup process? So, there is no need to fiddle with this either. Leave this thing as is!
Object Cache: Again, you had already set this previously during the initial setup. Leave it! No need to change anything.
Browser Cache: Leave it please! You had already set this during the initial setup.
CDN: This is where you can integrate CDN with W3 Total Cache. Unfortunately, W3 Total Cache doesn’t give a direct and easy way to integrate Cloudflare with it unlike WP Fastest Cache or WP Rocket. W3 Total Cache recommends using StackPath CDN.
You can, however, use Cloudflare with W3 Total Cache through the extensions that the plugin has to offer. If you want to use Cloudflare, you need to disable CDN here.
If you enable CDN here, you need to make sure that you are using one of the CDN types you find in the dropdown.
Also, if you are using the premium version of W3 Total Cache, you can use FSD CDN offered by W3TC.
If you enable the premium version, this is what you will see in the CDN segment:
In the premium version you will see what is called FSD CDN. FSD stands for full site delivery. This means everything from your site including fonts, media, HTML, CSS, JS, etc. will be delivered by CDN.
If you are using simple CDN, only a few types of files will be delivered via CDN. Rest will be delivered via your website server. Of course, FSD CDN gives a faster website.
Do note that the default CloudFlare (even with free W3TC) offers full site delivery. So, if you want to upgrade to W3TC only and only for FSD CDN, it is totally meaningless.
Reverse Proxy: It is a very advanced feature that you can use only when you are using a private hosting. Most-likely, you are not doing that. So, you need to leave it disabled.
Message Bus: You can safely ignore this thing. It is designed for server clusters and massive and complex applications. Message Bus is available only for Pro users, and trust me, you will need help from W3TC developers to configure everything related to Message Bus.
Just remember that Message Bus has nothing to do with average Joes and Janes like us!
User Experience: This segment will help you to improve user experience. Enable all the options you find here.
If you have Google Maps on your website, you should lazy-load that as well to improve performance. You can enable it and configure the caching mechanism in the User Experience page.
Remember, lazy-loading of Google Maps is available only for premium users. If you are using the free version, you will not get this option.
Statistics: This segment will give you statistics about the cache performance. I will never recommend turning ON this option.
The reason for not recommending the activation of this option is simple. It will consume additional resources. While you may argue that you can always turn this on if you are on a powerful server, the thing is, you really don’t need it.
Fragment Caching: If you are unsure of what it is, it is better to leave this segment untouched. But since this review focuses on telling you everything, here is what you need to know:
Fragment cache is an interesting concept. In case you are not aware, whenever a WordPress site’s page loads, PHP processing takes place and the MySQL database is queried.
There are times when a code block can take long for execute. So, everytime the code block runs, it will eat up a significant amount of time.
With Fragment caching ON, the output of the code block is stored for a certain time that is predetermined.
If the code runs again within the predefined time limit, caching system will simply ignore the block of code and print the stored output on the page, thereby saving some time and speeding up the webpage.
Fragment caching is quite powerful and technical. You need to use it very cautiously. With W3 Total Cache, there are different methods of Fragment cache available for different types of server. For instance, if you are on a shared server, you should use the Disk method. If you are on a server that allows Memcached and/or Redis, select the appropriate one.
Licensing: This is where you provide the license key for the pro version. There is no brainer here. Once you purchase the license, enter the key in the provided field.
Miscellaneous: This is where you can integrate Google PageSpeed Insights, lock your website files, etc. I don’t see a reason why you should be using this in the first place. You don’t need any of these things.
In all likelihood, you are not using a hosting service that uses Network-based File System (NFS). If you are on such a server, you need to disable ‘file locking’ and enable ‘optimize disk enhanced page and minify disk caching for NFS.’
Debug: Disable this option, please! If you enable this, performance will take a hit. Use this only when you need to debug the caching errors.
Import / Export Settings: This segment will allow you to import the settings of W3TC from another website to a current website. Alternatively, you can export the current settings to use somewhere else.
The Page Cache Tab
Again, there are multiple segments here. Don’t be too confused. The Page Cache tab gives you fine controls over how your website pages are cached.
Use the recommended settings for each segment.
Enable Cache SSL only and only if you are using SSL certificate. Most of the web hosting companies will give you free SSL using Let’s Encrypt. You can also get free SSL from your CDN provider (Cloudflare provides free SSL).
Please do not cache 404 pages.
Aliases: If you are serving your website content through different domains (totally not recommended), you should enable this option. Otherwise, leave it disabled.
Cache Preload: I have explained preload several times earlier. If you read my reviews of WP Fastest Cache or WP Rocket, you will find the explanation there. Still, for your convenience, cache preload refers to creating fresh cache pages at certain intervals.
You can automatically set preload as per your preferences. You can also set cache preload depending on your sitemap. If you are using Yoast SEO plugin, the sitemap is perfectly compliant. You can enter the sitemap for cache preloading depending on your sitemap.
The settings to use for cache preload are shown in the image.
Purge Policy: Page Cache: This is where you define the circumstances under which the old caches are purged and new caches are created.
The default settings are perfectly fine, but if your sever is a powerful one, you can provide additional options like Post comment pages, Post author pages, Post comments feed, Daily archive pages, Monthly archive pages, Yearly archive pages etc.
You can set the purge limit to ‘0’ to ensure that all pages are purged and rebuilt!
REST API: In case you are using WordPress backend for certain integrations (for example, allowing certain mobile apps to access your site), you should consider REST API caching. If that’s not the case, you can leave the default option (Don’t Cache) enabled.
If you are hundred percent sure that you will not be using REST API ever (for example, you are building a simple blog that will not integrate mobile apps or other applications), you can completely disable REST API.
Advanced: Okay, this is where you need to be cautious about what you are doing. There are too many options here.
Let’s take a look at them:
These are the first few options you find here. The only two things you should be fiddling around with are ‘Compatibility mode,’ and ‘Charset.’ Always enable compatibility mode and disable UTF-8 blog charset support.
Leave the remaining (that you see in the image above) untouched. They are perfectly fine!
Let’s continue exploring other options.
Accepted query strings: Look at this example: https://example.com/path/to/page?name=ferret&color=purple.
Here, name=ferret and color=purple are two different query strings. If there are certain URLs that use specific query strings that you don’t want to cache, you need to list all the query strings in the given area. One URL may have multiple query strings separated by a delimiter (delimiter example “&”).
Rejected user agents: If there are certain user agents that W3TC should not send cached pages to, you can put all of them in the given area.
Never cache the following pages: There may be certain pages that you may not want to cache under any circumstance. You can list all those pages. You can even add entire directories if you don’t want them to be cached. Some pages and directories are already added by default. You don’t need to add anything else, unless you have specific needs.
Never cache pages associated with these categories: If there are certain pages associated with certain categories that you don’t want W3TC to cache, you can list the category slugs in this area. Make sure that you are listing one entry per line.
Never cache pages that use these tags: If there are certain pages that use certain tags that you don’t want to cache, list all the tag slugs (one item per line).
That’s not the end! There are more options available in the advanced segment. Take a look:
You will also have the option of not caching several pages by author and custom fields. Also, if you previously made a list of pages that you never want to be cached, but want a few exceptions, you can add them to the cache exception list. Some options are already populated, and they work perfectly fine.
Again, if there are certain pages on your website that doesn’t have a trailing slash in the URL, you can cache them as well. The prepopulated options work just fine.
The final two options, that is, specify page headers and handle XML mime type – just leave them untouched. They are not required for proper functioning of your website cache.
The Minify Tab
Be careful about whatever you are doing here. Your settings can break the site. So, thoroughly test your site after you enable any option here. Let’s start with the segments in this tab.
General: The default settings are perfectly fine. Do not tamper with them. Also, there is no reason to disable minification for logged in users.
If any error occurs you can get a notification either through an email or through admin notification or both. You can enable this option. There is no harm in doing so.
HTML & XML: This is where you can minify HTML codes on your website. You will get several other options like inline CSS and inline JS minifications, feed minification, line break removal, etc.
If you are activating inline CSS and JS minification, make sure that you are checking your website properly. This may break your website.
Not enabling them works perfectly fine.
As far as the Ignored Comment Stems is concerned, the minification feature will not remove comments from HTML file that include certain terms. A few terms are already included in the field, but you can add more! Usually, what’s there by default is good enough.
JS: Please enable JS minification! This will remove white spaces and comments from the JS files. The minification method you choose can break your website design and function. So, experiment. There are various options available. The default selected option is combine and minify.
The other options available for minification method are minify only and combine only. Experiment with the options. Everytime you select an option, click on the Save Settings & Purge Caches button to see what changes take place.
- Non-blocking using JS
- Non-blocking using “async”
- Non-blocking using “defer”
Usually, the default option (blocking) gets rid of the PageSpeed Insights notification of removing render-blocking assets.
You need to understand that certain JS and CSS files are render-blocking by design. So, removing them or blocking them is not going to help.
About HTTP/2 push, you should be enabling this only if your server supports that protocol. You should ask your web hosting provider about that. Alternatively, if you are using CloudFlare or any other CDN, that supports HTTP/2 protocol, you need not worry about enabling this. The CDN provider will take care of that.
CSS: Please activate CSS minification. The minification method can be tricky. Combine & Minify may work well for you. For others, minification only or combine only can work best.
For Minify engine settings, only enable the last option that states eliminate render-blocking CSS by moving it to HTTP body.
Do nothing for import handling and enable HTTP/2 only if your server supports that. If your CDN supports HTTP/2, don’t bother about enabling it.
Advanced: There’s nothing much to do here. Leave everything as is.
Leave the time for updating external files and garbage collection as is! The first option will update the cache files and replace them with new caches. The next option will completely remove the expired cache files.
The other options are quite self-explanatory. In case you don’t want to minify certain pages, CSS, and JS files you need to list them appropriately.
If you don’t want certain user agents to receive minified content, you can specify them too. If there are external files (CSS, HTML, JS) and libraries that you don’t want to be combined, you can specify them as well.
The Database Cache Tab
Do not touch anything here! Everything is the way it should be. You make a mistake here and your website goes for a toss.
I will repeat – DO NOT TOUCH ANYTHING UNLESS YOU ARE A DATABASE ADMINISTRATOR AND YOU KNOW WHAT YOU ARE DOING.
The Object Cache Tab
Again, everything is what it should be. So, please do not change settings here. Faulty settings can cause issues.
Just like database caching, object caching is an advanced setting. Don’t mess with this if you don’t have the necessary knowledge.
The Browser Caching Tab
There are many options here, but the only thing you should be considering is setting the global browser caching policy.
Use the following settings for the general segment:
- Set Last-Modified header: checked
- Set expires header: checked
- Set cache control header: checked
- Set entity tag (ETag): checked
- Set W3 Total Cache header: checked
- Enable HTTP (gzip) compression: checked
- Enable HTTP (brotli) compression: checked (if available)
- Prevent caching of objects after settings change: unchecked
- Remove query strings from static resources: checked
- Don't set cookies for static files: checked
- Do not process 404 errors for static objects with WordPress: checked
- Rewrite URL structure of objects: unchecked
Leave rest of the options you see on that page to their default settings. Make sure that you are not messing around with the Security Headers segment. Any faulty settings can be disastrous.
The Cache Groups Tab
Just leave this thing. Incorrect configuration can be disastrous for your website.
The CDN Tab
This is where you need to configure CDN. W3 Total Cache suggests using StackPath CDN, which is a great option. If you want, you can always use it!
Now matter what CDN you are using, you need to make sure that you checking all the options available in the General segment.
This is what you need to set:
Below the general segment are the advanced settings. You shouldn’t be tampering with those settings. They are perfectly fine.
The Fragment Cache Tab
I mentioned it earlier, and I will mention it again. Fragment cache is very technical and you should not be using it unless you know what you are doing. Your website should work perfectly fine without fragment cache provided you have a simple website or blog.
I, for instance, never use fragment cache for my blogs. That’s not needed at all! If you have a very complex website, it is better you approach the support team to get the right configuration.
The User Experience Tab
This plugin has a few settings to play with. The default settings are perfectly fine and you don’t need to change anything.
If you are using Google Maps via one of the three plugins mentioned (see the image above), you can enable lazy-loading for the map, too!
The Extensions Tab
This is where you can enable several extensions. For instance, if you want to integrate CloudFlare with W3TC, you need to enable the necessary extension.
The extensions you activate will depend on your requirements. You need not activate all of them.
There are a few more tabs available. They are:
- FAQ: This will take you to a new webpage where you will find answers to frequently asked questions.
- Support: This is where you will find different support options. What’s awful is that despite purchasing the pro version, W3TC will charge you for things like plugin configuration, CDN configuration, eliminate render-blocking JS, etc. That’s truly funny, and guess what? Their prices are outrageous.
- Install: This is where you will find information about the installation. You will see what changes have been made to your .htaccess files.
- Setup Guide: The setup guide will pull up the initial automated setup process.
- About: The about segment speaks about W3TC and all that it can do. It also give you the list of people involved in the development of the plugin.
- Statistics: This is where you will get usage statistics. You need to enable it. I will not recommend doing that because it will eat up server resources.
Pros & Cons of W3 Total Cache
- It is a powerful caching plugin that can help you to achieve incredible speeds even without a CDN. However, I will recommend using a CDN for even better performance.
- The free version is incredibly powerful. The pro version brings extra features that are great for further enhancements.
- It supports a wide range of CDNs.
- It gives fine-tuned control over different settings – something you won’t find with most of the caching plugins.
- For simple tasks like plugin setup, CDN configuration, etc. the company charges extra even if you have the pro version. Competitors like WP Rocket will do that for free.
- Extremely difficult to setup, especially for rookies. The plugin can be extremely confusing. In fact, the plugin happily ignores the fact that most of the users will be rookies.
- Doesn’t offer prefetch of DNS for external resources.
- Doesn’t offer localization of fonts or Google Analytics.
- There is no built-in ability for offering WebP conversion of images.
Do I Recommend W3 Total Cache?
Speed is what matters! If you are okay with the extreme complexity of the plugin, it is okay to use W3 Total Cache, but the free version is what you should go for. The premium or the pro version is no less than a gimmick.
If the developers are charging extra for plugin configuration, server conflict resolution, CDN setup, etc., and that too an outrageously high amount, it is better you go for WP Rocket. Not only is WP Rocket a fantastic plugin, but also offers exceptional support and features.
So, I do recommend W3 Total Cache, but only its free version! I do not recommend the pro version.