Share

If you’re researching this topic for the first time, we recommend starting with our initial article – A Beginner’s Guide. Due to the sheer number of potential server setups out there in the wild, out of necessity, we will be sticking to an overview of some of these advanced options as we dive a little deeper rather than getting into detailed configurations.

In this second part of our overview of the W3 Total Cache (W3TC) plugin, we’re touching on some of the more advanced options available.

Overview

A Summary of The Beginner’s Guide

Let’s begin with a brief recap of what was covered in the beginner’s article.

  • Why use the W3 Total Cache (W3TC) plugin?
  • Requirements and installation.
  • Plugin setup guide and features.
  • Alternative cache plugins.
Plugins

The beginner’s article is an introductory overview of using the W3 Total Cache (W3TC) plugin to enhance website performance. We explain the importance of caching for improving page load speeds and overall user experience, detail the initial setup and installation requirements, and highlight the plugin’s key features. The guide is intended to help new users effectively implement W3TC to optimize their WordPress sites

Page Cache

The Page Cache feature creates static cache files for each page and posts on your website, storing them in the server’s memory or disk (depending on the settings). When a page is requested, the server delivers the pre-generated HTML file instead of processing the heavier WordPress PHP scripts each time. This significantly reduces server load, decreases response times, and can significantly improve speed for websites with high traffic or dynamic content.

Page Cache is highly effective for websites with dynamic or primarily static content, like eCommerce stores, discussion forums, blogs, or news sites, where changes to existing content are only occasionally made.

Basic Settings

Utilizing page cache can significantly enhance your website’s speed, especially when evaluating Time to First Byte (TTFB). TTFB represents the duration between a user accessing your website and your server delivering its initial response.

Here, you enable page caching and choose the page cache method depending on whether you are using a shared server, dedicated/virtual server, or multiple servers.

Page Cache Settings

Advanced Settings

1: General

The options listed on the General Settings page are related to your website’s homepage display settings. Your homepage display settings are managed in the WordPress Dashboard > Settings > Reading section.

General Cache Settings

2: Aliases

The plugin optimizes cache utilization by recognizing alias hostnames, improving website performance and user experience across various domains or subdomains. This is particularly useful when identical WordPress content is accessible from multiple domains, and the cache engine will treat them as equivalent for caching purposes.

Cache Aliases

3: Cache Preload

The option allows for automatically priming the page cache by generating and storing cached versions of web pages without waiting for user requests. Users can set the update interval by determining how frequently a new set of cached pages is generated.

You can limit the number of pages created per batch based on server capabilities. Users can also specify a Sitemap URL to guide the primed cache creation, with pages cached according to XML file priorities.

Cache Preload

4: Purge Policy

This option allows users to specify the pages and feeds to purge when new posts are published, edited, or when comments are submitted to posts on your site. The Purge limit setting allows users to control the number of pages purged on post updates.

Purge Policy

5: Rest API

This option allows you to turn on/off, utilizing the WordPress API to enhance performance and scalability. Turning off the WordPress REST API provides an extra layer of security for users who may not require this functionality.

Enabling caching is recommended, especially when using WordPress as a backend for integrations. It significantly improves response times and reduces resource consumption for repeat API requests, which is particularly beneficial for scaling performance.

WordPress Rest API

