How To Install/Configure WP Super Cache

The WP Super Cache plugin by Donncha O Caoimh is one of the most useful plugins available for WordPress, and it will help you keep a site functioning well and served to your users in a cost-efficient manner.

There are many WP Super Cache (or WPSC) articles that will provide you a quick explanation on how to use it. In truth, you could get by, just by activating the plugin and do nothing else – it is that good. However, if you are reading this page, I’m assuming that you want to understand more about WPSC in order to use it optimally.

My goal is to provide information that I have gathered over years of using WPSC in a production environment, serving up millions of page views per month and mostly surviving any incoming traffic onslaught that happened, including the Apple live blogs. Overall, things went well, but I’ll share a few bumps on the road, hoping that you can avoid them as your inevitable success will lead you to new levels of traffic.

Why use a caching plugin at all?

WordPress uses dynamic pages, which means that it builds pages as people visit the site by making database queries to get some data and assembles the final page using a pre-determined template before sending it to a visitor’s computer.

This is great because there is no need for the webmaster to manage a myriad of individual static files. However, this is also much more computationally expensive, which makes the process slower and more costly in terms of web hosting fees.

WP Super Cache works by saving dynamic pages built with WordPress to the server’s hard disk as static files. That way, you get the best of both worlds: the pages will be served basically as fast as static pages, but will be dynamic in the sense that if you edit the content, your visitors will see the changes immediately.

Here is an overview of how to properly configure WP Super Cache, and more importantly, I’ll try to explain what is really important (at least to me), and what is optional.

Note: This tutorial was written using WordPress 3.8.3 and WP Super Cache 1.4. Remember that you should always backup your site before making modifications.

Install WP Super Cache

  1. Go to the plugin screen
  2. Click Add New at the top
  3. Type “WP Super Cache”, click on Search Plugins
  4. Make sure that the plug in is from Donncha O Caoimh, and click on Install Now. If WordPress asks if you really want to install the plugin, click “OK”
  5. WordPress will install the plugin and you can click Activate Plugin
  6. You should see “WP Super Cache is disabled. Please go to the plugin admin page to enable caching.” Now the fun can start…
  7. Click on WP Super Cache > Settings

The 1 minute setup that works for 98% users

I think that most people could use the settings below and leave the rest untouched:

That’s it, your site should now be cached. If you want to fine-tune the settings, here are all the details below…

Settings: Easy Tab

wp-super-cache-screen-easy
As its name indicates, this step is very simple. Before the plug in is active, you need to turn it on, so select the “Caching On” radio button and click on the Update status button to save this change. WP Super Cache is not caching yet and we will still have a few things to set up.

Below the Update Status button, you will see a Delete Cache button. This is used to completely empty the cache and make sure that old cached pages will be replaced by new ones. That is typically useful if you change something or if you suspect that the caching is causing a glitch.

Settings: Advanced Tab

Now things are getting a bit more complicated, so I’ll explain every options one by one and tell you which I think most people use.

Now things are getting a bit more complicated, so I’ll explain every options one by one and tell you which I think most people use.

Cache hits to this website for quick access

This basically turns the caching ON, so check it.

Use mod_rewrite to serve cached files

Use PHP to serve cached file

Legacy page caching

Compress pages so they’re served more quickly to visitors

304 Not Modified browser caching

Don’t cache pages for known users

Don’t cache pages with GET parameters. (?x=y at the end of a URL)

The main reason for this is probably that pages with parameters could trigger some odd combinatorial explosion of the number of cached files. This is because each different URL is considered to be unique.

But when you have parameters, you can easily end up with www.mysite.com/?x=10&y10&z=5, www.mysite.com/?z=5&y=10&x10, www.mysite.com/?y=10&z=5&x10. Although they produce the same page, they would be cached as 3 separate files. The more parameters and the more combinations and the cache could grow to an unmanageable size.

That said, WordPress does a good job at not using crazy parameters, and if you use pretty Permalinks, this should not be an issue. Keep in mind that external sites could link to your site and add some really bizarre parameters. I’ve seen hundreds of sites do that, so this remains a possibility

Most people can leave it unchecked, and revisit this if the url parameters get out of hand

Make known users anonymous, so they’re served supercached static files

This is the exact opposite of the previous option “Don’t cache pages for known users”. Typically, this would be very useful for a site in which there are a lot of people logged in, but those users don’t really edit the content much, if at all. Because they don’t change the content, it’s OK to serve them cached pages.

There are many reasons to have people logged-in, even though they are not authors. For instance, they could be paid subscribers, or have access to a premium area. Most people can leave this unchecked

Cache Rebuild. Serve a super cache file to anonymous users while a new file is being generated

The idea here is to serve a cache file, even if the cache period has already expired, then rebuild a new cached file right after, in case someone else comes to visit this content again. The advantage of doing so is that the visitor gets served a page right away. Chances are that not much has changed since, so it’s not critical to make that person wait for a new page rebuild. Since the page is getting some visits, a new one is built and the next person will get fresh content.

Proudly tell the world that your server is Stephen Fry proof (places a message in your blog’s footer)

Places a little promotional message to the footer of your blog. Most people will want to leave it unchecked, but if you want to promote the plugin and its author, you can. I personally have opted for making a cash donation to the author. As a former software engineer, I think that whatever I gave was a tiny fraction of the benefits this code has brought to my site

Enable Dynamic Caching. Requires PHP or legacy caching

This option is used by people who modify their template code to make certain parts of the template dynamic, even when cached. It works by executing the cached page with PHP and inserting some page elements in the cached file before it is sent to the visiting browser.

Since this is a rather advanced technique, I’m assuming that people who use it wouldn’t need this tutorial. If there a demand for it, I could look at providing more information, but the FAQ of the plugin does provides enough to those who can actually use it.

Most people will leave this unchecked.

Mobile device support

This is an option that makes WP SC compatible with some plugins that turn your site into a mobile friendly one (WPTouch, WordPress Mobile Edition and WordPress Mobile Pack). If you use one of these plugins, check this option.
Mobile pages are cached under as index-mobile.html instead of index.html, so they are easy to see via FTP.

Remove UTF8/blog charset support from .htaccess file

It may happen that the character set used in your system does not work well with the caching system. If you see odd characters appear in the cached files, this may fix it. I’ve never seen this, and I wonder when it happens. If you have experienced it, please share your experience. More information on UTF-8 and htaccess files.

Clear all cache files when a post or page is published or updated

The label is pretty explicit. In general, I don’t recommend checking this because, out of the box, it’s a bit wasteful to clear everything because you have published one post.

That said, this could come in handy if you absolutely want that “latest news” module in your sidebar to update right away. This is particularly true if you have a long cache expiration time.

Extra homepage checks

This feature was added by the plugin author because he noticed that everyone in a while the home page caching could go wrong and maybe return a blank page.

This works in conjunction with the “check front page every 5 minutes” option in the DEBUG tab. We’ll get to that later.
I have personally never seen the problem, and it has never been reported to me by a user, so I think that most people can leave it unchecked.

If you are really worried that someone may infrequently see something weird on your homepage, you can check it, but it will use a bit of resources to perform those checks.

Only Refresh current page when comments made

This means that when a comment is made, the article page cache file is deleted. This is pretty much what you expect, but the idea is that things like related tags, categories and other archives aren’t deleted because the article content (title, text…) has not changed at all. If you use the WordPress commenting system, it’s worth experimenting with this.

List the newest cached pages on this page

this will display the latest cached files created. In general, I just look at those over FTP, and if you have a big site, this could slow things down. For smaller sites, it shouldn’t matter much. I’ve never found this to be particularly useful to me.

Coarse file locking

This option was introduced a very long time ago to avoid file name collisions, but I believe that the current plug-in uses temporary names anyway, so there is little chance of that happening. Leave it alone.

Late init

Normally, WP Super Cache gets initialized very early in the page view process, so early in fact that most of the WordPress API has not been initialized yet.

If for some reason, you need to alter WPSC’s functions using information coming from the WordPress Database, this option will delay the initialization of the plugin until the WordPress “init” hook is called. At that point, you can query information from WordPress and do what you needed to.

This is more for plug-in and theme developers, but if you want more information, check this post from the plugin author.

Do not cache page secret key

Introduced in version 1.0, this option ensures that you can see any page without going through the cache. This allows you to verify something in case you think that stale content is being seen on the public site. This is a debugging tool.

Settings: Advanced, Expiry Time & Garbage Collection Tab

Before going over the option, a quick overview of the terminology is in order. First, the Expiry Time (in seconds) is how long the cached data will be valid. If you set an expiry time of 300 seconds, that’s 5mn, which means that 5mn after the cached data was created, WP SC should re-create it if a visitor visits the page.

Most cache systems will verify the data expiry time when there is a query. In this case, it’s not convenient because serving cached pages with Apache’s mob_rewrite doesn’t execute any code. Instead, WP Super Cache checks the status of the cache periodically and when you edit/create content. Checking for data expiration is called Garbage Collection, because the data is no longer valid and is therefore called “Garbage”. You have a few options here:

Cache Timeout

It defines how long the data is valid for. Depending on how frequently you update your blog, it could be minutes or days, but always compute this in seconds. It would have been nice if this timeout could be different for every type of content (articles, home page, attachment pages, RSS feeds…) but unfortunately, every single cached page will use this timeout value.

The timer

This is one of the ways to define how often Garbage collection is done. You can see it as a countdown and at the end of it, WPSC will go and delete/mark pages that are no longer valid. They will be rebuilt at the next visit.

The scheduler

Is another way to define how often Garbage Collection happens. If you want to set it to once per day, or have it run at a specific time of the day, then it’s a more sensible solution.

The longer you cache the content, and the more beneficial caching is going to be because the less computation and database queries will happen. That said, there are a number of caveats that you should be aware of.

If your site if big enough, disk-based caching will reach a limit when the disk operations (I/O) will take too long, or even time out. In my experience, this can happen with 1000 cached files, and depending on your own I/O things can be worse (NFS share) or better (SSD), but eventually, your server will bump into a maximum number of cached files that it can handle before things turn sour.

This happens because when garbage collection occurs, WPSC needs to look at a potentially large number of files to see if they have expired. Each file takes a little bit of time to access and it adds up quickly when there are thousands of files in the cache directory.

For example, if you have too much cached files, garbage collection operations may time out, and when they happen as you save/create/publish a post, it may seems like WordPress is crashing. For the sake of this article, let’s say that the limit is 1000. I see two main types of WPSC users:

  1. Your site has less than 1000 pages and is not updated often
    1. Most personal and small business sites will fall in this category. This is great because it means that you can cache virtually everything at all times. You can either set a long cache for 604800 seconds (one week), or you can disable the garbage collector and let WPSC delete cached files upon content editing. If you don’t see any problems, then you now benefit from the best of static page serving and dynamic content management system – life is good!
  2. Your site has more than 1000 pages, is growing fast, and is updated several times a day
    1. This would concern professional content writers like bloggers who are either very prolific or make a living from publishing content. If that’s the case, your content will grow fast enough to get you two types of traffic:
      1. Home page or specific viral pages visits
        1. Traffic to the homepage is perfect for caching since it is repeated visits on the same content. Long-tail traffic means that every once in a while, a page gets visited, often via Search engines, or a link from another site. The page may even get one visit every day or once per week.
      1. Long-tail traffic to thousands of older articles
        1. Your are very successful at making interesting content, but this is a difficult case for caching because most of the time, the caching system will build and save a page (thus using disk IO and other resources) and it will ultimately expire before the next visit.
        2. In that case, the cache isn’t helping much. There is not much that you can do, but as long-tail traffic raises you may have to look into other WPSC storage options that can handle more cached objects, like memory-based Memcached or APC. Long tail traffic makes things more difficult to cache, and I suspect that most people don’t get that problem. Those who do are probably professionals that can afford to pay a consultant to help them out. If you have basic Linux Admin skills, Memcached is pretty easy to fire up, but if you don’t, get help.
        3. The overall idea is that the larger your site and traffic, and the more cached content will be generated. Yet, you need to make sure to stay within the performance limits of your file system and this is why the plugin author recommends lowering the cache expiration for such sites. The default 3600 (1hr) value is pretty safe for larger sites that have tens of thousands of posts and millions of page views per month, but smaller sites can benefit greatly from a much longer cache time.

Accepted Filenames & Rejected URIs

This will let you pick pages that do not need to be cached. The check boxes will let you select specific content types that will not be cached. In general, I would advise you to leave everything unchecked, and if a specific type needs NOT be cached, you can tweak this later.

The URL is the web address of a page. The first edit box with lets you define the URLs that will not be cached. One URL template per line can be added and since you can some regular expressions to reject caching on specific URL names. Most people don’t need to worry about this.

A second edit box lets you add “exceptions” to the rule defined above, which can be handy if there are name conflicts that are beyond your control. Again, you will probably not need this.

Rejected User Agents

Web browsers or crawler robots (bots) identify themselves with a user-agent name. Tell WP SC that it doesn’t need to cache content when a specific browser visits the site. I’m not sure why/how people use this. In general, I think that bots should get the same content as users, but if for some reason you don’t want them to see the cached content, this gives you options.

Most people won’t bother changing this, and even though it may waste a bit of server resources when bots visit, it never became bad enough for me to worry about it. If you want to save extra server resources, you could remove all these user agents from there. I have seen instances where there are 200,000 bot visits per day, and this is really when you need to be mindful of every single cycle used to generate the pages.

Lock Down

Meant for cases where a huge flood of traffic comes to the website. I’m not 100% sure why it was added, but I suspect that it may have to do with the fact that a very high succession of page requests may create a cache stampede situation where several requests are being processed before the content could be generated and cached.

Let’s say if your server takes 1 second to generate a page, and you are getting 30 page requests per second, then it is possible that 30 concurrent requests will go through before the first one has been served. This could lead to your server being overwhelmed. Lockdown tries to keep things cached for as long as possible and it will not invalidate the cache or refresh content while lockdown is enabled.

I think that most people can ignore it. Chances are that by the time you realize that you are bombarded with traffic, it’s most likely too late.

Fix Configuration

Will reset the configuration to its default setting. This is handy in case you think that you screwed something up, but aren’t sure what is wrong exactly and want a fresh start.

CDN Tab – How to Set Up WP Super Cache with a CDN

CDNs, or Content Delivery Networks are one of the easiest ways to offload your web server It is technically also a form of “caching”- from your server to another.

Setting up a CDN is outside of the scope of this article (check this one instead), but if you want to use an origin-pull CDN, WP Super Cache will let you do it. If checked, Enable CDN will use the CDN feature. Here are the configuration parameters:

Off-site URL

This is the URL of your origin-pull CDN. Most people set up something like cdn.mysite.com. Origin pull works by having cdn.mysite.com copy content once from www.mysite.com and serve it multiple times. Instead of having your server send this file to every visitor, it only sends it once to the CDN service. This saves you CPU cycles and bandwidth.

The idea is that the CDN service will have cheaper bandwidth and doesn’t charge for page serving CPU cycles. CDNs also have multiple server locations closer to the visitors, which makes the content arrive faster, thus speeding up your site.
I highly recommend learning how to use a CDN if you have enough traffic to justify it (are you paying for CPU or bandwidth overage?).

Include Directories

By default, every time WPSC sees www.mysite.com/wp-content/ or www.mysite.com/wp-includes/ il will rename the URL with “cdn” instead of “www” in the HTML code so that visitors pull the content from the CDN. In this edit box, you can specify additional locations that should be hosted by the CDN. Most people can ignore this and leave it as is.

Exclude if substring

Sometime, you don’t want certain files to be served by the CDN. PHP files are a good example since they could have code that is designed to be executed every time. When that’s the case you don’t want to cache this file on the CDN. By default, you don’t need to do anything with this.

Additional CNAMES

Skip https URLs to avoid mixed content errors

This is a checkbox that makes sure that content hosted on an HTTPS (secure HTTP) cannot be delivered over a CDN which is probably HTTP. It’s possible to have  HTTPS CDNs, but they cost more, and most of the time, you don’t need extra security/encryption for WordPress files in /wp-content/ or /wp-includes/. This is however useful to companies that only host content on HTTPS servers. In general, you don’t need to worry about this. Leave it alone unless you know what you are doing.

Contents Tab

This is a simple screen which shows you the state of your cached data. For example, you can use Regenerate Cache Stats to see how many pages are being cached right now. As we discussed earlier, this is useful information if glitches start to appear. If you feel like there are too many cached files you can reduce the expiry time.

Delete Expired will trigger a garbage collection process basically and get rid of the expired files right away. Delete cache will clear all the cached files. Note that if you have enough traffic, new files can be created before this process ends, so don’t be surprised the cache directory is not completely empty.

List all cached files will show you which files are currently in the cache. This is interesting, but on a large site, it will most likely time out because it takes too long to get detailed information about hundreds of cached pages. Alternatively, you can browse the cache directory over FTP if you are really curious.

Preload Tab

In general, you don’t need this feature, but if you are curious, read on.

Preloading is a feature that can be used to “warm up” a cache. This means that you can create cached pages in a controlled manner before traffic hits the site randomly.

I have not seen any particular use for this feature because I’d rather cache pages that actually get visits instead of building a cache for everything. For small sites, building cached pages randomly isn’t so bad, and for big sites, the file system becomes an issue at some point. Since this is a long process, it has more chances to time out and run into various problems typical to long processes over PHP.

I could imagine that if you have a site that you will not edit/update for weeks or months, it could effectively turn the site into a static site, and lower the cost of hosting it. That said, how is it different from simply disabling Garbage Collection and letting the cache fill up naturally? I’m not sure – please drop a comment if you are using this.

