This post is for you if you’re interested in learning about the best cache plugins. We’ll go over one of the most popular caching plugins, W3 Total Cache (W3TC).
These plugins allow you to reduce the amount of time visitors have to wait for your content to load by speeding up the time it takes for your site to load.
To help you know how to use the W3 total cache plugin, we’ve put together a step-by-step guide for installing W3 Total Cache on your WordPress site. So let’s get started!
How Do Caching Plugins Work?
Unless you revamp your site or add new content, your site’s pages and articles are unlikely to change significantly once they’ve been published. A cache plugin, on the other hand, creates a static version of your website that serves your users. This implies that if a visitor revisits your site, they will see a cached version of it.
What is W3 Total Cache?
The speed of our website is one of our priorities. We use the W3 Total Cache plugin to ensure that our site scales and can handle large amounts of traffic without crashing. It also makes it easier for us to interface with MaxCDN. Mashable, Matt Cutt’s blog, CSS-Tricks, and WPBeginner are among the sites that employ the W3 Total Cache plugin. Popular hosts such as HostGator promote it.
Page Cache, Database Cache, Browser Cache, Object Cache, CDN integration, and other caching features are available. For most beginners, this sounds like a tangle of gibberish. So, let’s go over it a little further.
Installing W3 Total Cache
- Go to your WordPress account and sign in.
- Select Permalinks under the Settings menu.
- After choosing a permalink structure, click Save Changes.
- Click Add New from the Plugins menu.
- Look for W3 Total Cache.
- Under W3 Total Cache, choose Install Now.
- Activate the plugin by clicking the Activate Plugin button.
Configuring W3 Total Cache
Click the Performance menu button in your WordPress admin panel to proceed to the General Settings page.
Toggle all caching on or off at the same time using the checkbox. Leave this option unchecked because it is rarely utilized.
If you’re testing out new options and don’t want to disrupt your site, the preview mode comes in handy.
You can test any of the settings by enabling preview mode and seeing how they affect your website. When you turn off preview mode, the settings will revert to their original state.
Article Continues Below
The caching of individual pages on your site is known as page cache. The following are the recommended settings.
- Enable page caching
- Disk Enhanced Page Cache Other choices are available if you are using a VPS or numerous servers. If you’re doubtful, go with Disk Enhanced.
The process of merging and condensing CSS and JS files is known as minification. When opposed to multiple little files, a single huge file places a lower demand on a server.
If you’re using Cloudflare, the minification will be handled by Cloudflare. In such a situation, disable minify in W3 Total Cache.
PHP is cached via the Opcode cache. PHP is used in parts of WordPress and is run on a regular basis. For a performance gain, the Opcode cache can cache these code blocks.
W3 Total Cache’s opcode cache is only accessible in the pro edition. Enable both the settings and the performance test if you have the pro version.
It overloads the server, especially on shared hosting, therefore leave it disabled. To improve efficiency, the database cache stores the results of common database queries.
The following are the recommended settings:
Database Cache: enabled
Database Cache Method: Disk
You should disable the database cache if you use a CDN like MaxCDN, KeyCDN, CloudFront, or others.
If you disable it, the website and dashboard will normally slow down.
To reduce server load, Object Cache caches the results of sophisticated database queries. A simple search on your website, for example, will do a comprehensive search of your WordPress database. This type of query can be cached for faster results.
In some circumstances, object cache might cause websites to slow down. We suggest that you test the Object cache with your website first.
Browser cache allows your website’s assets to be cached in the visitor’s browser.
- Enable the browser cache.
CDN is hosted on numerous servers across the world by CDNs (Content Delivery Networks). The CDN then serves the visitor, which reduces the strain on your server.
The response time for requests is also lowered because the request is served by the server nearest to the visitor.
- CDN : Enabled if you are using a CDN, disable for Cloudflare.
- CDN Type : Select the service that you want to use
If your site has a huge number of simultaneous users, your server may become stuck between fetching data and checking incoming requests.
In this case, a reverse proxy comes in handy. A reverse proxy is a server that sits in the middle of your visitor and your actual server. When you make a request, the proxy server receives it instead of your server.
After then, the proxy server can access the cache and provide service to the visitor. This frees up your primary server to focus on other duties.
It is recommended to use a reverse proxy server such as Varnish, although its setup is hard for the faint of heart. We don’t advocate installing Varnish without the assistance of an expert.
New Relic, a performance monitoring service, works with W3 Total Cache. You can sign up for a free account and be notified if the performance of your application or server degrades.
A fragment can be a social element (such as a Facebook Like Box), an e-commerce element (such as a shopping cart or wishlist), or other user-specific features.
This poses some difficulties because dynamic and personalized elements cannot (or should not) be cached because the data is unique to each user.
Between no caching and a complete page cache, fragment caching can help. W3 Total Cache Pro is the only way to get this feature, and it’s normally reserved for dynamic sites.
Licensing – Your license key goes here if you’re using the pro edition of W3 Total Cache.
Google PageSpeed Widget – Instead, I propose using the GTmetrix plugin for monitoring.
Enable the appropriate setting if you’re having problems with one of the caches. W3 Total Cache generates logs in the HTML source code that you can use to troubleshoot the problem.
Turning on this option on a live website is not recommended because it will reveal a lot of information about your website. Turning one or more features off will also cause your website to slow down.
You can use this section to back up your W3 Total Cache settings or to import fresh ones.
Let’s look at the “Page Cache” settings in W3 Total Cache.
- Cache Front Page – The front page of most websites is usually the page that receives the most traffic. As a result, we recommend that you enable this option.
- Cache Feeds – WordPress provides a variety of RSS feeds that can be used by third-party apps and services such as Feedburner to show your site’s content. While RSS isn’t as popular as it once was, we nevertheless recommend that you enable it.
- Cache SSL (HTTPS Requests) – Enabling this parameter may improve performance if your web server does not force HTTPS for all inbound requests. There’s no need to enable this if you’re already mandating HTTPS on your web server.
- Cache URIs with Query String Variables – A query string is a parameter added to the end of a URL (for example, /?version=123). Query strings are commonly used in WordPress to request and show specific data from the database. We recommend keeping this deactivated unless you have specific query strings you’d like to cache.
- Cache 404 (Not Found) Pages – This option is deactivated by default in W3TC. If you’re utilizing the “Disk Enhanced” page caching approach, this is most likely due to caching behavior. 404 pages will now return a 200 response code if that option is selected. 404 pages should, in theory, return 404 response codes, thus we urge that you test this setting with your caching configuration to see whether it works.
- Don’t Cache Pages for Logged In Users – This option should be enabled. Users who are logged in are usually updating pages. Users would have to clear the cache on a regular basis if caching was enabled in order to notice page updates.
- Don’t Cache Pages for Certain User Roles – For certain WordPress user roles, this option allows you to avoid the cache. This option will have no influence on cache behavior if the “don’t cache pages for logged-in users” option is already activated.
The “Aliases” feature of W3 Total Cache allows you to cache identical WordPress information across several domains. This functionality is not recommended to be enabled. To avoid duplicate content penalties from Google and other search engines, put up a 301 redirect rule to divert requests to your primary domain if your WordPress site is available via multiple domains (e.g. domain.com and www.domain.com).
The “Cache Preload” function crawls your sitemap and makes requests to the pages on your site to preload the page cache. We advocate eliminating cache preload for most sites because it can generate server resource spikes that cancel out any performance gains.
Configuring W3 Total Cache
The “Cache Preload” feature scans through your sitemap and sends requests to the pages on your site to preload the page cache. We advocate deactivating cache preload for most sites because it can generate resource spikes on the server, negating any potential performance gains.
W3TC enables you to select a sitemap URL, update interval, and pages per interval if you really wish to enable cache preloading. To avoid CPU spikes, make sure your “update interval” and “pages per internal” aren’t set too high.
The “Purge Policy” feature in W3TC allows you to designate which pages and feeds should be automatically purged once posts are published or updated. The basic settings (front page, posts page, and blog feed) should suffice for most sites. There are several options to specify if you wish to add new pages to the purge policy.
REST API (Representational State Transfer)
The REST API supplied with WordPress allows you to query for JSON-formatted data. REST API is essential for headless WordPress deployments and is utilized by a number of plugins. Caching the query results may be a smart idea depending on your specific REST API use case. REST API caching is in the category of “if you need it, you’ll know it,” therefore if you’re not sure whether or not to enable it, we recommend leaving it on “Don’t Cache.”
You can configure a range of parameters in W3TC’s “Advanced” page cache options, including “approved query strings,” “rejected user agents,” granular cache bypass settings, and more. For example, if you need to set W3 Total Cache to never cache posts from a specific category or tag, you can do so in the “Advanced” settings.
There are no “suggested settings” that we can supply because these parameters can be very site-specific. With that in mind, the advanced options should be explored if you want to tweak a very particular feature of your site’s page caching behavior.
- Default Lifetime of Cache Objects – The expiration time for unchanged cache items. A larger item cache derives from a longer time period. We recommend leaving the default number or lowering it if you’re concerned about your server’s storage capacity.
- Garbage Collection Interval — This parameter determines how often expired cache data is removed from the system. For most sites, the default value of 3,600 seconds (1 hour) should suffice.
- Global Groups — This option lets you build up shared cache groups across multiple sites in a multisite network. Unless you have a special need to change this setting, we recommend leaving it alone.
- Non-Persistent Groups — You can use this parameter to specify which object groups should never be cached. Again, we advise staying with the default settings.
- Enable Caching for wp-admin Requests – By default, this option is off, and we don’t advocate enabling it because it can have negative consequences. Furthermore, the wp-admin dashboard is rarely used by visitors to WordPress sites.
W3 Total Cache’s creator recommends that you leave the minify settings alone. This suggestion is made for a reason.
Minify has the potential to completely destroy your website. There is also no general recommendation for the options you should enable because it is dependent on a number of elements unique to your website.
A working set of settings may operate for a while, but a simple theme change or even the installation of a plugin could damage it. We recommend leaving these settings at their default values unless you have a professional assist you.
We recommend speaking with a developer before making any changes to browser caching behavior because there are so many options on this page. With that in mind, there are a few important browser caching options to be aware of.
Expires Headers Lifetime — For optimal browser caching, setting a lengthy “expires headers lifetime” is critical. Static assets such as CSS, JS, pictures, and fonts have a one-year lifespan at Kinsta. Set this value to 31536000 if you’re using W3TC to manage browser caching (1 year).
Cache-Control Policy – To ensure that browsers can cache your static content, set the cache-control policy to “public, max age=EXPIRES SECOND”.
Use HTTP (gzip) Compression – GZIP compression significantly reduces the file size of HTML pages and assets before they are sent to visitors, therefore if your host’s server setup supports GZIP, make sure to enable this option. There is no need to enable GZIP compression in W3TC if your site is hosted on Kinsta because it is already configured as part of our default configuration.
Remove query strings from static resources – A query string is a string appended to the end of a URL route to specify request parameters or force a web server to deliver a new item. Query strings begin with and most web servers are set up to skip the cache for query string queries. Because these requests require PHP to render pages, removing query strings from page requests helps to reduce server load. We don’t recommend removing query strings from static resources in W3 Total Cache since they assist ensure that your users get the most up-to-date CSS and JS files.
A range of security header settings, such as Content Security Policy (CSP) and X-XSS Protection, is also available on the “Browser Cache” settings page. Working with a trained developer to go over these settings is always recommended because erroneous configurations can have a direct influence on your site’s user experience.
User Agent Groups
A user agent is a piece of software that acts on the user’s behalf. The real person viewing the webpage does not exist from the server’s perspective.
Only the browser that is sending the request is understood by the server. The server responds to those requests without knowing who the actual user is.
The user agent in this scenario is the browser.
W3 Total Cache’s user agent area allows you to create groups of specific user agents and customize their experience.
Let’s adjust W3 Total Cache’s “User Experience,” or lazy loading setting:
- Process HTML Image Tags – Select this option to ensure that images are loaded slowly.
- Process Background Images — If you’re using background to display an image in CSS, this option will allow you to lazy load those images.
- Exclude Words – You can specify the text to bypass lazy loading in this area. If you add no-lazy-load to this field, for example, an image displayed will not be lazy-loaded.
- Script Embed Technique – Customize the loading method for the lazy loading script with this setting. For most sites, the default async approach is the best solution. The inline technique can be used to decrease the number of HTTP requests required to load a single landing page if your site just has one.
W3 Total Cache Alternatives
Here are the top three most popular W3 total cache options.
WP Fastest Cache
This is another excellent cache plugin that converts your dynamic WordPress site into static HTML files. That is, when a page is rendered on your website, PHP and MySQL are used, which implies the system requires RAM and CPU, and this plugin optimizes performance accordingly.
The nicest aspect of the Comet Cache plugin is that it takes a real-time snapshot of every blog post, page, category, link, and so on, which is then intuitively kept (cached) so that it can be referenced later when the user requests a page, link, or post.
That way, all of the processing time that has been slowing down your website loading times will be saved, and your website visitors will be able to access your site much faster.
WP Super Cache
This plugin produces static HTML files from your dynamic WordPress blog in order to offer bespoke cached files targeted to visitors surfing from various areas on your website.
Wrapping Things Up!
W3 Total Cache isn’t the easiest plugin to use. However, given the extensive features it provides and how difficult they might be, it’s understandable. The plugin comes with a full explanation of each feature, which is extremely excellent.
So, if you want your website to function better and load faster, install a caching plugin like W3 complete cache and you’ll witness incredible improvements to your website.
Let us know how you get on!