WpW: LiteSpeed Caching 101

Welcome to another installment of WordPress Wednesday!
Today’s Topic: Understanding LiteSpeed Cache

Previously in our Cache 101 series, we discussed the basics of caching. Be sure to take a look at that, if you missed it, because today we are going to go more in-depth, and discuss LiteSpeed Cache in particular. We’ll talk about how it works, how it is different than other WP caching solutions available, and what that really means for your WordPress site.

LiteSpeed Cache

As we mentioned, LSCache is a server-side page cache. This essentially means we are storing static snapshots of the pages on your WordPress site. We can do this because the dynamically-generated pages are effectively the same each time they are built. Why generate the same page multiple times, when you can do it once and save the results at the server level? Rather than making your visitors wait for WordPress and PHP to assemble the pages for each request, we can serve them the snapshots much faster.

Filling up and using the cache

LiteSpeed Web Server is required for the use of the LSCache for WordPress plugin. This is because the basic LSCache functions are actually carried out by the server. The plugin is provided as an easy way for a site admin to communicate with the cache engine, but it doesn’t actually execute any of the caching tasks, and the cache files themselves are not stored within the WordPress file structure.

LiteSpeed’s cache can be populated in two ways: behind the scenes through the use of a crawler, or through visits to the site. We’ve written a comprehensive overview of our crawler functionality before, so for now let’s just focus on a basic example where a couple of users drop by to check out your site.

Visitor #1:

1. lands on your site and requests a dynamic page to view.
2. The request goes to the server, which checks to see if the page is in the cache.
3. It is not, so the request goes to WordPress.
4. The WordPress backend processes all of the PHP code and generates an HTML page
5. The HTML page is served to the visitor.
6. The page is also stored in the cache.

Visitor #2:

1. lands on your site and requests the same dynamic page to view.
2. The request goes to the server, which checks to see if the page is in the cache.
3. This time the server finds the page in cache
4. The cached page is quickly served to the visitor.

You can see, when the page was cached after Visitor #1 requested it, that things really improved for Visitor #2 (and presumably, every subsequent visitor as well). That is the benefit of caching, in a nutshell.

As long as a page remains in cache, all visitors will have the same experience as Visitor #2. Once some event occurs that purges the page from the cache, the process begins again. The next visitor after a purge will have the same experience as Visitor #1 did: waiting for the backend to process the request and store an updated version in the cache.

Emptying the cache

Pages cannot remain in the cache indefinitely, so while visitors keep triggering more and more additions to the cache, LSCache relies on a set of rules to tell it when to remove pages. A page removal (or, purge) occurs when certain activities trigger it, or when the page has been in the cache long enough to expire.

Purge through expiration

The most common way for a page to be removed from the cache is for its TTL to expire. Each page has a TTL (Time to Live) defined, and when that time is up, the page is purged from the cache. As site admin, you have control over your pages’ TTLs, and it makes sense to choose a time that is as long as possible without impacting your site’s functionality.

For example, if you have a site with a few thousand pages, most of which never change, then you can set your TTL to something quite long, like a week, or maybe even a month.

On the other hand, if your site is frequently being updated, you’ll want a TTL that isn’t very long, like a day or 8 hours.

Purge through activity

There are certain events that are built in to LSCache that trigger a purge. If a post is edited, saved, deleted, trashed, or an attachment is deleted, then that post is purged from the cache.

Additionally, LSCache has a really nifty tagging system that allows pages to be grouped together and purged all at once after a triggering event. Here’s an example that shows the “smart purge” system in action:

You publish the following post:

Title: Hello, World!

Category: Greetings

People visit your site, the post ends up in the cache.

You then edit the post and change the Title and add a second Category:

Title: Hey, World, How Are You?

Category: Greetings, Questions

Since there have been changes to the post, the following pages are purged from the cache according to the rules set up in LSCache admin:

• The post itself
• The front page and/or home page of your site
• The author archive page
• The post type archive page
• The monthly archive page
• The “greetings” and “questions” category pages

You can change the rules to purge even more pages than this (or fewer), if it’s appropriate for your site.

This purge tag functionality is very powerful. It means that LSCache can do a targeted purge like we saw above, removing the edited post, as well as every other page that is influenced by that post. Without a tagging system, other plugins can either purge too little (just the post) or too much (all of the site’s pages).

This functionality allows you to specify relatively long TTLs for your pages, knowing that LSCache will step in and purge any pages that are affected by recent activities.

