![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2017\/12\/null.png\" "\\"\\"")
<\/p>\n<\/p>\n
Welcome to another installment of WordPress Wednesday<\/a>! Disclaimer<\/strong>: The information contained in this post is accurate for LSCWP v1.6.6 [release log<\/a>]. If you are using a newer version of the plugin, some details may have changed. Please refer to our wiki<\/a> for the latest!<\/em><\/p>\n 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\u2019re going to visualize these three types of caching, and help you to figure out which one is best for your<\/em> particular application.<\/p>\n For the sake of simplicity, let\u2019s say that you have a site with just one page on it, and that your site has four visitors.<\/p>\n This piece of paper represents the page of your site as stored in public cache. All four visitors to your site\u2019s page are shown that exact same piece of paper.<\/p>\n PRO<\/strong>: Very little storage space is required. Any page that has no personalized content whatsoever is a good candidate for public cache.<\/p>\n 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 \u201cWelcome, Sally\u201d 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.<\/p>\n Many simple sites do just fine with public cache. If you don\u2019t allow your visitors to create logins, and you don\u2019t 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.<\/p>\n So what do you do if your visitors can<\/em> create logins, or you do<\/em> want to display the weather for their IP\u2019s city?<\/p>\n You\u2019re going to need more paper for that.<\/p>\n When you have LSCache configured to save a page in private cache, it\u2019s as if you have a whole pile of papers, one for each visitor to that page.<\/p>\n PRO<\/strong>: You can personalize each paper to a great extent – different colors, different patterns, a completely different design if you like… 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\u2019s cart are bound to differ from the contents of Linus\u2019s cart.<\/p>\n 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.<\/p>\n This is fairly simple to set up, but you have to be careful if you have storage limitations. It\u2019s not a big deal with our 4-person example, but if you have 10,000 visitors to one page, that\u2019s 10,000 copies of that page in private cache. It adds up!<\/p>\n 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\u2019s only a tiny area of the page that is changing?<\/p>\n Sure there is, and it\u2019s called ESI.<\/p>\n 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.<\/p>\n 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.<\/p>\n PROs<\/strong>: Very little space is required, and there\u2019s room for a small amount of personalization. Let\u2019s 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.<\/p>\n 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\u2019s recent activity\u2026 those are all things that can be put inside an ESI block and cached differently than the rest of the page.<\/p>\n 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\u2019s better just to cache the whole page privately.<\/p>\n As you can see, all three configurations have pros and cons associated with them. You\u2019ll need to look at your own site, and what you are trying to accomplish with it.<\/p>\n
\nToday’s Topic:\u00a0When to Use Public Cache, Private Cache, or ESI<\/strong><\/p>\nPublic Cache<\/h2>\n
![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2017\/12\/null-2.jpeg\" "\\"\\"")
<\/p>\n
\nCON<\/strong>: There\u2019s no opportunity for personalization – everyone gets the exact same page<\/em>.<\/p>\nPrivate Cache<\/h2>\n
![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2017\/12\/null-3.jpeg\" "\\"\\"")
<\/p>\n
\nCON<\/strong>: A lot more space is required to store all of those individual pages.<\/p>\nPublic Cache with ESI Blocks<\/h2>\n
![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2017\/12\/null-4.jpeg\" "\\"\\"")
<\/p>\n
\nCON<\/strong>: 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.<\/p>\nWhat Type of Cache is Right for You?<\/h2>\n
![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2017\/12\/wpw31d-1024x341.png\")
<\/a><\/p>\n