6: Expert Advanced

  • Late initialization: With this option turned on, the caching engine postpones the initialization of specific caching processes until later in the page generation cycle. This delay allows for improved compatibility with WordPress functionality, especially when fragment caching is involved. It allows for more effective caching of dynamic elements, enhancing the overall performance and responsiveness of the website.

  • Late caching: This option introduces a mechanism to modify the caching process by postponing the extraction of entries during WordPress’s initialization (‘init’) action. This allows for the overwriting of the key used in the page caching process. This key is a unique identifier associated with a specific page or content, and it is crucial for retrieving the correct cached version. Website admins and developers can leverage this option to tailor the caching strategy based on precise requirements, providing elevated customization and flexibility.
  • Compatibility mode: This setting is designed to enhance the plugin’s interoperability with different hosting environments and address specific actions within the WordPress ecosystem. An example use case for enabling Compatibility Mode addresses issues related to Apache web server rules that sometimes conflict with caching mechanisms.
  • Charset: This option specifically addresses character encoding issues related to UTF-8 support. UTF-8 support correctly handles diverse characters, languages, and symbols on a website. This option might be relevant in situations where the default UTF-8 encoding leads to rendering problems or misinterpretation of characters and provides a means to experiment with alternative character encoding settings to find a configuration that resolves rendering issues.
  • Reject HEAD requests: This option handles HEAD HTTP requests and the associated caching behavior. HEAD is one of the HTTP methods browsers use to request only the headers of a particular resource (e.g., a web page) without requesting the full content. HEAD requests are used to gather information about a resource, such as its size or modification date, without downloading all of the content for performance reasons. Turning on this option ensures that requests made using the HEAD method do not result in the caching of full-page content. This option controls caching behavior and prevents scenarios where subsequent requests for a resource might return empty or incomplete pages.

  • Garbage collection interval: This option controls the frequency at which expired cache data is identified as expired or no longer valid and removed. Lower values are preferable for busy websites with high traffic and frequent content updates. Lower intervals ensure that expired cache data is removed more frequently. High-traffic sites with dynamic content or frequent updates benefit from shorter intervals. In contrast, lower-traffic sites with less dynamic content may not require as frequent garbage collection.
  • Comment cookie lifetime: This option refers to the duration for which comment cookies are deemed valid. Comment cookies are data stored on a user’s machine when they leave a comment on a website. Cookies help recognize the user when they revisit the site. TTL (Time to Live) refers to the duration for which a cookie remains valid. By setting a shorter TTL, the goal is to minimize the duration for which comment cookies are stored on users’ devices where there is a desire to reduce the volume of authenticated user traffic, lowering server load and improving overall server performance.
  • Accepted query strings: This option allows administrators to specify a list of URL parameters that must be cached. The query string is the part that comes after the “?” character and consists of key-value pairs separated by “&” symbols. Query strings are used to pass information to a web page, such as parameters for filtering, sorting, or customizing dynamic. By configuring accepted query strings, administrators have the flexibility to customize the caching behavior for URLs with distinct parameters. Everyday use cases include scenarios where specific parameters dynamically alter the content of a page, such as search results, filter options, or pages with sorting preferences.
  • Rejected user agents: This option allows administrators to specify a list of URL parameters that must be cached. The query string is the part that comes after the “?” character and consists of key-value pairs separated by “&” symbols. Query strings are used to pass information to a web page, such as parameters for filtering, sorting, or customizing dynamic. By configuring accepted query strings, administrators have the flexibility to customize the caching behavior for URLs with distinct parameters. Everyday use cases include scenarios where specific parameters dynamically alter the content of a page, such as search results, filter options, or pages with sorting preferences.

Minify

Code bloat is an ongoing problem for many sites, and there are two main culprits when it comes to WordPress:

  • CSS: The arrival of CSS frameworks has spared front-end developers a lot of heavy lifting at the expense of substantially increasing the average code base size in themes.

  • Javascript: An ever improving front and back end feature set in WordPress is increasingly powered by Javascript but at the price of a lot of extra code.

Minification tackles both of these problems by stripping CSS, Javascript and HTML files of all unnecessary information – whitespace and comments for example – in order to reduce their overall file size.

It’s well worth reviewing the Minification sub-section of the W3 Edge FAQ page before starting to explore all the options here.

As we suggested in the previous article, the first step is usually testing the default settings for minification to see what (if anything) breaks. Do this by going to Performance > General Settings > Minify. You’ll typically see the greatest savings here by selecting the disk caching method.

If you do find yourself needing to tweak, then you’ll need to switch the minify mode to manual to fine-tune each option directly from Performance > Minify.

The first thing to notice in the Performance > Minify options is that error reporting is available to help you track down the specifics of any problems you run into.

The second thing to point out is that each of the three options – HTML, Javascript, CSS – can be switched on and off individually to help you troubleshoot with more granularity.

The intricacies of the individual CSS and Javascript options are slightly outside the scope of this overview, but we recommend reviewing Tutsplus’ Advanced Minification Settings article for a more detailed breakdown of the individual options.

You also have the option further down the screen in the Advanced section to get even more specific by disabling minification entirely for chosen pages, Javascript or CSS files or even particular user agents.

With the range of theme and plugin configurations that this module can potentially affect, controlled experimentation is very much the key.

Take advantage of the ability to test items individually and make sure to use the plugin’s import/export options to help document your decisions and dial in the setup that is right for you.

Database Cache

As we noted in the first article, WordPress is a database heavy application.

Many of the calls made will be exactly the same as the site uses, so it makes little sense to be hitting the database time and again if the results of a particular set of queries can be cached.

