Warm the WordPress Full-Page Cache From Your Sitemap Before the First Visitor
Full-page caching makes WordPress feel fast for people who arrive after the cache is warm. The first person after a deploy, a bulk edit, or a scheduled purge still pays the full generation cost: PHP, database, plugins, and template rendering. On a busy homepage that can be seconds. On a sale day it is also revenue.
Most teams celebrate a green lab score on a URL they already refreshed themselves. Real visitors keep stumbling into cold pages. Preload flips that. The cache is filled from your sitemap in the background so the first human gets a cached copy instead of building one for everyone else.
Lightify is the DaftPlug performance plugin. This post is about full-page cache with gzip, warmed in the background from the sitemap, re-warmed after purge, rate limited, with cart/checkout/account excluded and a mobile-aware separate variant. Not unused CSS, not delay JS, not YouTube placeholders.
If third-party hosts still tax every pageview next to caching, read Self-host third-party scripts on WordPress instead of hitting their CDNs. Cache and origin control stack well together.
What Lightify actually ships for cache preload
Feature list for this article only:
- Full-page cache with gzip
- Background warm from your sitemap
- Re-warm after purge
- Rate limited crawls so preload does not hammer the host
- Cart / checkout / account excluded (dynamic pages stay dynamic)
- Mobile-aware separate variant so phone HTML is not served a desktop cache copy by mistake
Supporting Lightify tools you can pair later: LCP/INP/CLS/FCP/TTFB from real visitors, minify/defer/delay JS, unused CSS, self-host third-party, lazy images/video/iframes, LCP preload, YouTube placeholders, speculative loading, DB cleanup, font preloading, resource hints, WebP on the fly.
Preload is about who pays the cold cost. Speculative loading is about the next click after they are already browsing. Different jobs.
Why “cache on first hit” quietly taxes real people
A typical day on a WordPress site:
- You publish a post. Cache for that URL (and often related archives) is purged.
- The next visitor requests the URL.
- WordPress builds HTML from scratch.
- The response is stored.
- Everyone after that is fast. The first person was your unpaid warm-up bot.
That pattern repeats after theme updates, WooCommerce stock changes that purge product pages, scheduled cache clears, and “empty cache” panic clicks in staging deploys that leak to production.
Sitemap preload moves the warm-up into the background. Lightify walks URLs you already declared as important, stores gzipped full-page HTML, then keeps re-warming after purges so the next human is not the canary.
Mobile-aware variants matter because phone templates often differ. One desktop HTML blob served to mobile is a layout bug dressed up as a performance win.
How to warm the cache from the sitemap in wp-admin
1. Enable full-page cache first
In wp-admin, open Lightify. Turn on full-page cache (with gzip). Confirm cart, checkout, and account paths are excluded. If a logged-in or cart page gets cached wrong, you will chase ghosts for a week.
Smoke-test: open a public post while logged out, view source or response headers for a cache hit indicator Lightify exposes, then reload. Second load should be the fast path.
2. Point preload at your sitemap
Enable cache preload / warm from sitemap. Use the sitemap WordPress (or your SEO plugin) already publishes. That list is your “these URLs matter” contract. Do not invent a second hand-maintained URL dump unless you have a reason.
If the sitemap is huge, that is fine. Rate limiting exists so preload does not become a self-DDoS.
3. Confirm re-warm after purge is on
Publishing and bulk edits will purge. Re-warm after purge is how you avoid a cold spike every time an editor hits Update. Leave it on unless you have a staging-only reason to pause.
4. Respect rate limits (and your host)
Preload should crawl politely. Keep rate limiting enabled. On shared hosting, start during off-peak hours the first time you warm a large catalog. Watch CPU and TTFB while the first warm runs. If the host complains, lower concurrency / respect the limiter rather than turning preload off forever.
5. Verify mobile-aware separate variants
With a phone user-agent (real device or DevTools), request a key URL after warm. Confirm you are not getting a desktop-only layout. Repeat for a few product and category templates if you run WooCommerce.
6. Exclude what must stay dynamic
Cart, checkout, and account should remain uncached. Also think about pages with per-user notices, geo banners, or A/B tests. If a page must be unique per visitor, keep it out of the full-page path. Preload cannot fix a page that should never have been cached.
7. Measure with real-visitor vitals, not only a lab refresh
After preload has run, watch TTFB and LCP from real visitors in Lightify’s Core Web Vitals dashboard. Lab tools are useful. They are also easy to fool by refreshing the URL yourself before the test. Real visitors tell you whether cold pages still leak through.
8. Pair preload with the rest of the performance stack (without confusing jobs)
After the first warm succeeds, keep roles clear:
- Preload fills HTML before humans arrive.
- Speculative loading prefetches the next page on hover after they are browsing.
- Self-host / minify / delay JS cut third-party and main-thread cost on every hit, cached or not.
- Real-visitor CWV tells you whether the first paint still hurts on phones.
You can enable those later. Do not turn preload off because a lab tool still complains about a giant LCP image. Fix the image. Keep the cache warm.
What good looks like
After preload has run for a day:
- Logged-out hits on key sitemap URLs come back warm without you refreshing first.
- A publish + purge is followed by re-warm, not a lunchtime TTFB spike.
- Cart, checkout, and account never serve a stale cached stranger’s basket.
- Mobile UA gets the mobile variant, not a desktop HTML surprise.
- Rate limiting kept the warm job polite; the host did not page you.
- Real-visitor TTFB in the CWV dashboard looks calmer after deploys.
If only the URLs you personally tested are fast, the sitemap list is incomplete or re-warm is off. Fix coverage, not the lab tool.
Pitfalls (the ones that bite)
Warming while cart/checkout are still cacheable. Fix exclusions before you celebrate TTFB.
Turning off rate limits to “finish faster.” You can knock over PHP-FPM and make the site slower for everyone during the warm.
Assuming one HTML variant fits mobile and desktop. Enable and verify the mobile-aware separate variant.
Forgetting re-warm after purge. Editors keep publishing. Cold spikes return by lunch.
Preloading a broken sitemap. 404s and redirect chains waste crawl budget inside your own warm job. Fix the sitemap first.
Expecting preload to replace minify, delay JS, or image work. Preload helps the first byte and HTML reuse. Heavy JS and huge heroes still hurt LCP/INP.
Testing only while logged in as admin. Admin bars and logged-in caches lie. Use a private window.
Practical checklist before you call it done
- Enable full-page cache with gzip.
- Exclude cart, checkout, and account.
- Enable sitemap-based background preload.
- Keep re-warm after purge on.
- Keep rate limiting on.
- Confirm mobile-aware separate variants on a phone UA.
- Publish a post, wait for re-warm, hit the URL logged out, confirm a warm response.
- Spot-check homepage, a category, and a product/post template.
- Watch real-visitor TTFB/LCP for a day after a big purge.
Takeaway
The first visitor after a purge should not be your unpaid cache warmer. Sitemap preload moves that work into the background, rate limited, with dynamic commerce paths left alone and mobile HTML kept separate.
Lightify ships full-page cache with gzip, background warm from the sitemap, re-warm after purge, rate limiting, cart/checkout/account exclusions, and mobile-aware variants. Turn those on before you chase another lab screenshot.
One Pro membership unlocks Lightify plus Progressify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only. See pricing when you want the first human to get the cached page.
Warm the sitemap once on purpose. Then purge a post and watch the re-warm. When the next stranger is fast, preload earned its place.