WpW: Choosing Between Public Cache, Private Cache, and ESI
Welcome to another installment of WordPress Wednesday!
Today’s Topic: When to Use Public Cache, Private Cache, or ESI
Disclaimer: The information contained in this post is accurate for LSCWP v1.6.6 [release log]. If you are using a newer version of the plugin, some details may have changed. Please refer to our wiki for the latest!
LiteSpeed Cache can store pages in a public cache, in private caches, and via ESI. (ESI = Edge Side Includes, which can essentially result in a public/private hybrid.) Today we’re going to visualize these three types of caching, and help you to figure out which one is best for your particular application.
For the sake of simplicity, let’s say that you have a site with just one page on it, and that your site has four visitors.
This piece of paper represents the page of your site as stored in public cache. All four visitors to your site’s page are shown that exact same piece of paper.
PRO: Very little storage space is required.
CON: There’s no opportunity for personalization – everyone gets the exact same page.
Any page that has no personalized content whatsoever is a good candidate for public cache.
A blog archive page, for instance, could work, if it has no Admin Bar at the top, and there are no areas on the page that say “Welcome, Sally” or anything of that kind. When Sally visits the page, she sees exactly the same content as Linus, Charlie, and Lucy do when they visit.
Many simple sites do just fine with public cache. If you don’t allow your visitors to create logins, and you don’t create any special content based on data that you can learn from their IP address (for instance), the chances are very good that public cache will be adequate for your site.
So what do you do if your visitors can create logins, or you do want to display the weather for their IP’s city?
You’re going to need more paper for that.
When you have LSCache configured to save a page in private cache, it’s as if you have a whole pile of papers, one for each visitor to that page.
PRO: You can personalize each paper to a great extent – different colors, different patterns, a completely different design if you like…
CON: A lot more space is required to store all of those individual pages.
A classic example of data that should be cached privately is a shopping cart. You certainly do not want every visitor to your shop to be served the exact same shopping cart page. The contents of Sally’s cart are bound to differ from the contents of Linus’s cart.
The simplest way to deal with this is to store the shopping cart page in private cache. Or, in terms of our paper metaphor, set aside a new piece of paper for each visitor who accesses the page.
This is fairly simple to set up, but you have to be careful if you have storage limitations. It’s not a big deal with our 4-person example, but if you have 10,000 visitors to one page, that’s 10,000 copies of that page in private cache. It adds up!
So, what if you have a page with only a very small amount of private content on it? Is there an alternative to storing thousands of copies of the full page, when it’s only a tiny area of the page that is changing?
Sure there is, and it’s called ESI.
Public Cache with ESI Blocks
When you use ESI (or, Edge Side Includes), you are storing the full page in public cache: a single piece of paper like we had earlier. The difference is that now you are punching holes where the private information needs to go, and caching those holes differently.
When a visitor requests the page, they are served the one single page, but with their own set of special blocks plugging up the holes.
PROs: Very little space is required, and there’s room for a small amount of personalization.
CON: It consumes more resources to show a visitor a page that needs to be assembled from several pieces than it does to show them a page that is already intact.
Let’s look at that shopping cart again. In many cases, the shopping cart block in the middle of the page is the only piece that differs from visitor to visitor. The header, the footer, a sidebar or two, and possibly some displayed shipping policies may be exactly the same for everyone. In this case, it could be better to keep serving the full page from public cache, but punch a hole in it for the private shopping cart contents.
ESI is best used in situations where most of the page is public, but one or two sections of it are not. A personalized greeting, the aforementioned Admin Bar, a widget showing the visitor’s recent activity… those are all things that can be put inside an ESI block and cached differently than the rest of the page.
The biggest pitfall with using ESI is in using it too much on a single page. If you have many areas of private content on a page, the effort that the server must go through in order to reassemble the pieces can negate the caching benefits. For pages with a lot of private content, it’s better just to cache the whole page privately.
What Type of Cache is Right for You?
As you can see, all three configurations have pros and cons associated with them. You’ll need to look at your own site, and what you are trying to accomplish with it.
Can you get away with storing just a single page for everyone? Do you need to store a whole separate page for each of your visitors? Or can you use a single page with a few holes punched into it?
Furthermore, does the same strategy apply to every page on your site, or can you cache some pages differently than others?
|Cache Type||When to Use||Examples||Storage Space||Resources|
|Public||Page has only content that may be displayed to every visitor||*Blog post page|
*Blog archive page
*Product Information page
|Private||Page has extensive customization, relevant only to individual visitors||*User account page|
*Shopping cart page
*Available downloads page
|Significantly more than Baseline||About the same as Baseline|
|ESI||Page is mostly public with a few small areas of private content||On otherwise-public page:|
*Recent posts widget
|Slightly more than Baseline||Significantly more than Basline|
Keep in mind that the examples in the chart above are just that: examples. Even though “blog post page” is listed in the “Public” row, there could certainly be situations where blog post pages contain areas of private content. It depends on the theme and configuration of the site.
If you want to know more, take a look at these in-depth articles:
If you still can’t decide which way to go, feel free to post on our support forum. LiteSpeed Cache is capable of handling public cache, private cache, and ESI, and we’d be happy to help you figure it out!
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