Database caching enables you to do just this while also being smart enough to know when the information behind the scenes has changed and needs to be served up anew.

W3 Total Cache’s own installation guidelines point out that enabling this option on shared hosting setups may actually be counterproductive, though some hosts such as GoDaddy claim to support it.

Our suggestion is to test in isolation on your own setup to judge its effectiveness.

The types of performance gains on offer here will very much depend on the complexities of your own setup, with the main distinction being whether the information is stored on disk or in-memory with a solution such as APC or Memcached.

The common consensus seems to be that in-memory solutions provide the best results for the database cache.

You can select the database cache method in Performance > General Settings > Database Cache.

Further fine-tuning is then available in Performance > Database Cache.

The main option to pay attention to here is to make sure that Don’t cache queries for logged-in users is selected in order to ensure that normal WordPress functionality continues to work as expected.

The default values for Maximum lifetime of cache objects and Garbage collection interval should be adequate for most setups.

The Never cache the following pages box gives you a handy way of being able to exclude sections of a site if you run into compatibility difficulties with a particular plugin or part of your site.

Object Cache

WordPress ships with a number of object caching options built in for developers to access and make use of.

The general theory here is similar to that of database caching: information associated with WordPress operations can be stored and reused quickly without having to be constantly regenerated.

The first point to notice here is that this is likely to do more harm than good if you find yourself on shared hosting, so unless you are managing your own server setup it is best to ignore this option.

The option can be enabled by going to Performance > General Settings > Object Cache and selecting the Object cache method of your choice.

As with the previous database option, in-memory storage is likely to yield better results here if you have it available to you.

Further tweaking is available via Performance > Object Cache but the default settings here should be more than suitable for the average setup.

Content Delivery Networks (CDN)

Using a CDN (Content Delivery Network) means offloading the delivery of a certain subset of your content to a company that specializes in getting that content to the user as quickly as possible, regardless of where they are in the world.

They do this by having numerous data centers located strategically around the globe where your content is mirrored and delivered to the user from the location nearest to them.

In the case of WordPress, this would typically involve the delivery of static assets such as image files along with CSS and Javascript files.

CloudFlare and MaxCDN are two of the best known providers in the business and both offer user friendly options for those just starting to get their feet wet with CDNs.

In terms of the backend of W3 Total Cache, there are three general areas to configure in Performance > CDN. Firstly, you need to decide which types of content you will be offloading to the CDN in the General options.

Secondly, you need to establish the connection with the CDN itself via the Configuration panel.

Options here will naturally vary from provider to provider but the good folks over at WPBeginner have an excellent breakdown of how to install MaxCDN with W3 Total Cache that should give you a good idea of the overall process.

The default Advanced settings should work out of the box on most setups, so begin there before starting to tweak.

W3TC Resources And Showcase

Many blue-chip companies trust the W3 Total Cache plugin for their websites. Along with Frederick Townes’ work for Mashable, high-profile sites such as yoast.com, ilovetypography.com, smashingmagazine.com, and Matt Cutts have all plumped for this plugin as their caching solution in the past.

Resources

As you explore W3 Total Cache further, it’s worth bookmarking a few references for general information and troubleshooting purposes:

  • W3 Total Cache plugin homepage: The Installation and FAQ tabs here address many common issues users run into. Make sure you review them both carefully. You can also access the support forums from this page.

  • W3 Edge FAQ: This set of FAQs provides a little more detail, including coverage of technical questions such as, for example, whether to choose opcode caching or memcached. It’s well worth a detailed read before you start integrating on your own site.
  • Stack Exchange: As always, Stack Exchange and Stack Overflow are likely to be your friend at some stage.

Showcase

The following links provide some more detailed breakdowns of real-world W3 Total Cache performance that you might find useful when digging deeper into how best to implement it on your own site:

  • MyBloggingThing: A good overview of how W3 Total Cache can fit into an overall optimization strategy.

  • DashboardJunkie: An excellent deep-dive comparison of real-world W3 Total Cache performance as measured against other popular caching solutions.

Summary

We hope the points above will shed further light on some of the more advanced features of W3 Total Cache and help you make the most of it within the parameters of your own particular setup. Two takeaways:

  • If you’re managing your own servers – virtual or dedicated – database and object caching both stand to bring major performance increases.

  • Minification and using a Content Delivery Network are options available to all and should bring significant gains to both you and your users.

Subscribe To Our Newsletter

Receive all of the latest news and updates fresh from ThemeFusion!

Leave a comment