- What is Cache Preloading?
- The basic function of Cache Preloading
- Cache Preloading Pre-Requisites
- Full page Caching
- A cache time to live that is appropriate.
- Adequate server resources.
- A cache preload program, plugin or code.
- Cache Preloading Options
- WP Rocket
- Optimus Cache Prime
- Issues with Cache Preloading
- Cache Preloading is Inefficient
- Dependant on Cache Time to Live
- Not great for Dynamic Sites like WooCommerce
- Preloading already Preloaded Pages
- Nginx FastCGI Tricks
- Cache Preloading and Object Cache
What is Cache Preloading?
The basic function of Cache Preloading
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.
Cache Preloading Pre-Requisites
If you decide you want to setup cache preloading for a site, you need to make sure you have the following in place.
Full page Caching
- WP Rocket, Nginx FastCGI/Redis, LSCache + LSE/Openlitespeed or another full page caching solution.
A cache time to live that is appropriate.
- A cache time to live designates how long the cache is to live before being discarded.
- You’ll want to make sure this is set appropriately as you’ll need to run your cache preload within this timeframe or you’ll preload too often or not often enough.
Adequate server resources.
- The process of cache preloading requires that each page of a site is executed, which means WordPress + PHP have to generate the page. This results in a spike in resources.
A cache preload program, plugin or code.
- You’ll need something to gather the URL’s to preload into cache and then visit each one.
Cache Preloading Options
There’s a number of options, either built into existing caching solutions or through a plugin.
Need to explain more.
Need to explain more.
Optimus Cache Prime
Need to explain more.
Issues with Cache Preloading
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.
Cache Preloading is Inefficient
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.
Dependant on Cache Time to Live
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.
Not great for Dynamic Sites like WooCommerce
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.
Preloading already Preloaded Pages
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.
Nginx FastCGI Tricks
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.
Syntax: fastcgi_cache_background_update on | off; Default: fastcgi_cache_background_update off; Context: http, server, location This directive appeared in version 1.11.10. Allows starting a background subrequest to update an expired cache item, while a stale cached response is returned to the client. Note that it is necessary to allow the usage of a stale cached response when it is being updated.
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.
Cache Preloading and Object Cache
Need to add more here.