Unlike most plugins, Super Cache doesn't start working as soon as you activate it. You have to configure it first. You'll see a red-outlined warning message on your plugin list until you set up caching or deactivate the plugin, as shown in Figure 11-2.
Go to Settings ^ Super Cache to configure the plugin (Figure 11-3). The first thing you have to decide is whether to run the plugin in Half On or full On mode. In Half On mode, Super Cache emulates an older plugin, WP-Cache, which stores the cached files as PHP. Your server won't have to process any MySQL queries, but it still has to generate those PHP pages. In On mode, Super Cache saves those files as HTML instead, so there's no PHP processing required to serve them up to your visitors. If you're serving thousands of pages per minute, that small difference goes a long way.
For most sites, Half On mode will be fine for daily use. You can always toggle the status later if you need to.
Next, you should probably turn on the option labeled Don't cache pages for logged in users. This will ensure that as you're making changes to the site, you can view them immediately without waiting for the cache to refresh.
The next option will rebuild the cache when you add a post or page. This will ensure that your visitors will see the new content immediately, but it will also slow things down for you and your other users. Every time you publish something, the entire cache will have to be regenerated, and that can take a significant amount of processing power if you have a large site. My recommendation is to try writing a few posts with this option on and see how it goes. If your site becomes unusably slow, turn it off! Your visitors will just have to wait for the old cached pages to expire (within the time limit you'll set in just a moment) before they see your new posts.
Normally, a post's cached page will be rebuilt every time someone adds a comment. However, if you get so many comments that this would be counterproductive, you can turn on the cache rebuild option. New files will still be generated, but if a new comment comes in while the page is being generated, the viewer will see the older copy.
Coarse file locking is no longer recommended but is still available for backward compatibility. This option locks cache files while they are being rebuilt, but Super Cache now uses temporary files during the rebuild process, and coarse file locking is obsolete.
I do not recommend listing the most recently cached pages unless your site traffic is nominal and you're curious as to how the plugin is operating.
I'll talk about the mobile support option in the next section. For now, choose among the options I've gone over and press Update status.
When the page refreshes, you should see a section listing the contents of the cache (Figure 11-4).
Figure 11-4. Super Cache contents
In this section, you can manually delete the cache. This is helpful when you've changed some of the settings in the first section and you'd like the changes to take effect before the cached pages expire.
The compression settings determine whether your cached files are stored in compressed (gzipped) format. Modern browsers are capable of unzipping pages after downloading them, so your server can send smaller files. Compression is optional in On mode, but is on by default in Half On mode. If you're running in On mode, you can enable compression. You'll then be shown a list of the rewrite rules that should be added to .htaccess, and if your . htaccess file is writeable, you can press a button to make the changes. Otherwise, you'll need to copy them by hand.
Super Cache compression can cause problems if your server is already compressing output using mod_deflate (on Apache) or PHP compression (zlib). In this case, the doubly-compressed files might appear as garbage characters to some users. You can turn off compression in Super Cache or adjust your server's settings. The plugin FAQ contains information on how to do this; if those instructions don't work, ask your hosting provider about your server's compression settings.
Under Expiry Time & Garbage Collection, you can choose how long your cached pages will last before they should be rebuilt. The default setting is 3600 seconds (one hour). You can lower this, but keep in mind that garbage collection requires server resources, just as rebuilding pages does. You should experiment with different settings to strike a balance between these two processes that doesn't overly tax your server.
Md -»■'- WWW tfUl can CM («Tied. run Ii Ihr, lUftcft One of IM rt.ecWd MibStTlng ipfühtd itat
Figure 11-5. Accepted filenames and rejected UJRIs in WP Super Cache
In the Accepted Filenames and Rejected URIs section of the Super Cache settings (Figure 11-5), you can specify certain pages that should not be cached. The page type options should look familiar; they're identical to the conditional tags you saw in Chapter 7. Of these, I would recommend checking Feeds. You can leave the rest of these settings on their default values in most cases. You'll change them when you enable mobile support in the next section.
At the bottom of the Super Cache settings screen, you'll have the option to directly cache a single file (Figure 11-6). If you write a post or a page that you know will bring in untold numbers of readers, you can head off the impending performance crisis by caching the page not in the usual hidden cache location, but right in your blog directory. How does this work? The WordPress rewrite rules—all of them, including Super Cache's—are set up to rewrite URLs only if the requested file or directory does not exist on the server. Therefore, if you create a cached page in the location that matches the permalink, the cached file will trump all rewrite rules. Since the server doesn't have to look through all those rewrites, it will be a little faster at serving up that particular file. And when you're looking at thousands of requests coming in, "a little faster" multiplies quickly into some significant performance.
Figure 11-6. Directly caching a popular file in WP Super Cache
Was this article helpful?