Speed Up Your Server’s Response
This article is about page caching on a shared host, using W3 Total Cache. Other articles:
- Improving page load speed using W3 Total Cache, – minifying files;
- What the W3 Total Cache Browser Cache Setting do, and mean;
The trick is to “cache” each page. When your visitor requests a page, your webhost executes some code, e.g. get_header(), then transmits the file. Why not execute this code beforehand, store, i.e. cache, the result, and transmit the result when the visitor requests it.
Fig 1 – General Settings
Enable page cache in the General Settings tab. If your hosting is low cost, then your choice is either Disk:Basic and Disk: Enhanced. Disk: Enhanced, if available, is better.
I suspect Disk:Basic is worse, because W3Total Cache runs additional code that redirects the visitors request to the cached file. Disk: Enhanced is quicker, because W3Total Cache sets up the redirects in the wp-config file, which execute faster. However, some security plug-ins don’t give W3Total Cache permission to write code to the wp-config file.
This is all fine, if each page is static, e.g., doesn’t change every minute. W3Total Cache has more complex caching options, which you only get with expensive hosting services.
- Opcode Caches: When the visitor requests a page, the server first compiles the PHP script, then executes the compiled version. Finally it transmits the data. An Opcode cache stores the compiled PHP script, ready for immediate execution. The W3Total Cache page cache lists different types of opcode caches.
- memCached: Instead of storing files on a hard disk which takes ages to access, why not store them in speedy RAM, which the server can quickly access.
Fig 2 – Page Cache Settings
Fig 2 shows the General settings within Page Cache. I can’t think of anything to explain here.
Fig 3 – Cache Preload
If you clear the page cache, the cache empties. So, the first visitor waits while W3 Total Cache re-builds the cache for page, before transmitting the page.
Automatically priming the page cache builds the page cache automatically. Some recommend an update interval that doesn’t fall on an hour, when the web-server might be running another task. Hence a figure like 908 seconds means W3 Total Cache creates a new page cache every 15 minutes. Since my pages don’t frequently change, I’ve set 4 hours: 14,409 seconds.
The Cache Preload wants a sitemap, and it is worthwhile preloading the cache when a post is published.
Fig 4 Advanced Settings
The plug-in author advises enabling Compatibility mode. It is supposed to enable additional functinality that improves interoperability with wordpress.
Garbage collection determines how often W3 Total Cache removed expired files. So the Garbage collection interval should be longer than the Page Cache Update Interval.However, as the notes say, the length of time that cached pages live is determined by the HTML Expires Header Lifetime in the browser cache settings. This suggests that the Cache Preload Update Interval and the Advanced Garbage Collection Interval should be similar amounts of time.
