Full-page caching makes WordPress feel fast for the 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 PageSpeed lab score on a pre-warmed URL and never notice that 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.
This post is about cache preloading inside Lightify: full-page cache with gzip, background warm from the sitemap, re-warm after purge, rate limiting, and mobile-aware variants. Not unused CSS, not YouTube facades, not speculative hover prefetch. Those help other parts of the stack.
If you still need the caching baseline, read how to set up full-page caching in WordPress. For why lab scores alone mislead, see Core Web Vitals explained.
The problem: cache that only helps the second visitor
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.
Step 3 is the tax. On shared hosting it is worse. On WooCommerce it is worse still if you accidentally cache cart and checkout (Lightify excludes those for you, but the homepage and category pages still need warming after churn).
Preload moves step 3 into a background crawl so the human never owns it.
What Lightify actually gives you for preload
Stick to shipped behaviour.
Full-page cache with gzip, warmed in the background.
Purge on publish or edit, so stale content does not stick around.
Cart, checkout, and account pages excluded automatically for WooCommerce-style flows.
Mobile-aware variants, separate cache per device class when that matters.
Cache preloading from your sitemap on a schedule.
Re-warm after a purge, so the pages you just cleared come back hot without waiting for traffic.
Rate limited so the warmer never fights real visitors for CPU.
Pair that with Lightify’s Core Web Vitals view from real traffic (LCP, INP, CLS, FCP, TTFB) so you can see whether warming actually moved field data, not just a lab run you refreshed twice.
Turn preload on the right way
- Enable full-page cache first. Preload with caching off is busywork.
- Confirm the sitemap is current. Broken or incomplete sitemaps mean the warmer never sees half your money pages. Rankify (same membership) can own sitemaps if that is your SEO stack; otherwise use whatever XML sitemap you already trust.
- Turn on cache preloading and pick a schedule that matches publish cadence. A news site needs tighter loops than a brochure site that updates monthly.
- Leave rate limiting on. Polite crawls protect the live site during traffic spikes.
- Publish a test page, watch purge + re-warm. Confirm the URL is cached before you share it on social.
What to put in the warm set (and what to skip)
Warm what people actually hit:
- Homepage and main landing pages
- Top category and product archives
- Cornerstone blog posts
- Pricing and key comparison pages
Skip or exclude:
- Cart, checkout, my-account (already excluded)
- Logout, nonce, and admin-adjacent URLs
- Faceted filter URLs that explode into infinite combinations
- Preview and thank-you endpoints
If your sitemap includes every tag archive from 2014, trim it. Preloading junk burns CPU and storage for pages nobody visits.
Pitfalls that make preload look “broken”
Two caching plugins at once. Deactivate WP Rocket, LiteSpeed Cache, W3 Total Cache, and friends before Lightify owns the page cache. Two layers purge differently and fight.
Host or CDN already caching HTML. That can be fine. Know who is authoritative. Lightify plays with Cloudflare, Bunny, Kinsta, WP Engine, SiteGround, Cloudways-style stacks, but you still want one clear purge path.
Assuming lab LCP equals field LCP. Warming helps TTFB and HTML generation. It does not fix a 3MB hero or a third-party chat widget. Use Lightify’s real-visitor vitals and fix media and assets separately.
Warming during a migration. Finish DNS and SSL first. Do not preload a half-cutover domain.
Ignoring mobile variants. If desktop HTML is warm and mobile is cold, your phone traffic still pays. Keep mobile-aware caching on when your theme diverges by device.
How this fits with the rest of Lightify
Preload is one piece of the performance story:
- Assets: minify, defer, delay JS, remove unused CSS, self-host third-party files
- Media: lazy load, preload the real LCP image, YouTube facades
- Cleanup: emojis, dashicons, Heartbeat, scheduled database tidy-ups
- Speculative loading: fetch the next page on hover or via Speculation Rules
Do not turn every aggressive toggle on day one. Cache + preload + conservative asset rules usually move the needle. Then tune with field vitals.
How this fits DaftPlug Pro
Lightify ships in the same membership as Progressify, Generatify, Rankify, and Snapshotify. One Pro licence, every plugin. Site-count tiers only: pricing. Fourteen-day money-back. Free Lightify exists to try the baseline; Pro is where the full optimization set and monitoring live together without stacking three speed plugins.
A simple weekly check
Once a week:
- Purge a non-critical URL on purpose.
- Confirm preload re-warms it without you visiting.
- Spot-check TTFB on that URL from a private window.
- Glance at Lightify’s real-visitor vitals for pages that still look slow.
If HTML is warm and LCP is still poor, the problem moved to images, fonts, or third-party scripts. Preload did its job. Fix the next layer instead of turning the warmer into a scapegoat.
Takeaway
A full-page cache that waits for a human to miss is only half a cache. Point Lightify at your sitemap, warm on a schedule, re-warm after purge, and keep the crawl polite. The first visitor after you hit Publish should get the fast path, not build it.