Cache Preloading (Cache Warming)
Populate the page cache proactively before visitors arrive so no one ever hits an empty cache.
Metrics
This technique can move up to 67% of LCP's share of the Lighthouse score.
This technique does not move TBT.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 67% of SI's share of the Lighthouse score.
This technique can move up to 100% of TTFB's share of the Lighthouse score.
Overview
Cache preloading — also called cache warming — crawls a site’s URLs and requests each page before real visitors arrive, triggering page generation and storing the result in cache. This ensures that the very first visitor to any URL receives a cached response rather than waiting for PHP execution. Without cache warming, new deployments, cache clears after updates, and after cache expiry cause the first visitor to each URL to experience the full uncached page generation time.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.
The Problem
Cache-based performance optimization has a fundamental weakness: the first request after a cache miss is always slow. After a WordPress update, the entire cache is cleared. After a plugin change, thousands of cached pages are invalidated. After a scheduled cache expiry, pages gradually go cold as their TTLs expire. In each case, the first visitor to each affected URL hits a fully uncached PHP + database execution path — often the worst time for performance, since deploys often coincide with high-traffic moments like announcements and email sends.
Performance Impact
LCP
High
cached pages deliver LCP elements faster as the full page is served from disk/memory for every visitor
FCP
High
every visitor — including the very first — receives a pre-warmed cached response
SI
Moderate
cached pages render more completely and faster, improving Speed Index across the board
TTFB
500ms–2s+
TTFB drops from full PHP generation time to cache file read time for all URLs from first visit
Risk: Low
cache warming increases server load during the warming process — schedule outside peak hours on large sites
How it works
01
Crawl the sitemap to discover URLs
Cache preloaders fetch the XML sitemap (
/sitemap.xmlor/sitemap_index.xml) to build a list of all pages, posts, categories, and archives to warm. For large sites, warming starts with the highest-priority URLs — homepage, top-traffic pages — and works through the list in order.02
Sequential or concurrent warming
Sequential warming (one request at a time) puts minimal server load during the process. Concurrent warming (5–10 simultaneous requests) is faster but spikes CPU and database load. Most cache plugins default to sequential warming to avoid self-imposed DDoS during deploys.
03
Trigger warming automatically after cache clears
Configure the cache plugin to start warming immediately after any cache clear event — WP updates, plugin updates, manual clears. This minimizes the window between cache invalidation and cache availability. WP Rocket, LiteSpeed Cache, and W3 Total Cache all support automatic post-clear warming.
04
Limit warming to high-traffic pages on large sites
Warming 50,000 pages sequentially may take hours. On large sites, focus cache warming on the top 100–500 pages by traffic (available from Google Analytics or server logs). Long-tail pages can warm lazily on first visit — the trade-off is acceptable given their low individual traffic.
Code Example
# Without cache warming:
# Deploy → cache cleared → first visitor to /blog/ waits 1.2s (PHP + DB)
# First visitor to /about/ waits 800ms
# First visitor to each of 3,000 pages waits full PHP execution time# With cache warming (WP-CLI + cURL):
# Deploy → cache cleared → warming process starts automatically
# wget crawls sitemap: requests all pages, populates cache
# All subsequent visitors (including first real humans) get cached responses
# Manual warm via WP-CLI (WP Rocket)
wp rocket preload --allow-root
# Custom bash: crawl sitemap and warm cache
curl -s https://example.com/sitemap.xml \
| grep -oP '(?<=<loc>)[^<]+' \
| xargs -P 5 -I{} curl -s -o /dev/null {}The -P 5 flag runs 5 concurrent curl requests. Adjust based on server capacity — start with 2–3 concurrent requests and increase if server load stays below 70%.
Limitations
- Cache warming generates real HTTP traffic to your own server — on shared hosting or resource-constrained servers, aggressive parallel warming can cause CPU spikes that affect live visitors.
- For large sites (10,000+ pages), a full warming pass may take hours. Prioritize by page importance rather than attempting to warm every URL.
- If the site uses a CDN, cache warming must also prime CDN edge nodes — the CDN only caches pages after the first request reaches its edge. A separate CDN-specific warming step or CDN cache prefill API call is needed for full edge coverage.
Common Mistakes
Running cache warming with too many concurrent requests on shared hosting
Shared hosting plans often limit CPU to a fraction of a core. A warming process firing 10 concurrent requests can degrade performance for live visitors for the duration of the warm. Use a single-thread sequential warm (-P 1) and schedule it at off-peak hours.
Warming the cache but not setting an appropriate TTL
A warmed cache with a 5-minute TTL must be re-warmed every 5 minutes. Set TTLs appropriate to content freshness requirements — news sites may need 5–15 minutes; marketing pages can use 24 hours or more. Longer TTLs mean warming is needed less frequently.