KakapoWP KakapoWP
Log in Try for free
Help Center/Performance/Setting up cache preloading

Setting up cache preloading

Applies to: Kakapo Performance· 4 min read

Measure first: does the self-call work?

Preheating means that your web server calls up its own pages. Whether that works on your setup is answered by the button “Test self-call”: it fetches exactly the home page and reports the status code, the transferred size and the response time. If HTTP 401 or 403 comes back, there is usually an access barrier in front of it — basic auth in front of a staging site, or a firewall. If the test runs into its time limit of 10 seconds, the server is often blocking itself, because only a single PHP worker is free and that one is already occupied by your click. Two further requirements are checked as well: the page cache must be switched on and the cache directory must be writable for the web server. As long as one of them is missing, the preview and the start button stay disabled and the reason is shown below them in plain words.

Where the addresses come from

There are two sources. “Sitemap” covers the whole site; without an entry, /wp-sitemap.xml is used, while Yoast and Rank Math put theirs at /sitemap_index.xml. A sitemap index is followed one level deep, across at most 25 sub-sitemaps. Only addresses of this site can be entered; another host is rejected with an error message. If not a single address comes back, the message names the reason — the most common one: if “Discourage search engines” is set under Settings › Reading, WordPress switches its sitemap off and delivers the 404 page instead, and does so with status code 200. Anyone who only looks at the code takes that for success. “Recently changed content” needs no sitemap: the home page, the posts page and the most recently edited posts and pages, 50 by default, adjustable between 5 and 500. In everyday use this is often the more suitable source, because what you have just edited has dropped out of the cache and will be called up next.

Reading the preview

“Check queue” only counts — nothing is changed until then. The breakdown separates things cleanly: addresses found, duplicates, ones on other hosts, ones that are never cached (with up to eight examples including the reason), ones that are already in the cache and fresh. Right at the bottom is the number that would actually be fetched, plus the first twelve addresses for you to check. If a line “above the upper limit” appears, the rest does not fit into one run: the default is 300 addresses, 10 to 5000 are allowed. Under “Scope” you decide between “only missing pages” and “regenerate everything”. Nothing is lost when regenerating — a cache file is created again by itself on every call. Incidentally, the queue is rebuilt at the start; the list from the preview is not carried over, and minutes can pass between checking and clicking.

Chunks, time limits and what drives the run

One step fetches 5 addresses by default (adjustable from 1 to 20) and hands back after 20 seconds at the latest, so that no call runs into the server's time limit. In addition, each address has its own time limit, 10 seconds by default, adjustable between 3 and 30; after that the address counts as failed and the run continues. On weak hardware you turn the chunk size down, not up: the run then takes longer, but the site stays usable alongside it. The steps are driven by the browser as long as the admin page is open, and after that by WP-Cron — in a separate call that no visitor is waiting for. If DISABLE_WP_CRON is set, things only continue after you close the tab if a real cron on the server calls wp-cron.php. Only one step ever works at a time; a lock of 120 seconds prevents two open tabs, or the browser and cron, from fetching the same addresses twice and counting the numbers more than once. “Cancel” takes effect between two addresses, not only at the end of the chunk; cache files that have already been created remain valid.

Reading the result and starting runs automatically

Every fetch ends in exactly one of three lines. “Stored in the cache” means: after the fetch the file was actually there — what is checked is the file system, not the status code. “Delivered, but not cached” means: the page came back but was not stored; as a rule an exclusion rule of the page cache then applies, and that is where it should be checked, not here. “Failed” covers timeouts, error codes and redirects; redirects are deliberately not followed, because the target address is what belongs in the sitemap. The log keeps the last 40 fetches; the table shows 25 of them with address, status code, duration and result. Its own fetches carry a marker and therefore do not flow into the hit rate of the cache — otherwise the statistics would rise without any visitor getting anything out of it. Two switches start runs without you: after the cache has been cleared and on a schedule, hourly, twice daily or daily (daily by default). Both only start if none of the requirements is missing.

Was this article helpful?