The idea behind cache preloading is to trigger your caching solution to generate a cache of all the pages on a particular site. Versus having them generated when they’re visited. This is important as a cached response will be faster than a response that is un-cached but actually generates a cache for the next visitor.

How does cache preloading work? It’s pretty simple, you’ll have a program or piece of code grab the sitemap of your the site in question you want to preload (or another source that lists all your sites URL’s you want to preload).

The program or code will then take each URL and trigger a visit, this will then trigger your site to generate a page cache using whatever caching solution you have in place. If you have a site with 10 pages, this is fairly quick, but if you have 1000’s of pages, it may take longer.

When a visitor visits any of the URL’s that were preloaded, they will receive the cached version which will load faster than an un-cached version.

If you decide you want to setup cache preloading for a site, you need to make sure you have the following in place.

There’s a number of options, either built into existing caching solutions or through a plugin.

Need to explain more.

Need to explain more.

Need to explain more.

https://patrickmn.com/projects/ocp/

The idea behind cache preloading is simple, but it’s not efficient. It will speed up sites that are infrequently accessed, but it does little for sites that are frequently accessed. It will increase page speed scores, but it will utilize server resources frequently.

I said it, it’s extremely inefficient. Not only do you have to run the cache preloading consistently to keep your pages cached. It requires server resources for each page, which can result in a slow down to other tasks on the server, such as someone browsing the WordPress admin or pages that are un-cached like a WooCommerce checkout.

If you don’t have a high enough Cache Time to Live, you’ll have to run a cache preload more often. With a higher cache time to live, you also run the risk of wp_nonce on forms not working correctly. Or data not being updated properly, such as product stock with WooCommerce.

Note, that both issues raised above are not a problem for Litespeed Enterprise caching as the LSCache plugin is able to use ESI to render parts of a page dynamically.

If you have stock changes frequently, you might see issues with a product being available and then out of stock on checkout which is un-cached.

Some solutions aren’t aware of pages that are already cached, Optimus Cache Prime is a good example. It doesn’t know if a page is cached already or not, so it will simply visit all the pages of a site. You might think, this isn’t bad since if a page is already cached it will return a cached copy and there isn’t many resources used.

However, Optimus Cache Prime will still need to load the page, wait and move on to the next one. Which does take time for your overall run, and could be avoided alltogehter.

A way around this is to collect pages that are already cached within your current full page caching solution, and exclude them from being pre-loaded. This way your preloading program can simply work on pages that need to be cached.

When you’re using the FastCGI caching method within Nginx, there is a configuration option fastcgi_cache_background_update which controls how cache is generated. Here’s what the Nginx help page says.

Why am I mentioning this configuration option? Well, it’s rather important to understand how this option will help you with preloading your sites cache.

The above setting improves your cache efficiency and cache preloading efficiency. When a page is expired, the cache isn’t discarded like it normally would be. It’s kept until a request is made to the page, at which point the stale cache is served and in the background the page cache is generated again. This means the visitor get’s a cached version of the page, while the next visitor will get a fresh cached version of the page.

What does this mean? You effectively only need to run a cache preloader when something or someone purges a single item in the cache or the entire sites cache. You can go a step further and run the cache preloader based on when specific WordPress hooks are fired. If a single item is purged, then you preload that pages cache or when the entire cache is purged you run the cache preload on the entire site.

There is only one caveat, if the Nginx main process is restarted then the FastCGI cache is cleared and you’ll need to run a cache preload on the entire site.

Need to add more here.