A few days ago we started a series of tutorials about W3TC (W3 Total Cache), which is a plugin that will allow you to cache your blog, so that it runs much faster.
This tutorial series looks like this:
- 1 part: Introduction to Cache
- Part 2: How to configure W3TC
- General Settings - Episode 1
- More General Settings - Episode 2
- Configuring the page cache - Episode 3 (this tutorial)
- Configuration Minifications - Episode 4
- Database Cache Configuration - 5 Episode
- Object and Browser Configuration - Episode 6
- Part 3: All the answers to your questions
- Part 4: W3TC "Mainspan" Parameters
In the previous episode, we were still in part 2, but started with the general settings. Today we will continue with the settings of the cached pages.
When the cached pages is activated from the general settings menu, use the “ Page Cache To access the cache configuration for this element.
When selecting pages to cache, be as inclusive as possible. In most cases, you will want to cache almost all pages.
If your site is available with the https protocol, then you will want to enable SSL Cache (https) For these applications.
Most sites will not benefit from the cached based on the URIs. Enabling this option may produce unexpected results by caching unexpected strings. So unless your search function is widely used for searching with the same terms, leave this option disabled.
Finally, it is advisable not to cache the 404 page. Visitors should not see them very often, anyway, and you will not want Google to index an 404 page as a regular page, which can happen if you enable this option.
The next option, "Cache requests only for (Your domain) the site address ”(Cache requests only) is unchecked by default, but the universal recommendation is to check this option.
The next two options look quite similar, but the explanation below each option clears it up.
« Don't cache pages for logged in users should always remain checked Must always remain checked. If you leave it checked and view your site while connected, your action will cache the page and display it for users who are not logged in.
« Do not hide pages for the following user roles Means that users who match the selected role will access the direct (not cached) version of your site.
The next section, " Cache Preload Is used to build the page cache before it is loaded.
It's a good idea to choose the page cache preload option. The default page interval and page interval values are good settings for shared servers. However, if you have an environment ofaccommodation more powerful feel free to reduce the page update and caching interval.
You will need to add the sitemap URL in the appropriate field of sorts that W3TC uses to use it to identify pages that need to be cached.
Finally, in most cases, you'll want to select the " Preload the post cache ". This will ensure that the cached version of your page is updated every time when you publish a new article.
The cleaning section is used to specify pages to " empty From cache, whenever an article is posted, edited or commented.
You will probably want to leave the cache cleaning options, unless you know you will not want one of the pages to be purged at the previously mentioned events.
The purge limit determines the number of archived pages that must be purged. For example, if your article archive has 20 pages, and you set the purge limit to 15, then the last 15 pages will be purged, while the oldest five pages will not be purged until that the expiration date of these pages arrives.
Setting the value to 0 to purge all pages is a good idea unless some of your archives are very large. In this case, you will need to use a value of 10, which may be suitable for this situation.
If you have built custom pages that must be purged each time the messages are edited and published, you must manually add them to the additional pages field (Option available a little lower).
The advanced section will help you to:
- Controls how W3TC handles specific request strings,
- Exclude certain agents (devices, browsers) that will not receive the cached version,
- Identify cookies that will allow W3TC not to cache pages
- Set up additional specific exceptions.
Take a minute to look at the settings at the start of the "Advanced" section.
« Late initialization This advanced feature allows you to implement page caching in a fragmented way. You can ignore this option in most cases.
« Compatibility mode »: The author of the plugin recommends activating the compatibility mode to minimize the appearance of errors.
« Charset If you notice odd characters appearing in cached pages, enable this option.
« Reject HEAD requests ": Leave this option disabled. The information contained in an HTTP HEAD request is sometimes necessary to build the resulting page. If you disable this option, HEAD request data will not be cached and may break pages that are built using this information.
« Garbage collection interval »: Specify how often expired cached data is deleted. Deleting cached data takes resources of the server, it should not be done too often if your site is busy or if your server is overloaded. The default is appropriate for almost all servers.
« How to cook lifetime Reducing this value will reduce the load on the server because the expiration of the cookies used to authenticate stakeholders expires more quickly. However, setting a value too short will cause users to log in all the time.
The rest of the fields in this section should not be changed unless you know that you want to override the W3TC behavior for a specific cookie, a " user agent Or a page.
That's it for this suite. We will continue in a next episode.
