You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Edit and finalize draft for publishing (remove draft label, add draft-finalized label)
Assign Issue to yourself and create Markdown file (remove draft-finalized label, add pending)
Project Lead: Review and Publish KB Article (remove pending label, add published label)
Additional TODOs
Additional TODO list items go here.
title: Is Comet Cache the fastest cache plugin available for WordPress? How does it compare to others?categories: questionstags: pre-sale-faqsauthor: jaswsincgithub-issue: https://github.com/websharks/comet-cache-kb/issues/89
No, Comet Cache is not necessarily the fastest cache plugin available. In fact, if you search the web you will see Comet Cache reviewed in several articles in various ways. Obviously, some of those articles/reviews are more generous to us than others. In any case, you can't dispute the facts. Comet Cache ranks well for speed, but not always the absolute fastest available. Why? Here are some things to keep in mind :-)
One should consider whether speed is the only concern...
It's easy (when comparing caching plugins) to put a focus on speed and speed alone. However, plugin compatibility and overall peace-of-mind with a reliable plugin that also works to speed things up is more valuable in our opinion. While Comet Cache ranks well for speed, we really don't put our primary focus on speed. Caching is the speed, no matter how you cut it that will dramatically speed up your site. What we focus on is being compatible with a wide variety of plugins. So (in code) we take a "do no harm" sort of approach in that regard.
How do crazy-fast cache plugins pull it off?
In many WP cache plugin reviews, one of the main differences between plugins (in terms of speed) is in how they actually serve the cached copy of pages. When you look at some of the fastest cache plugins, they generally rely on two things in order to accomplish a faster speed score.
Browser caching; i.e., a client-side cache. This is generally not recommended on any site that has users logging in/out all the time. Allowing a browser to cache the HTML content of your site can result in a visitor seeing a page that was originally cached by their browser whenever they were not logged into the site; as opposed to what they should be seeing when they are in fact logged in. Note that caching "HTML" content generated via PHP (i.e., by WordPress) is different from caching static resources. Static resources should always be cached and/or served from a CDN if possible.
The cache hits not touching PHP at all; i.e., several .htaccess tweaks. This increases speed by a lot. However, it also means there is very little (or no) validation of the cache entries and/or inspection of the current user. This reduces the number of configurable options that you have, and it is certainly not recommended for a site that is dynamic; e.g., a membership site or any site that runs things like bbPress or BuddyPress. By serving the cache in a very early phase of PHP (before WordPress loads) we achieve the best of both worlds. Speed and reliability with deep validation of the cache before a decision is made to serve the cached copy; or not.
The text was updated successfully, but these errors were encountered:
Awesome! Love this. There's such a subtle but important distinction between caching that relies on the web server (e.g., via a .htaccess file) and caching that has the intelligence of PHP behind it. The former is faster, but the latter not only improves compatibility but also allows the caching engine to ensure that visitors see the most recent version of a page and allows the site owner to control all sorts of things that aren't possible when giving up that control to a web server (via mod_rewrite in an .htaccess file); for example, efficient cache expiration time.
One thing I'd love to see in this article is a comparison of caching-related features possible with both methods, so that a site owner can get a better idea why ZenCache prefers the PHP-method.
raamdev
changed the title
Is ZenCache the fastest cache plugin available for WordPress? How does it compare to others?
Is Comet Cache the fastest cache plugin available for WordPress? How does it compare to others?
Jun 1, 2016
KB Article Creation Checklist
draft
and eitherquestions
ortutorials
draft
label, adddraft-finalized
label)draft-finalized
label, addpending
)pending
label, addpublished
label)Additional TODOs
Additional TODO list items go here.
No, Comet Cache is not necessarily the fastest cache plugin available. In fact, if you search the web you will see Comet Cache reviewed in several articles in various ways. Obviously, some of those articles/reviews are more generous to us than others. In any case, you can't dispute the facts. Comet Cache ranks well for speed, but not always the absolute fastest available. Why? Here are some things to keep in mind :-)
One should consider whether speed is the only concern...
It's easy (when comparing caching plugins) to put a focus on speed and speed alone. However, plugin compatibility and overall peace-of-mind with a reliable plugin that also works to speed things up is more valuable in our opinion. While Comet Cache ranks well for speed, we really don't put our primary focus on speed. Caching is the speed, no matter how you cut it that will dramatically speed up your site. What we focus on is being compatible with a wide variety of plugins. So (in code) we take a "do no harm" sort of approach in that regard.
How do crazy-fast cache plugins pull it off?
In many WP cache plugin reviews, one of the main differences between plugins (in terms of speed) is in how they actually serve the cached copy of pages. When you look at some of the fastest cache plugins, they generally rely on two things in order to accomplish a faster speed score.
.htaccess
tweaks. This increases speed by a lot. However, it also means there is very little (or no) validation of the cache entries and/or inspection of the current user. This reduces the number of configurable options that you have, and it is certainly not recommended for a site that is dynamic; e.g., a membership site or any site that runs things like bbPress or BuddyPress. By serving the cache in a very early phase of PHP (before WordPress loads) we achieve the best of both worlds. Speed and reliability with deep validation of the cache before a decision is made to serve the cached copy; or not.The text was updated successfully, but these errors were encountered: