Since the latest release of AZIndex (0.6) incorporates full support of the widely used WP Super Cache plugin, I thought it would be a good idea to explain how caching works with the AZIndex plugin.  For most of you, especially if your WordPress blog doesn’t use a caching plugin like WP Super Cache, it may be too much information, but for those who want to get the best performance out of their blog’s index pages, read on.

AZIndex’s Internal Cache

Building an alphabetical index from scratch can be a time-consuming process especially if you have an index with thousands of entries.  You certainly don’t want users to have to wait that long every time they access an index page.  So to prevent that from happening, I added some internal caching code to AZIndex.  The only data saved in this cache is the sorted list of posts in the index.  While that may not seem like much, it helps the index load much faster–as much as 20 times faster or more than rebuilding from scratch, for large indexes.

While that is a great improvement over no caching, it can still take a while to load an index page if you have hundreds of items on it.  This is because AZIndex still has to fetch the contents of the index page from the database (e.g. the titles of all the items in the index) and then format the HTML for the page.

WP Super Cache

Ideally, however, if there have been no changes to the index since it was last accessed, you should be able to send out the same HTML next time the index is accessed without having to rebuild the page.  This is where a plugin like WP Super Cache comes in.  When AZIndex serves up an index page, WP Super Cache saves a copy of that page in its own, disk-based cache and the next time the same page is requested by a user, WP Super Cache delivers that same page directly out of its cache almost as fast as the server can deliver a static HTML page. 

Therefore, to get the very fastest response times from your index pages (or any page in your blog for that matter), you should install and configure the WP Super Cache plugin.

Now, making AZIndex work nicely with WP Super Cache wasn’t as easy as you might think!  Sure, it’s easy enough to install WP Super Cache and start caching the index pages, but what happens, say, when you add a new post to the index or modify the title of a post that appears in the index?  WP Super Cache has no way of knowing when creating or editing a post affects the contents of your index page.  It will just keep delivering the old, out-of-date HTML until the cached page expires, which could be as much as an hour or more later.

To make sure that does not happen, AZIndex keeps an eye on the changes you make to your blog posts.  (Don’t worry, there’s nothing sinister about that!  No information ever leaves your WordPress blog’s database.)  Whenever you create a new post, delete an old one, edit a post, change a post’s tags or categories, publish or unpublish a post, AZIndex checks to see if those changes might affect your indexes.  If it finds a change that might, it makes a call to WP Super Cache to tell the plugin to delete the index page(s) from its cache.  Then, next time the index page is requested by a user, AZIndex can rebuild the index page (from its own cache, if possible) updated with the changes you made.

The Bottom Line

So what is the bottom line?  If you don’t have a large index (e.g. more than a couple of hundred posts) or a large number of page hits an hour (more than a thousand or two), then AZIndex’s internal caching is likely to be fast and efficient enough on its own.  If, however, you have an extremely busy blog (lucky you!) or have a massive number of posts in your index, then you might want to consider installing and using WP Super Cache.

Note: If you are using a different caching plugin, please let me know and I will take a look to see if I can add support for that one too.