Many time WordPress blog owners install a cache system on their blog, but does not understand two thing: how a cache system works and when a cache system can be dangerous.
A cache system works, basically, saving the generated page (HTML page) on first request, and serving the saved content on subsequent requests without re-generating it. To generate a page involves a lot of work: WordPress activation, database queries, plugins and widgets activation. Every operation cost CPU and memory.
A cache system cannot “cache” an image, neither compress it. If an image is 100 kilobytes, every time a user get it navigating the bog, generates 100 kilobytes of traffic. Some advanced cache, like W3 Total Cache can distribute images over a CDN, but it’s an advanced topic and bloggers who need a CDN are not too many.
When a cache system can be dangerous? When you have plugins that, for a given pages, generate two or versions. The extreme situation is mobile plugin, which for every page generate a mobile version based on the device which is surfing the blog. Every cache system tries to solve the problem avoiding to cache the page when recognized mobile devices are surfing the blog or caching (like Hyper Cache and other) the mobile version too.
Caching more than one version of a page means to be able to serve the right version on subsequent requests. It’s not always simple.
Another problem is when you have plugin (like Newsletter) that let you to hide part of a post, unlocking that hidden piece only for regular subscribers. A cache system has no way to know that a particular page can be rendered in two different version (the one incomplete and the one complete) so the risk is that it caches the complete one and starts to serve it for everyone.
Another example is user data disclosure. WordPress, after a user comments on a blog, pre-fill the comment form with user data: name, email, url. The email is th delicate part: no one want his email published on a blog.
If the cache system caches a page generated by WordPress with the comment form pre-filled, the user data will be shown to everyone! Cache plugins usually have a filter to detect is the surfer is a commenter (if he has some specific cookies) and if so do not serve the cached content but a fresh page every time. You can identify such filter if you have a caching plugin that integrates with Apache modifying the .htaccess file. The rule to detect commenter looks like:
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
Hyper Cache (and may be other caches) can be configured in a different way: to force WordPress to ignore the commenter data or better to ignore commentators at all and avoid WordPress to pre-fill the comment form, letting the cache to always work. That make the user’s experience on the blog worse, but can save an upgrade of the server.
There is a third solution, as implemented by Lite Cache, a my cache plugin exercise, which solves the commentators problem.
Let me to step back on the odd problem of plugins that create a different version of a page. Is not as uncommon as you can thing. Newsletter plugin with content locking feature, Protector plugin, various membership plugins can work on specific page to hide and show content. How can we deal with this pages?
First approach is to remove the cache plugin. Second is to configure the plugin to not cache (or never serve cached version) of those pages: can be a boring work. Third, the cache plugin can be configured to cache the “normal” version of the page (the one with hidden content) and serve the cached version to everyone except for who has the right to see the content.
Those users can be identified with a cookie (Newsletter uses the “newsletter” cookie) and the cache, detecting it, can suspend it self for that specific surfer. The drawback? The cache suspends it self for any request from those users. If you have a lot of recurring readers with a cookie that disable the cache… it’s you would be without the cache.
The solution I prefer is to avoid caching the pages with two version because usually they are dynamic pages used to sell or to show user data or… Avoid caching of those pages can be managed on caching plugin configuration but there is a better solution: when those pages are generated or transformed by third party plugins, it should be enough to make those plugins communicate with the cache system.
For example, Hyper Cache has a global variable ($hyper_cache_stop) set to false by default. Any plugin can set it to true and hyper cache won’t cache the “current” request. I always use it on my plugins like Newsletter, when they manipulate the page content in a user dependent way.
Do a serious analysis of what approach is the best is not easy and strictly depends on the kind of traffic. To make easy to stop caching of specific pages transformed by third party plugins, I have a proposal: I hope to receive comments from cache authors.
