WordPress 本身动态生成页面的特性导致其性能一直为人诟病，表现为速度慢、服务器负载重等，于是大家想出一系列的办法来修正这个问题，我见过的思路有以下几种：
1. 缓存数据库查询，减轻 SQL 查询负担
2. 缓存页面，减轻 PHP 解释负担
3. 生成真正的静态化页面，把 SQL 查询减少至 0，PHP 解释减少至 0 或接近 0
上面分得不一定严谨准确，我只是粗略划分一下（另外，本篇文章可能含有错误，发现并指正有奖）。
第一种思路的代表是 WP Cache，这是我用过最早的缓存插件，效果非常一般。我觉得这个思路本身就是矛盾的，缓存更新比较快的数据，打个比方说评论吧，缓存了可能会导致查询最 新评论结果不准确，不缓存吧查询频率还比较高。貌似 WP Cache 有后续版本？不好意思没关注过。
第二种思路的代表是 WP Super Cache，不过我觉得这么说可能不太准确，它应该也结合了第一种思路，貌似大家对 WP Super Cache 评价还比较高，但是我的看法是：不过如此。
第三种思路的代表是 cos-html-cache，在看过 Hyper Cache 的源代码之后，我把它也归进这第三种思路中，但这二者又有差异。cos-html-cache 的机制是生成真正静态的 HTML 文件，所以这个插件也要求把 WordPress 的永久链接格式改为 .html 结尾，它的优势非常明显：缓存机制彻底绕过了 WordPress，完全没有 PHP 和 SQL 消耗。在发生第一次访问请求时，生成页面缓存，缓存生成之后，所有访问请求到的页面都是一个真正的 HTML 网页，显然优化程度已经达到了极限。
与之相比，Hyper Cache 并没有完全脱离 WordPress，虽然它也会生成静态的页面（不是 HTML 网页，而是序列化后的二进制数据），但为了保证插件适用范围更广，Hyper Cache 仍然依赖于 WordPress 的插件机制，当有访问请求时，Hyper Cache 首先会检查是否生成了缓存，如果缓存存在，把二进制缓存数据反序列化并返回，否则生成缓存。（包括生成方式在内，Hyper Cache 更新缓存的方式跟 cos-html-cache 也无二致，都会在有新评论、有新日志产生的时候更新相应的部分缓存。）
由此可见，有人说“Hyper Cache 轻松打败 WP Super Cache”是有道理的，但与 cos-html-cache 的优化效果相比，还是存在一定的差距。不过 Hyper Cache 仍然称得上是一款优秀的 WordPress 缓存插件，良好的缓存性能、对永久链接格式没有苛刻的要求、支持 gzip 压缩另外还有易用的配置界面（实话说我只看过这个页面的源代码），都足以让 Hyper Cache 代替 WP Super Cache 成为非 geek WordPress 用户的选择。