In any case, if you do so, then I would recommend checking the Preload mode, which disables the Garbage Collection (GC). If you don’t do that, GC would probably delete a bunch of files that you preloaded earlier, which defies the purpose.

Plugins Tab

The WP Super Cache plugin has plugins of its own, which are located in \wp-content\plugins\wp-super-cache\plugins, and this page is here to manage them. As of version 1.4, WP Super Cache shipped with the following extensions / plugins:

You may recognize some well-known WordPress plugin and these extensions are there to help WPSC be compatible with them. This is pretty easy stuff: you basically “enable” one of these extensions if you want WPSC to function properly with one of those plugins.

Debug Tab

On this page, you can enable some logging in order to track down some bugs. The log is located in /wp-content/cache/ as a .txt file. It is possible to keep the logging activity low by tracking only a single IP address and that’s what the IP Address edit box is there for.

Enabling the Cache Status Message also lets you keep an eye on what WPSC is doing without logging.  By looking at the page generation time, you can spot when your server or database becomes abnormally slow. How long it takes to generate the page often depends mainly on how fast your database server is and how many queries you are doing. It’s not uncommon to see pages generated in 0.35 to 0.6 seconds, but there is no rule and each webmaster has his or her own tolerance.

Note that the page generation time is not how fast the page will load in the browser. It represents how long it took for WordPress to put the HTML together before saving the page in the cache.

There’s a home page check option that can be activated. It uses a specific keyword that WPSC will search on the page to make sure that it is working properly. Typically this is great to detect blank pages that sometime happen if something goes wrong.

Common questions

How do I know that WP Super Cache is working?

If you have enabled the cache status messages in the debug Tab, then right click on your page in the browser and select “view source”. You should see the super cache HTML comment at the bottom of the page. It shows you exactly when the page was created (in server time).

If you did not check that option or if you minify the HTML code, you can also log in via FTP and check the \wp-content\cache\ folder to see if there’s any caching activity going on.

A cached page seems stuck and doesn’t seem to refresh

First, make sure that the page is not cached by the browser. You can close and re-open the browser, or force the browser to clear its cache in the browser settings.  If this still doesn’t work, you can try purging the cache by clicking “Delete Cache” in the Easy or Contents tabs.

If all else fails, you can use FTP and check the \wp-content\cache\ folder.

How To Uninstall/Delete WP Super Cache?

Like other plugins, you can simply deactivate and delete it. Upon deletion, WP SC will also remove two files in the \wp-content\ directory:  advanced-cache.php and wp-cache-config.php. WPSC does not save its options in the WordPress database because its code is executed before the WordPress database PHP object is loaded. It has code that will trigger the buffering of any PHP output so that it can be saved later in the cache file.

Note that many different caching plug-in use a similarly named “advanced-cache.php” file, so if you see one, you may want to open it in a text editor to see which caching plugin it came from.

Metrics for success

The end game of all this is to make the site better and faster. To measure and quantify the improvements, I would look at a few key metrics:

  1. Server response time (in milliseconds)
    1. Caching should improve dramatically from hundreds of milliseconds to tens of milliseconds. More about server response time.
  2. Server CPU and Database usage (in dollars)
    1. Using WP SC or another caching system should reduce the server load and ultimately save you money
    2. If you pay a flat fee, using less resources increases your odds of staying in good terms with your hosting company
  3. Page served per second
    1. Your server should also be able to serve more pages per second in case your content becomes popular. WP SC should basically multiple the capacity of your server by an order of magnitude, if not more

Once the page is cached on disk, what you are really looking at is how fast your web server (Apache/NGINX or other) is at serving static files or .php files.

Conclusion

I hope that this WP Super Cache overview and real-world usage information was useful to you. I could have this info back in the days, lol. I would like to thank Donncha O Caoimh for taking the time to go over this article before it was published. If you want to glean additional information about how the plugin development went, check Donncha’s personal blog WPSC posts.

I highly recommend any WordPress user to install some form of caching, unless the web hosting company already has a solution in place (many specialized WordPress hosting companies do). There is really little to no downside as it will help the website performance and will save you money – both of which are highly desirable. In addition, this plugin is free and a proven technology.

If you have additional questions, please add a comment below, and I’ll try to address it as soon as I can. Also, if you spot an error, or would like to point out something that can help other users, feel free to do so. If a tip becomes popular, I’ll see if I can add it to the article.

Happy caching!

You May Also Like

Related Articles on Ubergizmo

Popular Right Now

Exit mobile version
Exit mobile version