WordPress.org

So Why Does WordPress® Need To Be Cached?

To understand how Quick Cache works, first you have to understand what a cached file is, and why it is absolutely necessary for your site and every visitor that comes to it. WordPress® ( by its very definition ) is a database-driven publishing platform. That means you have all these great tools on the back-end of your site to work with, but it also means that every time a Post/Page/Category is accessed on your site, dozens of connections to the database have to be made, and literally thousands of PHP routines run in harmony behind-the-scenes to make everything jive. The problem is, for every request that a browser sends to your site, all of these routines and connections have to be made ( yes, every single time ). Geesh, what a waste of processing power, memory, and other system resources. After all, most of the content on your site remains the same for at least a few minutes at a time. If you've been using WordPress® for very long, you've probably noticed that ( on average ) your site does not load up as fast as other sites on the web. Now you know why!

The Definition Of A Cached File ( From The Wikipedia )

In computer science, a cache (pronounced /kash/) is a collection of data duplicating original values stored elsewhere or computed earlier, where the original data is expensive to fetch (owing to longer access time) or to compute, compared to the cost of reading the cache. In other words, a cache is a temporary storage area where frequently accessed data can be stored for rapid access. Once the data is stored in the cache, it can be used in the future by accessing the cached copy rather than re-fetching or recomputing the original data.

Prepare To Be Amazed / It's Time To Speed Things Up

Quick Cache is extremely reliable, because it runs completely in PHP code, and does not hand important decisions off to the mod_rewrite engine or browser cache. Quick Cache actually sends a no-cache header ( yes, a no-cache header ) that allows it to remain in control at all times. It may seem weird that a caching plugin would send a no-cache header :-). Please understand that the no-cache headers are the key to the whole concept behind this plugin, and they will NOT affect performance negatively. On the contrary, this is how the system can accurately serve cache files for public users vs. users who are logged in, commenters, etc. That is why this plugin works so reliably.

If you care about the speed of your site, Quick Cache is one of those plugins that you absolutely MUST have installed. Quick Cache takes a real-time snapshot ( building a cache ) of every Page, Post, Category, Link, etc. These snapshots are then stored ( cached ) intuitively, so they can be referenced later, in order to save all of that processing time that has been dragging your site down and costing you money. The Quick Cache plugin uses configuration options, that you select from the options panel. See: Config Options under Quick Cache. Once a file has been cached, Quick Cache uses advanced techniques that allow it to recognize when it should and should not serve a cached version of the file. The decision engine that drives these techniques is under your complete control through options on the back-end. By default, Quick Cache does not serve cached pages to users who are logged in, or to users who have left comments recently. Quick Cache also excludes administrational pages, login pages, POST/PUT/GET requests, CLI processes, and any additional User-Agents or special pattern matches that you want to add.

Running Quick Cache On A WordPress® Multisite Installation

WordPress® Multisite/Networking is a special version of WordPress®. If Quick Cache is installed under a Multisite/Networking installation, it will be enabled for ALL blogs the same way. The centralized config options for Quick Cache, can only be modified by a Super Administrator operating on the Main Site. Quick Cache has internal processing routines that prevent configuration changes, including menu displays; for anyone other than a Super Administrator operating on the Main Site.

How To Enable GZIP Compression For Even Greater Speeds

You don't have to use an .htaccess file to enjoy the performance enhancements provided by this plugin; caching is handled by WordPress®/PHP alone. That being said, if you want to take advantage of GZIP compression ( and we do recommend this ), then you WILL need an .htaccess file to accomplish that part. This plugin fully supports GZIP compression on its output. However, it does not handle GZIP compression directly. We purposely left GZIP compression out of this plugin, because GZIP compression is something that should really be enabled at the Apache level or inside your php.ini file. GZIP compression can be used for things like JavaScript and CSS files as well, so why bother turning it on for only WordPress® generated pages when you can enable GZIP at the server level and cover all the bases.

If you want to enable GZIP, create an .htaccess file in your WordPress® installation directory and put the following few lines in it. Alternatively, if you already have an .htaccess file, just add these lines to it, and that is all there is to it. GZIP is now enabled!

<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
 AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
 AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
 AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
 AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
 AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>

If your installation of Apache does not have mod_deflate installed. You can also enable GZIP compression using PHP configuration alone. In your php.ini file, you can simply add the following line anywhere: zlib.output_compression = on