Why WordPress should be served Cached
To Cache or to not Cache
When it comes to self-hosting WordPress, Caching is an inevitability.
The biggest strength of WordPress is its dynamic nature. A browser view of a WordPress website is like a “skin” which interfaces with dynamic components under the hood. But once a WordPress website starts growing, this also becomes the biggest weakness of WordPress. The “skin” becomes overloaded with more and more dynamic components. and a simple pageview becomes acrimonious for the server, as it struggles to deliver a “freshly prepared skin” to the browser for each and every page view. On the user end, the lag becomes noticeable.
There are of course, some theoretical alternatives to caching, such as pruning your plugins and becoming a Cloudflare subscriber. But there is no substitute to Caching, when it comes to improvement in speed.
Myth: Caching is a Compromise
It first glance, Caching appears to be the very antithesis of WordPress. If WordPress was meant to provide dynamic content, why go back to serving static files? In reality, Caching will not compromise the dynamic nature of your WordPress site. It will more or less act like an intermediary between your dynamic WordPress site and its viewers. Ninety per cent of WordPress sites do not need to be dynamic in realtime (as WordPress by default allows them to be). Caching can be tweaked according to your requirements. Setting the cache to be refreshed every hour is considered to be the ideal compromise between keeping your website dynamic and serving static files.
The ideal Caching plugin
There has been considerable debate on what is the ideal WordPress Caching plugin. There are also rumours that Caching may one day be integrated into WordPress. For the time being, Check out the exhaustive testing conducted by Kyle Robinson Young at Tutorial 9.
It is also evident that caching works differently in different server environments. For example, in shared hosting environments (where websites do not have dedicated IP addresses), the results tend to be different.
Of late, Quick Cache has gained a lot of attention as a lightweight caching plugin with out-of-the-box functionality. It appears to be ideally suited for a shared hosting environment. But what makes this plugin different is its complete rethinking of the concept of caching. To quote Lead Developer Jason Caldwell,
Quick Cache is extremely reliable, because it runs completely in PHP code, and does not hand important decisions off to the mod_rewrite engine or browser cache. Quick Cache actually sends a no-cache header ( yes, a no-cache header ) that allows it to remain in control at all times. It may seem weird that a caching plugin would send a no-cache header :-). Please understand that the no-cache headers are the key to the whole concept behind this plugin, and they will NOT affect performance negatively. On the contrary, this is how the system can accurately serve cache files for public users vs. users who are logged in, commenters, etc. That is why this plugin works so reliably.
== ‘Quick Cache’ vs WP Super Cache ( Main Differences ) ==
* Quick Cache uses a combination phase ( with less code ) and NO mod_rewrite rules ( no .htaccess file is required ). Super Cache requires an .htaccess file with mod_rewrite rules that serve GZ files. Quick Cache works right out of the box, so it is MUCH easier to install. All you have to do is activate the plugin and enable caching. All of its other options are already pre-configured for typical usage. Using an .htaccess file is 100% optional, and it’s for GZIP compression only.
* Quick Cache provides a complete set of decision engine options for its entire methodology. Super Cache offers On, Half On and Off. It has fewer options on the back-end panel. Even though Quick Cache is pre-configured for typical usage, it is important for a site owner to have full control at all times. Even those advanced settings that tend to scare novice users away; those have all been included with Quick Cache. Quick Cache teaches you advanced techniques with its examples and built-in documentation for each option.
* Quick Cache maintains absolute control over who sees cached pages. Super Cache allows browsers to cache-the-cache. In other words, some control is lost, and people who ARE logged in may see (not-logged-in) versions of pages. This technique gives Super Cache its name though. It makes things Super Fast. However, that may not be practical for some database-driven sites that are updated all the time and have lots of different plugins installed. If you offer membership or provide special content for members, you may want to try Quick Cache.
* Quick Cache provides you with the ability to customize the Salt used in cache storage. Super Cache does not provide this capability. It could be done with instruction, but you would need to dig into the code for that. The ability to easily customize the Salt used in cache storage is very important. Many sites offer unique services and serve special versions of certain files. The ability to control how different versions of pages are cached, is critical to advanced webmasters that need to tweak everything and customize the caching engine to their specific needs.
General Installation notes can be found here. In addition, remember to set the Mutex Option (in Quick Cache Configuration) to Flock for a shared hosting environment. Note that some database caching plugins can actually decrease speed in a shared hosting environment, and should not be used in conjunction with Quick Cache. Check the cache folder to make sure that old cache files are successfully being deleted. For example, if you set the cache expiration time to one hour, you should not see any files from yesterday in the cache folder. And never leave the cache folder (or any web folder) publicly writable. Only the server needs to access it.
The beauty of Quick Cache is that it makes GZIP compression (for website images) entirely optional and independent of Quick Cache operation. Many shared webhosts disable mod_deflate their Apache servers because it uses a lot of server CPU power. This means your website’s speed cannot be further increased (in addition to caching). Quick Cache will still function regardless.