Caching is one of the most effective methods to reduce server load and improve load times on a WordPress site. There are two commonly cited caching methods one can utilize. Surprisingly, most guides recommending caching methods to improve WP performance do not mention the significant drawbacks. In fact, many common “guides” for increasing WP performance with caching and gzip compression may instead decrease your site’s performance.
WordPress’s built-in Object Cache:
WordPress apparently has a built-in object cache feature that used to be enabled by default in v2.0.2 and lower. I could not find any official explanation for why the cache is now disabled by default, but I suspect it has to do with this PHP code injection vulnerability which can allow hackers to compromise WordPress installations using the object cache. The solution says to upgrade to v2.0.3. Does this mean the vulnerability was fixed in v2.0.3, or simply worked around by disabling the object cache?
Pros:
- Built-in feature of WordPress without plugins or code modifications
WordPress still generates fully dynamic pages so no functionality is lost
Cons:
- It is now disabled by default, perhaps for a good reason? The vulnerability found in 2.0.2 might not be fixed
Less effective than WP-Cache which generates static pages (read on)
To enable WordPress’s Object Cache feature, copy and paste the following code into wp-config.php.
define('ENABLE_CACHE', true);
WP-Cache Plugin:
WP-Cache is a popular plugin that creates static versions of your WordPress pages instead of compiling PHP code whenever a visitor requests a page. Unfortunately, WP-Cache is incompatible with the built-in gzip compression feature of WordPress. gzip compression decreases the size of webpages significantly, usually by much more than 50%. The recommended solution is to set “zlib.output_compression = On” in php.ini, something most shared webhosts do not allow. For those of us who cannot modify php.ini to enable transparent gzip compression, there are some workarounds not supported by the author of WP-Cache.
The most common yet problematic “fix” is as follows.
1. Turn off gzip in the options.
2. In wp-cache-phase1.php
Insert:
if ( extension_loaded(’zlib’) ) ob_start(’ob_gzhandler’);
Before:
foreach ($meta->headers as $header) {
3. In /wp-content/advanced-cache.php
Insert:
if ( extension_loaded(’zlib’) ) ob_start(’ob_gzhandler’);
Before:
foreach ($meta->headers as $header) {
The problem with this “fix” is that cached pages are compressed upon every single request. This can drastically increase CPU load during high traffic situations, which defeats the purpose of WP-Cache. We cache pages so that each request doesn’t require CPU crunching to compile PHP. This method makes your site do CPU crunch to gzip pages per request. In other words, enabling gzip using this method probably decreases your site’s performance on high load.
Fortunately, Nick Georgakis seems to have come up with a better solution to allow WP-Cache to coexist with gzip compression without modifying php.ini, and without constant recompression of pages. He makes use of the gzcompress function instead of the more convenient but buggy ob_gzhandler function. gzcompress is only called once per cached page, which gives us both the benefits of compress and caching. Unfortunately, it requires quite a bit of modification of source code, something I’m not comfortable with and don’t have time for right now. See this post and its comments for a lot of good information and source code for this hack.
Update: I lied. 
See this post for instructions and code for using WP-Cache and gzip compression together sensibly and efficiently.
Conclusion:
I have enabled WP’s built-in Object Cache. hoping that the vulnerability has been fixed since v2.0.2. As I’ve never suffered a hack before, this might be foolish bravado. Use caution if you enable the Object Cache feature on an important site.
I will disable WP-Cache and enable the WP’s built-in gzip compression. To handle traffic surges, I’ll use a more low-tech solution of redirecting visitors from high traffic sites to my Coral CDN mirror using .htaccess. I’ll post more on that after some research. Besides, my webhost NearlyFreeSpeech.NET claims to be no stranger to the Slashdot/Digg effect.
I tried turning off gzip compression and enabling WP-Cache; the site seemed really sluggish.
Now… if I can just get flooded with traffic somehow. 
If you liked this post, please subscribe to my feed. Thanks for visiting!
You would probably have much better luck with WP-Super Cache (which doesn’t invoke PHP for EVERY cached page like WP-Cache does). I write about how to do this, and other problems to consider with caching and wordpress in my post Traffic Proofing Wordpress.
Check out the best farming places in World of Warcraft.