Some things cannot be cached

Not every page on your site is cacheable. As of version 1.1.2, these are some of the pages that LiteSpeed Cache considers uncacheable, a few of which are configurable in WP-Admin:

• Admin pages
• Post requests
• Pages where no theme is in use
• Any page that is specified as “do not cache” in WP-Admin
• Any post that has a category or tag that is specified as “do not cache” in WP-Admin
• Any request that has a cookie or user agent that is specified as “do not cache” in WP-Admin

Public cache vs. private cache

As of this writing, the LiteSpeed Cache for WordPress plugin only deals with public cache. This will be changing soon, and we’ll update here when it does. But for now, let’s talk a bit about the difference between public and private, and what that means in a caching context.

[UPDATE: Private cache is available now.]

Public cache is cache that can be accessed by everyone. A single copy of a publicly-cached page is stored and served to everyone who requests it.

Private cache, on the other hand, is only accessible to an individual visitor. It usually contains information that is only pertinent to that particular user (for instance, shopping cart contents, or a personalized greeting). When a page is privately-cached, there is a separate copy stored for each user that requests it.

As previously mentioned, the WP plugin currently only deals in public cache, and so any page that has private data on it, is just not cached at all.

When a user is logged in, there is the potential for every page to have private data on it, and so pages are never cached for logged-in users.

We are very close to releasing a new version of the plugin that will support Edge Side Includes (ESI). This is technology that allows us to “punch holes” into publicly-cached pages, and treat those areas differently, whether that be to store them in private cache or to not cache them at all. We will have a lot more to say about this when it’s ready, so stay tuned for that!

[UPDATE: ESI is available now.]

LiteSpeed Cache vs. Other Plugins

As we discussed earlier, LSCache is an integral part of LiteSpeed Web Server. The plugin is merely the channel through which a WP admin can communicate with the server. This is not the way that other WP cache plugins operate. Other cache plugins don’t have the luxury of such a close relationship with the server. They must sit on top of the server, while LSCache is integrated directly into it.

This is an important distinction. To understand why this is so, we need to look at how WordPress caching works for just about every plugin (including ours):

The most effective WordPress caching plugins use rewrite rules to manage the cache.

The rules tell the server where to look for cached content. Plugins can place pages in the cache by writing to the file system, and they can purge pages from the cache by deleting the files. They can tell whether or not a page is cached by checking for the presence of the file. And they can tell if a cached page has expired by comparing the file time to the page’s TTL.

Pretty much all cache plugins can do these things, but that is the extent of their ability to manage the cache. If a plugin wants to avoid the expense of invoking PHP, then it cannot “remember” information about the cache entries between user sessions. Either the cached files exist, are fresh and can be served, or they don’t exist and/or cannot be served. That’s it.

LiteSpeed Cache can go further. Because the cache is integrated into the server, LSCache can remember things about the cache entries that other plugins cannot, and it can analyze dependencies. It can utilize tags to manage the smart purging of the cache as we discussed earlier, and it can use vary cookies to serve multiple versions of cached content based on things like mobile vs. desktop, geographic location, and currencies.

Through its tight integration with the server, LiteSpeed Cache provides powerful cache management tools that are simply not possible for the other plugins to replicate.

LiteSpeed Cache’s relationship with LiteSpeed Web Server translates into superior performance, as our benchmarks can attest. Even better, see what other people are saying!

If your WordPress blog is powered by LiteSpeed Web Server, and you haven’t given our cache plugin a try yet, I hope we’ve convinced you by now that it’s worth a try!

Conclusion

And thus ends our Caching 101 series. That wasn’t too painful, was it? You should now understand how LiteSpeed Cache works, and why it’s so unique among the available plugins. Now that we’ve got this basic foundation down, we can start talking about more advanced topics that rely on this knowledge. For example, we’d like to share some tips for plugin authors who want to maintain compatibility with LSCache. You can’t talk about that without understanding a bit about how LSCache does what it does! Keep an eye out for that topic (and others like it) in future installments.

In the meantime, if you have questions, please don’t hesitate to leave a comment. We’d love to help!

—

Have some of your own ideas for future WordPress Wednesday topics? Leave us a comment!

Don’t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:

• Subscribe to the WordPress Wednesday RSS feed
• Download LiteSpeed Cache for WordPress plugin
• Learn more about the plugin on our website