Most site owners notice this pattern eventually. You update the menu, clear the cache, and open the home page to check it. It is noticeably slow. You reload, and now it is quick. Fine, you think, it was just the first load. But every visitor who lands on a page before anyone else has opened it since that purge gets the same slow first load. On a quiet site, that can be most of them.
Preloading is the fix for that gap. Cache preloading explained in one line: a small crawler visits your pages itself, in the background, so the cache is already warm when a real person arrives. It also has a cost in server load, and on some sites it does more harm than good.
Why the first visitor after a purge is slow
A page cache stores a ready-made copy of each page the first time someone requests it. Until that first request, there is no copy. That empty state is called a cold cache. The first visitor to each page triggers the full build: PHP runs, the database is queried, the HTML is assembled. Only then is the copy saved for the next person.
A cache goes cold in several ways:
- You or a plugin purges everything, for example after a theme setting or menu change.
- Cached copies reach the end of their lifetime and expire.
- The host restarts or clears its server cache.
- A plugin, theme or WordPress update triggers an automatic full purge.
- The site moves to a new server.
On a busy site, the first visitor to each page warms it for hundreds of others, so the cost is spread thin. On a site with modest traffic, many pages are visited only a few times a day. If their cached copies expire between visits, a large share of real visits land on a cold page. If your site always seems slow on the first visit and fast after, our post on why a site is slow on the first visit covers the other causes too, including the browser and connection side.
Cache preloading explained step by step
A preloader is a small crawler built into your caching plugin or server. It works roughly like this:
- It builds a list of addresses to visit, usually from your XML sitemap.
- It requests each address in turn, as an ordinary logged-out visitor would.
- Each request causes the page cache to build and store that page.
- It pauses between requests, or handles a few at a time, so it does not swamp the server.
- It repeats the process after a purge, after cached pages expire, or on a schedule.
Many plugins also do a targeted version when you publish or update a post: they purge that page and the pages linked to it, such as the home page and its category, then immediately request them again so they are warm straight away.
Where the list comes from matters. A sitemap-based preload visits the pages you actually want indexed. A crawler that follows links instead can wander into tag archives, paginated listings and filter addresses you never meant to cache. Most plugins let you point them at a specific sitemap, which is the safer choice. WordPress has produced a basic sitemap for some years, and SEO plugins usually generate their own.
What preloading warms, and what it does not
It is easy to assume a preload makes everything fast. It only warms one layer, the page cache on your server. See our overview of how the website caches stack up for the others.
- It warms the logged-out version of each page in the list.
- It may warm the mobile version too, but only if your plugin keeps a separate mobile cache and the preloader is set to request both.
- It does not warm the CDN in other regions. A CDN edge in another country fills only when a visitor from that region asks for a file or page through it.
- It does not warm visitors’ browser caches. Each visitor’s first view still downloads your files.
- It does nothing for logged-in users or shoppers with a cart, who bypass the page cache anyway.
- It does not warm pages missing from the list, such as ad landing pages left out of the sitemap or addresses with tracking parameters, if your cache treats those as separate pages.
The cost: server load
Every page a preloader requests is a full, uncached page build. Preloading a site of a few hundred pages means a few hundred uncached builds in a short time. Each one occupies a PHP process on your server while it runs.
On generous hosting, that goes unnoticed. On a small shared hosting plan, it can push the account against its CPU or process limits, and then real visitors queue behind the crawler. The irony is a site that is slower for everyone while it tries to be faster. If you are not sure how many requests your server can handle at once, our explainer on PHP workers and how they queue shows why this happens.
Ways to keep the cost down:
- Use the plugin’s pacing settings: a longer delay between requests, or fewer requests at once.
- Preload only the sitemap of pages that matter, not every tag and archive.
- Avoid purging the whole cache for small edits, so full preloads happen less often.
- Use longer cache lifetimes where your content allows, so pages stay warm for longer between preloads.
- Watch the resource graphs in your hosting panel for the first few days after turning it on.
Scheduling, and the WP-Cron catch
Many preloaders rely on WordPress’s built-in scheduler, WP-Cron. WP-Cron has no clock of its own; it only fires when a page is requested. When traffic is light, a preload scheduled for after a purge may not start until the next visitor arrives, and that visitor gets the cold page anyway.
Switching WP-Cron to a real server cron job, which runs at fixed intervals regardless of visitors, makes preloading far more reliable. It has other benefits too, covered in our post on WP-Cron and site speed. Some server-level caches, such as LiteSpeed’s, run their crawler through the server rather than WP-Cron, and some hosts limit when or how often those crawlers may run.
When to warm up the website cache, and when not to
Good candidates
- Small and medium sites with modest traffic, where pages often expire unvisited.
- After a planned change such as a redesign, a menu overhaul or a server move, when every page is cold at once.
- Before a campaign. If you are about to send an email or launch ads, open the landing pages yourself, logged out, so they are warm before the first click arrives.
Think twice
- Very large sites. A store with thousands of products and variations, or a news site with years of archives, may never finish a full preload before the cache expires again. Preload the important pages, not everything.
- Weak hosting. If the account already runs near its limits, the crawler competes with real visitors.
- Frequent full purges. If something on the site purges everything every hour, a full preload every hour is constant uncached load. Fix the purging first.
- Stores with filter addresses. Layered navigation creates huge numbers of address combinations. Never let a link-following crawler loose on them.
- Busy sites. If real traffic already warms every important page within minutes of a purge, preloading adds load without much benefit.
Checking that preloading is working
- Purge the cache and wait for the preload to run, giving it plenty of time on a larger site.
- Pick a page you have not opened since the purge. Open it once, logged out in a private window.
- Check the response headers in the browser’s developer tools. If your cache adds a hit or miss header, the very first view should already show a hit.
- Check the plugin’s preload status or log, if it has one, to see how far it got.
- Look at your hosting panel’s CPU and process graphs for the time the preload ran.
If the first view still shows a miss, the page is not in the preload list, the preload has not run yet, or the crawler’s requests are being stored under a different cache key than real visitors’ requests, for example desktop only when the visitor is on a phone.
A sensible default
For a typical small business site with a few dozen to a few hundred pages, on reasonable hosting: preload from the main sitemap, at a gentle pace, after purges and when cached pages expire, with WP-Cron running on a real schedule. Then leave it alone and check the hosting graphs once in a while. Preloading is a finishing touch on top of a working page cache, and our page speed guide shows the bigger changes worth doing before it, while our post on WordPress page caching covers the cache it fills.
Frequently asked questions
How often should the cache preload run?
Usually only when it is needed: after a purge, and when cached pages expire. Running a full preload on a fixed short schedule regardless of changes mostly creates extra server load. On a small site with longer cache lifetimes, preloading after purges and expiry is enough to keep most pages warm.
Does cache preloading affect my analytics?
Normally not. Preloaders request pages from the server, but they do not run the JavaScript that analytics tools use to record visits, so they do not appear as visitors in tools such as Google Analytics. They do appear in raw server access logs and in some hosting statistics that count every request.
Can I preload if my host’s cache has no preload option?
Some hosts offer a warm-up or crawler setting in their panel, so check there first. Otherwise a developer can schedule a small script on a server cron that requests the main pages from your sitemap after a purge. For a handful of key pages, opening them yourself, logged out, after clearing the cache does the same job.
Can preloading get my site suspended on shared hosting?
It can push an account over its resource limits if it requests many pages at once on a small plan, and some hosts throttle or pause accounts that do that. Use gentle pacing settings, limit the preload to important pages and watch the hosting resource graphs after you first turn it on.
Slow pages after every cache clear, or a preloader straining the hosting, usually come down to cache lifetimes, purge rules and pace. Those are part of the caching configuration in our speed optimisation service, set to suit your server rather than a plugin’s defaults.
Next in this series: Cloudflare Caching for WordPress: Defaults, HTML, Purging
