With over 1 million active installations, W3 Total Cache is one of the most popular caching and optimization plugins in the WordPress repository. Unlike other WordPress optimization plugins which offer a relatively simpler and streamlined interface, W3 Total Cache gives complete control over your WordPress site’s caching configuration.
The granularity of W3TC’s settings makes it an ideal plugin for advanced users and developers who want ultimate control over their WordPress sites. In this article, we’ll take an in-depth look at W3 Total Cache’s settings, and we’ll give you our recommended configuration to boost the performance of your WordPress site.
If you’re a Atakdomain user, you won’t need to configure certain settings in W3 Total Cache because our hosting stack already has many optimizations built in. For example, server-level page caching via NGINX is enabled by default on all Atakdomain sites, so you won’t need to enable it in W3 Total Cache. If you’re setting up W3TC on a Atakdomain-hosted site, just pay extra attention to the setup instructions below. We’ll be sure to let you know if a specific setting isn’t needed or compatible with Atakdomain.
If you don’t have W3 Total Cache installed on your site, you can install it right in your WordPress dashboard. Just search for “W3 Total Cache” on the “Add Plugins” page and install it.
Install W3 Total Cache.
There is also a Pro version of W3 Total Cache, which can be purchased on BoldGrid’s website. The Pro version comes with a few additional features like REST API caching, Google Maps caching, and additional extensions. In this article, we’ll be using the free version from the WordPress plugin repository.
Boost the performance of your #WordPress site 🚀 and take control of advanced features with this guide to W3 Total Cache settings ⚡️CLICK TO TWEET
Where are W3 Total Cache Settings Stored?
After installing W3 Total Cache, you’ll see a “Performance” tab in the sidebar of your WordPress admin dashboard. Clicking on the “Performance” tab will reveal a variety of submenus like “General Settings”, “Page Cache”, “Minify”, and more.
W3 Total Cache sidebar settings.
You can also access W3 Total Cache settings using the “Performance” tab in your WordPress admin toolbar.
W3 Total Cache admin toolbar settings.
Before we get into how to configure W3 Total Cache, let’s quickly go over how to purge or clear your cache. If you hover over the “Performance” tab in the admin toolbar, you’ll see two purge options.
Purge W3 Total Cache.
Let’s dive into W3 Total Cache’s “General Settings” menu to configure a few basic settings.
By default, every single request to your WordPress site is rendered in real-time. For certain kinds of sites like eCommerce stores or discussion forums, dynamic rendering is ideal. However, for blogs, news sites, and other sites that don’t require dynamic content, adding a page caching layer can improve performance and reduce server load.
Enable page caching in W3TC.
If your site is hosted on Atakdomain, you don’t have to worry about page caching. We have a high-performance server-level configuration that automatically caches your site’s pages into static HTML files. If your host does not offer page caching, you can enable page caching in the W3 Total Cache plugin.
Minifying your HTML, CSS, and JavaScript assets can reduce the overall size of your site’s pages by removing unnecessary whitespace. For most WordPress sites, enabling W3 Total Cache’s “Minify” feature and selecting the “Auto” option for “Minify Mode” will be just fine.
Minify HTML, CSS, and JavaScript assets in W3TC.
In some cases, minifying assets may cause CSS or JavaScript code to break, which often results in visible errors on the frontend. If you notice unusual issues on your site after minifying assets, we recommend working with a developer to identify the assets causing issues. After that, you can use the “Minify” feature in manual mode, which allows you to bypass minification for specific CSS and JavaScript files.
WordPress is a dynamic CMS, which means PHP workers are constantly executing code in the background. Opcode cache/u> helps speed up your site by storing compiled PHP code, which makes subsequent requests that require the same code faster.
Enable opcode cache in W3TC.
If your site is hosted on Atakdomain, you don’t have to worry about enabling an opcode caching layer in W3 Total Cache. We enable OPcache, an opcode cache, on all live environments. OPcache is disabled on staging environments to ensure compiled PHP code is not cached and does not interfere with site development and debugging.
If your host does not offer opcode cache, we recommend enabling it in W3 Total Cache. Keep in mind that the opcode cache feature is only available in the Pro version of W3TC.
W3TC’s database stores the results of MySQL database queries. While this feature does sound useful, we recommend keeping it disabled and using an object cache instead.
Database caching in W3 Total Cache.
We’ve found that in some cases, the database cache feature may result in high CPU usage. This means the amount of CPU saved by storing database query results could end up getting offset by the increase in CPU required for this feature.
In the context of WordPress, an object cache stores the results of completed database queries. WordPress actually has a built-in object cache, but it only retains data for a single page load. This allows for more efficient page rendering because it ensures a page load will not need to waste CPU resources running identical database queries.
While WordPress’ default object cache is undoubtedly beneficial for performance, an object cache that retains data across page loads is even better! W3TC’s “Object Cache” feature adds a custom caching script in your /wp-content directory, and changes the behavior of WordPress’ object cache to retain data persistently (across multiple page loads).
We recommend enabling W3TC’s object cache feature on your WordPress site to speed up requests that utilize database queries if your site is not hosted on Atakdomain.
W3 Total Cache object cache.
If your site is hosted on Atakdomain, we offer a high-performance object caching layer powered by our Redis add-on. Redis is an open-source in-memory data structure store that’s often used for database and message broker applications.
Since Redis caches data in RAM, it allows WordPress to access cached data from a persistent object cache that is much faster than traditional object cache configurations.
Browser caching can speed up your WordPress site considerably by storing static assets like CSS, JavaScript, images, and fonts locally. Browser caching uses an expiration period to determine how long to cache assets for. On the modern web, most developers specify an expiration period of 1 year for static assets.
Enable browser caching in W3 Total Cache.
For sites hosted on Atakdomain, we enforce a 1 year cache period for static files. This can be verified by checking the cache-control header for a static file hosted on Atakdomain. If your web host does not enforce a “far-future expiry time” for browser caching, you can enable the “Browser Cache” feature in W3 Total Cache and configure the expiration period.
If you’re using a <CDN, or content delivery network, to offload static files to data centers around the world, you can configure W3 Total Cache to rewrite URLs for “theme files, media library attachments, CSS, JS” and more with your CDN hostname.
CDN settings in W3 Total Cache.
If your site is hosted on Atakdomain, we recommend using Atakdomain CDN, our high-performance content delivery network powered by KeyCDN. When Atakdomain CDN is enabled, static file URLs will be automatically rewritten to be served from Atakdomain CDN.
If you prefer to use another CDN provider or if your site is not hosted on Atakdomain, you can enable the “CDN” feature in W3 Total Cache and add your CDN URL.
A reverse proxy sits between your web server and WordPress, and can be used to perform various logic-based manipulations on incoming requests. W3TC supports Varnish, which is a popular “HTTP accelerator” for caching and serving data with the goal of reducing backend load.
In order to use Varnish, the Varnish package must first be installed by your host. If you’re a Atakdomain customer, do not enable the reverse proxy option as our infrastructure is not designed to work with Varnish.
W3TC’s “User Experience” optimization lets you enable lazy loading, disable emojis, and disable the wp-embed.js script. We recommend enabling lazy loading on your WordPress site to speed up page loads. If you’re not already using browser-native or plugin-based lazy loading, we recommend using W3 Total Cache for lazy loading.
User experience settings in W3TC.
In today’s world, most operating systems have built-in support for <emojis. Thus, you may want to disable WordPress’ included emoji script if you’re not a heavy emoji user. Using W3TC to remove wp-emoji-release.min.js will help you shave an HTTP request and remove ~10KB from your page loads.
Similarly, if you don’t embed WordPress posts, you can disable the wp-embed.js with W3 Total Cache. Disabling this script will not affect oEmbed functionality for embedding YouTube videos, SoundCloud streams, etc.
W3 Total Cache has a few miscellaneous settings that you can configure as well. If you want to display a Google Page Speed dashboard widget in WordPress, you can input your Page Speed API key. There is also an option to display the Page Speed rating in the menu bar for each page on your WordPress site.
Miscellaneous settings in W3 Total Cache.
For the other settings like “NGINX server configuration file path”, “enable file locking”, “optimize disk enhanced page and minify disk caching for NFS”, we recommend leaving them in their default settings unless you have a specific reason to change them.
If you’re troubleshooting an issue on your site, W3 Total Cache has a handy “Debug” menu that lets you disable specific caching layers and optimization settings. For example, if you notice a visual glitch on your site, you can enable debug mode for the “Minify” option, which will insert HTML comments into your page’s source code to help you troubleshoot.
Debug mode in W3 Total Cache.
Since the debug mode feature puts additional load on your server resources, we recommend only using it in a staging environment or during low-traffic hours. Furthermore, be sure to disable debug mode after you’re finished with your troubleshooting!
After you’ve finished configuring your settings, you can use W3TC’s “Import/Export” function to create a backup of your configuration. W3 Total Cache has a lot of settings, so being able to export a full backup is great for peace of mind. Furthermore, it allows you to easily replicate your custom W3TC configuration across multiple sites without having to manually configure anything.
Import and export W3TC settings.
Let’s dive into W3 Total Cache’s “Page Cache” settings. Remember if your site is hosted on Atakdomain, you don’t need to worry about page caching – so feel free to skip this section.
W3 Total Cache’s “Aliases” feature allows you to cache identical WordPres content that’s available on different domains. We do not recommend enabling this feature. If your WordPress site is accessible over different domains (e.g. domain.com and www.domain.com), it’s best to set up a 301 redirect rule to forward requests to your primary domain to avoid duplicate content penalties from Google and other search engines.
The “Cache Preload” feature crawls through your sitemap and makes requests to your site’s pages to preload the page cache. For most sites, we recommend disabling cache preload because it can cause server resource spikes that offset the potential performance benefits.
If you do want to enable cache preloading, W3TC lets you specify a sitemap URL, update interval, and pages per interval. Make sure you don’t set the “update interval” and “pages per internal” too high to reduce the chance of CPU spikes.
W3TC’s “Purge Policy” lets you specify the pages and feeds you want to automatically purge after posts are published or edited. For most sites, the default settings (front page, posts page, and blog feed) should be enough. If you want to add additional pages to the purge policy, there are a variety of options you can configure.
WordPress’ included REST API lets you query for JSON-formatted data. REST API is used by a variety of plugins, and is crucial for headless WordPress setups. Depending on your exact use case for the REST API, caching the query results may be a good idea. REST API caching falls under the “if you need it, you’ll know it” category, so if you’re unsure whether or not to enable REST API caching, we recommend leaving it on “Don’t Cache”.
In W3TC’s “Advanced” page cache options, you can customize a variety of settings including “accepted query strings”, “rejected user agents”, granular cache bypass settings, and more. For example, if you need to configure your W3 Total Cache to never cache posts under a certain category or tag, you’ll be able to do so in the “Advanced” options.
Since these settings can be very site-specific, there are no “recommended settings” that we can provide. With that said, if you’re looking to customize a very specific aspect of your site’s page caching behavior, definitely give the advanced options a look.
Next, let’s go over W3 Total Cache’s “Minify” settings.
Formun Üstü
Formun Altı
Join 20,000+ others who get our weekly newsletter with insider WordPress tips!
In the “HTML & XML” section, you can configure HTML minification settings.
In the “JS” section, you can configure JavaScript minification settings.
In the “CSS” section, you can configure CSS minification settings.
The “Advanced” section contains a few additional settings to customize minification behavior.
The rest of the “Advanced” section includes input fields that allow you to specify asset files that should never be minified. There is also a “Rejected User Agents” field that lets serve non-minified files to certain user agents. Lastly, you can add external asset files to be included in W3 Total Cache’s minification process.
Next up on the list is W3TC’s “Object Cache” settings. For most sites, the default settings will work just fine, but let’s go over them regardless.
Most WordPress hosts, including Atakdomain, already implement proper browser caching headers at the web server level. If your host does not, or if you want to customize browser caching behavior further, you can do so with W3 Total Cache.
In “Browser Cache” settings, the default settings for the “General”, “CSS & JS”, and “HTML & XML” and “Media & Other Files” sections are adequate for most WordPress sites. Since there are so many settings on this page, we recommend consulting with a developer before making any changes to browser caching behavior. With that said, below are a few key settings to pay attention with regard to browser caching.
The “Browser Cache” settings page also contains a variety of settings related to security headers like Content Security Policy (CSP) and X-XSS Protection. We always recommend working with a qualified developer to go through these settings because incorrect configurations can directly impact your site’s user experience. For example, enabling the HSTS header without a proper SSL certificate and HTTPS configuration may render your site inaccessible.
W3 Total Cache’s “User Agent Groups” feature is very powerful if you need to redirect traffic based on a user’s device type. For example, you can configure your site to render with a different theme if a user visits your site from a mobile phone. Similarly, you can redirect users to a completely different site if your mobile site lives on a unique subdomain.
In the age of responsive web design, we don’t see too many use cases for this particular feature. Nowadays, the best practice is to make your site responsive from the start instead of relying on multiple themes or a mobile-only subdomain.
An HTTP referrer is an optional HTTP header that provides information about where a request originated from. For example, if a visitor clicks on your site from a Google Search listing, the HTTP referrer would be google.com.
Struggling with downtime and WordPress issues? Atakdomain is the hosting solution designed with performance and security in mind! Check out our plans
In W3 Total Cache, you can define custom caching behavior based on a request’s HTTP referrer with “Referrer Groups”. For example, you could create a referrer group that consists of search engines, and customize caching behavior for requests from those domains only.
Similar to the “User Agent Groups” mentioned above, you can also redirect requests to a different domain with the “Referrer Groups” feature. Most WordPress sites won’t need to set up referrer groups, so we don’t recommend configuring any.
The latest caching group that W3 Total Cache supports is “Cookie Groups”. This feature lets you create unique caching buckets and behaviors based on a request’s cookies. Similar to the “User Agent Groups” and “Referer Groups”, most sites will not need to set up a custom cookie-based caching configuration. If your site requires cookie-based caching, we recommend working with a developer to configure it correctly.
Now, let’s move on to W3 Total Cache’s CDN settings.
Next, let’s customize the “User Experience”, or lazy loading, settings in W3 Total Cache.
W3 Total Cache offers various extensions to integrate with third party services. W3TC currently has extensions for the following services.
If you are using any of these services on your site, we recommend setting up the relevant extension to ensure proper compatibility with W3 Total Cache. In this section, we’ll take a look at Cloudflare extension for W3 Total Cache.
To integrate Cloudflare with W3 Total Cache, you’ll need two pieces of information from your Cloudflare dashboard – account email and API key. The account email is the email address you use to log in to Cloudflare. Let’s take a look at how to set up a Cloudflare API key.
In the Cloudflare dashboard, click on the “Overview” tab. Next, scroll down and click Get Your API Token in the right sidebar.
View your Cloudflare Global API Key.
Scroll down, and click View next to “Global API Key” to get your Cloudflare API key. Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.