Prefetch the Next WordPress Page Before the Click Lands
Most performance work obsesses over the page you are already on. Cache the HTML. Minify the CSS. Lazy-load the fold. That is necessary. It is also incomplete.
A huge share of perceived slowness happens between pages. The visitor finishes reading, aims at the next link, clicks, and waits for a fresh round trip. Your homepage can score well and still feel sluggish as a product because every internal navigation pays full freight.
Speculative loading flips that timing. While the pointer is still on the link (or the link is about to be tapped), the browser starts fetching the destination. By the time the click commits, the next page is often already downloaded, sometimes even prerendered.
Lightify puts that on a WordPress settings tab: Network Improvements. Prefetch on hover, focus, or touch start. Speculation Rules API where the browser supports it. Exclusions for carts, logout, and admin-style URLs. This guide is about that layer, not about flipping every asset toggle or chasing a lab score after you enabled page cache.
Why “fast page” and “fast site” are different jobs
Core Web Vitals grade the experience of a URL. Real humans experience a path: home → category → product → cart, or post → related post → pricing.
If each hop is 800 ms of waiting, five hops feel like a slow product even when each individual LCP looks fine in Search Console. Prefetch attacks the hop.
It also plays nicely with full-page caching. A warm HTML file sitting on disk is cheap to serve. Prefetching a cached URL is mostly bandwidth and a small amount of origin work. Prefetching an uncached, personalized URL is where people get burned. Pair this feature with a sane cache setup (Lightify’s page cache and preload, or your host cache with Lightify’s other optimizations). If you still need the caching primer, use the full-page caching walkthrough.
What Lightify actually enables
From the live product page and the Network Improvements docs:
Prefetch (on by default, conservative defaults). Same-origin links. No URLs with query strings. Cap of 12 prefetches per page. Fires as the cursor approaches a link on desktop, or as links enter the viewport on mobile. Delay, cap, and exclusions are filterable for developers.
Speculation Rules (Pro). Uses the browser Speculation Rules API to predict where the visitor is going and load it in advance. Can prerender, not only download, which is why navigation can feel near-instant on supporting browsers. On by default with Pro.
Resource hints (preconnect / preload / prefetch of specific URLs). Separate from link speculation. Useful when you know a third-party origin or a hero font is always late. Most sites need fewer hand-written hints than they think, because Lightify already preloads fonts and critical images elsewhere. Add a hint only when the network waterfall shows a late, blocking resource you can name.
Prefetch requests carry a Sec-Purpose: prefetch header. That matters for CDN and cache configuration below.
How to turn it on without surprising your server
1. Get the current page fast enough first
Speculative loading multiplies whatever the destination costs. If every internal URL takes two seconds of PHP and twenty database queries with no page cache, prefetch just schedules more expensive work earlier. Enable Lightify’s full-page cache (and deactivate a second cache plugin first; two page caches fight). Confirm cart, checkout, and account stay excluded. Lightify does that automatically for WooCommerce.
2. Open Network Improvements
In Lightify → Settings → Network Improvements:
- Leave link prefetch enabled unless you have a concrete reason to disable it.
- On Pro, leave Speculation Rules on and watch real navigations on Chrome.
- Do not spray preconnect across ten third-party hosts. Three or four critical origins max.
3. Respect the built-in safety rails
Lightify’s defaults skip query-string URLs. That keeps many cart-add, filter, and logout links out of the speculation path. Still audit anything on your site that changes state on a plain GET. Prefetch is a GET. If a “unsubscribe” or “delete item” link is a bare GET without a nonce, speculation can trigger it. Fix those URLs (POST, nonce, or exclude them) before you celebrate instant navigation.
Add explicit exclusions for any custom account, logout, or one-click action endpoints your theme registered outside WooCommerce’s usual paths.
4. Verify in DevTools
Chrome → Network. Hover internal links on a desktop page. You should see prefetch traffic for same-origin destinations, often with Sec-Purpose: prefetch. Click and note whether the navigation reuses that work.
If prefetches never appear:
- Destination sent
Cache-Control: no-store - CDN refusing prefetch purpose
- Link was cross-origin, had a query string, or hit the per-page cap
- You are testing a browser without support for the Speculation Rules path (prefetch may still work)
5. Watch bandwidth and origin for a week
Prefetch spends bandwidth on pages nobody opens. On a content site with a warm cache, that trade is usually excellent. On a thin VPS with heavy uncached PHP, dial the cap down or disable prerender until cache hit rates climb.
Field data still wins over vibes. Lightify’s Core Web Vitals dashboard is about real visitors on the URLs they land on. Speculative loading will show up more as “the site feels snappier when I browse around” than as a magic +20 on a single lab URL. For metric literacy, keep Core Web Vitals explained handy.
Pitfalls worth naming out loud
Prefetching personalized pages. “My account” HTML that includes a name and order list should not be a speculation toy. Keep exclusions tight.
CDN quirks. Some CDNs do not cache or even accept prefetch-purpose requests the way you expect. If the HTML is always a miss on prefetch, you paid for origin work twice. Adjust CDN rules or rely more on Lightify’s own page cache edge.
Stacking speculation plugins. Instant Page snippets, separate speculation plugins, and Lightify together can over-fetch. One owner for the behavior.
Confusing this with service worker offline cache. Progressify’s service worker helps repeat visits and offline. Lightify’s speculation helps the next click while online. They complement; they are not substitutes.
Preloading random assets “just in case.” Preload competes with LCP-critical bytes. The docs are clear: only preload what the first paint needs. Speculation of the next document is a different lever.
Turning every aggressive toggle on the same afternoon. Speculative loading is relatively safe with defaults. Combining it with delay JS, remove unused CSS, and three new exclusions in one deploy makes blame impossible. Change network improvements, browse the site for a day, then touch asset experiments.
A practical rollout order
- Page cache on, second cache plugin off, Woo dynamic pages excluded.
- Cache preload from the sitemap so popular URLs are warm.
- Network Improvements prefetch left on; Speculation Rules on if you are on Pro.
- Spot-check hover behavior and a mobile browse path.
- Only then add hand-written preconnect/preload entries from a real waterfall.
That order matches how Lightify is built: make the response cheap, then make the next navigation early.
Membership context
Lightify Pro (including Speculation Rules and the heavier optimization set) comes with the same DaftPlug membership as the other four plugins. Free on WordPress.org covers a serious baseline (page cache, minification, defer, CWV dashboard, and more). Pro adds the sharper knives. One checkout on pricing: Pro, Pro Plus, or Pro Max by site count. Fourteen-day refund.
Takeaway
Stop treating every navigation like a cold start. Once your WordPress pages are cheap to serve, let the browser fetch the likely next one while the visitor is still deciding. Lightify’s speculative loading and hover prefetch are the boring, productized version of that idea: same-origin, query-string aware, Woo-safe exclusions, optional Speculation Rules on Pro.
Instant pages are good. Instant moves between pages are what makes a site feel finished.