Hyper Cache is a lite, simple to configure and highly performant cache plugin for WordPress.
Hyper Cache is a cache system for WordPress. I wrote it because my hosting provider was very low in resources, particularly on the MySql side. Hyper Cache solved all my performance problems. It probably can solve yours as well!
The aim of Hyper Cache is to be efficient but easy to configure. It has a simple configuration panel with preset values ready for your blog. You can tweak the configuration to improve even more the performances or to address specific needs.
It is bbPress ready: Hyper cache is able to detect new topics and replies and refresh the forum cached pages.
Download and Support
Download it here and post your issue here.
How to detect if it is working
Use a clean browser (not the one you use to administer your blog or open a new browser window in anonymous mode), and load the same page a couple of times. Look at the page source and at bottom you should see the Hyper Cache signature.
Another way is to use a browser developer tool and look at the network panel: the response header for a cached page should contains the specific “X-Hyper-Cache” header with value “hit” or “hit-mobile”.
Hyper Cache main features
- easy installation: just activate Hyper Cache and it works with a set of default values
- easy configuration: you can just ignore the configuration panel (even if enabling the compression is a good idea!)
- mobile cache: separated cache for mobile devices (when you use mobile oriented themes or plugins)
- theme switch for mobile devices
- compression support to optimize your bandwidth usage and the overall page load speed (important with mobile devices)
- configurable bypass (when the cache should not… cache): by page address, user agent, cookies, feeds and so on
- 404 caching
- bbPress ready: can cache and refresh bbPress pages
- special refresh options
- configurable caching only of the newest posts
Download and Installation
Download it from the WordPress Plugin Repository or search for “Hyper Cache” in your blog plugin panel. Once activate, go to the configuration panel and follow the instructions.
Usually you need wo add a lince of code in the wp-config.php file just after the define(‘WPLANG’, ‘xx_YY’):
define('WP_CACHE', true);
If that definition is already present in your wp-config.php file, modify it as shown above.
The plugin options are explained inside the configuration panel, here you can find some deeper concept or annotations.
Configuration
Cached pages will be valid for…
It’s a time in hours used to consider still valid an already cached page. If a page is in cache but older than the specified number of hour, it is not considered and regenerated.
Cache folder
Usually you should leave this option empty to use it’s default value (auto computed by Hyper Cache). The cache folder where cached pages are store is locate at wp-content/cache/hyper-cache. You can specify an absolute path lo move it but pay attention: is you wrongly point the cache folder to an existing folder with files, on cache refresh they can be deleted.
Compression
Compression should be enabled for two reason:
- save a bit of bandwidth (mostly of the bandwidth is used for images and not for the text part of a page…)
- serve the content as quickly as possible to make the user experience better
More, if you have a mainly textual blog, you’ll save traffic on the client side, which is very good for mobile user with expensive data plans.
If you note strange characters instead of the regular page when the compression is enabled, it means your server is already compressing the pages on the fly. Seen that a cached compressed page is much more efficient than compressing the page on the fly, you should configure the server to not compress the html and xml mime types (but let it compress JavaScript and CSS).
Browser caching
When the browser caching is enabled, Hyper Cache tells browsers to keep a copy of the page in their cache and to not request the page again (until it expires).
The expiration time can be set in hours in the option panel or it will be computed as the time remaining for the page in your blog cache. For example, if the page has been cached 1 hour ago and your cache timeout is set to 24 hours, the browser will receive the suggestion to keep the page for 23 hours.
Pay attention: I usually keep this option off because if you change something of important in your blog, regular users will see always the already visited pages and cached in their browser. Only a forced reload will refresh the local user cache but not all web users know about it.
Bypasses
Hyper Cache can be configured to totally ignore some type of pages. For example you may want to not cache the home page to have it always fresh or the feeds to save disk space since they are rarely requested. Remember that WordPress has a feed for each post…
Other bypass are based on matching rules: for example if you have a forum installed which pages live under the URL “/forums” (actually it’s more correct to call the URIs), to never cache such pages add “/forums” to the “starting with URIs to bypass”.
Other bypasses are per user agent, cookie name or exact URI.
URI matching
The URI is the part of a site page address without the domain name. For example this page address is
the URI is “/plugins/hyper-cache” with a starting “/”. So if I want to NOT cache this page I need to specify “/plugins/hyper-cache” as URI to bypass.
If there are more than a URI to exclude just insert one per line. Remember: the URI is the full piece after the domain name. If your blog is installed under a path like:
http://www.satollo.net/blog/plugins/hyper-cache
to exclude that page you must use as URI the value “/blog/plugins/hyper-cache”.
For the “starting with” URI matching the same considerations apply.
The special case of comment authors
When a user leaves a comment in your blog, WordPress uses some cookies to store his data and fill the comment for fields with his name, email and site, The cache must take care of that, to avoid serving a page with those fields filled with another user data.
So, most of the caches simple disable them self when a visitor has those comment cookies. Hyper Cache is able to manage that situation and serve cached pages to comment authors visiting the blog, still pre-filling the comment fields with the visitor’s data.
This is done injecting a little JavaScript on single post. To disable that injection, just disable the serving of cached page to comment authors.
Mobile
If your blog is serving different content and or a different theme to mobile devices, you must consider to have a double cache, one for the desktop content/theme and one for the mobile content/theme.
Mobile detection must be enabled and the user agents set compatibly to the ones used by other plugin/themes. Hyper Cache must be able to decide to serve the desktop or mobile version on its own, otherwise the cache benefit will be lost.
Hyper Cache can be configure to activate a different theme when it detect a mobile device: it’s a simple integrated theme switcher.
A use case. I use Header and Footer to inject different ads formats for mobile devices, even if the theme does not change (it’s responsive). I have Header and Footer detecting the mobile devices in the same fashion than Hyper Cache so pages are cache with different ads code for desktop and mobile visitors.
Unluckily there is no a standard in WordPress so a detection system can be used initially and make all the plugin use it…
F.A.Q.
My cart widget does not work anymore. Do not use the cache or look at a widget configuration which let it to be loaded via AJAX.
My statistic plugin is no more working. Hyper Cache, when possible, serves directly a page without activate WordPress (and hence the installed plugins).
The cache folder is missing. Create it manually wp-content/cache/hyper-cache. For security reason some blogs have a write lock on wp-content folder.
I found no file in the cache folder. Try to set it to 777 permission level: for some reasons and on some providers Hyper Cache cannot write in that directory.
Why have I to use Hyper Cache and not other cache systems? I really cannot answer that question: Hyper Cache is free as for other cache plugin… take the one which gives more performances to your blog!
Where are the cache pages? In to the folder /wp-content/cache/hyper-cache: if you empty that directory the cache starts from zero. Do not delete the directory!
Why there is a JavaScript added at the end of cached pages?
It’s to pre-fill the comment fields even on cached pages. To disable it disable the serving of cached pages to comment authors.
<ul>
<li><a href=”#expiration-time”>Expiration time</a></li>
<li><a href=”#invalidation-methods”>Invalidation methods</a></li>
<li><a href=”#uri-rejection”>URI rejection</a></li>
<li><a href=”#faq”>Frequently Asked Questions</a></li>
</ul>
If you choosed to use Hyper Cache and are satisfied do a check of the advantages or the money saving it brings to you and consider to donate something: that will help me to continue the Hyper Cache developement. <a href=”https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2595746″><img class=”alignnone” title=”Donate” src=”/english/images/paypal.gif” alt=”” width=”92″ height=”26″ /></a> Thank you! <a name=”expiration-time”></a>
<h2>Expiration time</h2>
<strong>What means “expire a cached page after X minutes” and what’s the best value?</strong> Hyper Cache stores an html page in it’s repository. On each reaquest for a page, Hyper Cache checks how much old that page is. If the cached page is older than the X time (in minutes) specified, that page is not served by Hyper Cache, but “re-created” by WordPress (like if a cache system was not here). Hyper Cache then restores the generated page. I use 1440 minutes for my pages (one day), but remeber that a page can be cleared on special events (like comment or modification by the blog owner). You can specify a zero value to avoid any kind of cache expiration. Why it’s better to expire a page (even with a long time)? Because a page is not only the article text, but there are other information, like categories list with posts numbers, latest comment list, latest posts list and so on. With new content, new comments, those lists becomes “old”. <a name=”invalidation-methods”></a>
<h2>Invalidation methods, what’s the best?</h2>
There is not a best method, it all depends on your needs. <strong>Method “all”</strong>. If you need a really coherent and updated blog, you can choose the method “all”: each action on posts (eg. edit), new comment submission and so on leads to a complete cache invalidation. But it’s the more expensive (for your blog, not for the cache). Remember that Hyper Cache (at now) doesn’t intercept the blogroll modification or the theme change. For the latter there are good reasons. So if you plan to make big modification to the blog, manually invalidate the cache. <strong>Method “single page”</strong>. With this method, Hyper Cache invalidate only the cached page of a post modified (with the editor or when a new comment is added to it). The home page is invalidated too just to keep it coherent. But all the cache will be cleared if a post change it’s status from unpublished to published or from published to unpublished. That behaviour keeps all the blog pages updated (no links to article no more active or missing links to article just published). <strong>Method “single page strictly”</strong>. I was asked to invalidate only and only tha cache page of a post when it is modified (even for a status change as explained), because there was no interest on having all the page perfectly updated. <strong>Method “none”</strong>. The cache is never invalidated whatever action will be made (new comments, new posts, editing, and so on). This method can be good if you do very little modification to your blog. Obviously tha cache still respects the expiration time. <a name=”uri-rejection”></a>
<h2>URI rejection and matching criteria</h2>
There are times when a page or a post has to be served always from WordPress. Given the URI (URI is the right word) of that post, it can be added to the url to reject textarea. Let’s go with an example. You have a special page that has not to be cache, let it to be under the URI “/special-page”. So, enter that URI in the textarea <strong>without</strong> quotes. The matching criteria is “if the current URI <strong>starts</strong> with one of the specified, just skip the caching system”. Read the criteria, you can use the partial URI “/special” and the special page will be still rejected. <strong>What about if I need to reject a page with URI “/special” but cache the page with URI “/special-page”?</strong> Simply write the URI to reject surrounded <strong>with</strong> double quotes: “/special”. Hyper Cache will match exactly that page. <a name=”faq”></a>
<h2>FAQ</h2>
<strong>The options panel is saying my installation has problems!</strong> Deactivate and reactivate the plugin: some files need to be rewritten. Then **re-save** the configuration even if you didn’t make changes. <strong>Why have I to use Hyper Cache and not other cache systems?</strong> I really cannot answer that question, but I wrote Hyper Cache to have an easly to install and crontrol cache system for WordPress that make me happy with a 4000 page views/day blog and a 12$/year hosting provider. Enough? <strong>Where are the cache pages?</strong> In to the folder /wp-content/hyper-cache: if you empty that directory the cache starts from zero. <strong>Why have I to donate? And how?</strong> There is chances that if you are using Hyper Cache you are saving a lot of money keeping you site in a cheap provider. This can be a reason. Or just because you find me a cool programmer and want me to keep in developing Hyper Cache and eating two times a day :-). Or… <a href=”https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2595746″><img class=”alignnone” title=”Donate” src=”/english/images/paypal.gif” alt=”” width=”92″ height=”26″ /></a> Thank you!