DEV Community

Cover image for WordPress Speculation Rules: When Prerender Makes LCP Worse
Apogee Watcher
Apogee Watcher

Posted on Originally published at devlog.apogeewatcher.com

WordPress Speculation Rules: When Prerender Makes LCP Worse

Enabling Speculation Rules on WordPress often makes the next click feel free. Prefetch or prerender warms a destination while the visitor still reads the current page, so demos look like an easy win. Many teams then open PageSpeed Insights or a field chart on the entry URL and see Largest Contentful Paint (LCP) move the wrong way. The feature did not magically break LCP as a metric; bandwidth, CPU, and main-thread time spent preparing another document can contend with the paint you still owe on the page that is loading now.

WordPress 6.8 ships speculative loading in core with a conservative default, and the Speculative Loading plugin plus other prerender helpers can go further. The rest of this note is a developer diagnose pass: when that trade-off hurts, how to tell prefetch from prerender on WordPress, which failure modes raise current-page LCP, and how soft-navigation measurement differs from speculation so you do not mix the clocks. For the agency settings and verification walkthrough, use WordPress Speculation Rules and prerender plugins vs Core Web Vitals (Apogee Watcher).

Why next-page prerender can make this page’s LCP look worse

Speculation Rules tell the browser which URLs to fetch early and how aggressively. Prefetch mainly warms the network cache, but prerender goes further: Chromium can build a near-ready document in a speculative context so activation feels almost instant. That work still costs something on the device and the connection that are also painting the current navigation.

LCP on the current URL is still decided by whatever becomes the largest contentful paint for this document load. If speculative work competes for the same radio, the same CPU, or the same critical path as your hero image and fonts, the current LCP can rise even while demos of “click the next article” look magical. Field data that samples cold entries will show that pain; lab runs that only exercise warmed destinations will hide it.

Treat “speculation enabled” and “LCP improved” as separate claims, therefore. Measure the entry experience you sell (cold homepage, campaign landing, product template) with speculation on and off, then measure the subsequent navigation separately. Do not average them into one victory slide.

Prefetch vs prerender on WordPress (short map)

On WordPress you usually meet speculation in two layers. Core 6.8 enables speculative loading with a cautious stance, commonly moderated prefetch rather than site-wide eager prerender. The Speculative Loading plugin from the WordPress Performance Team exposes eagerness and mode so you can choose prefetch or prerender and how early rules fire. Other “instant page” or prerender plugins inject their own rules or legacy hints, and stacking them with Core or with each other is a common way to over-fetch.

For API behaviour and safety notes, Chrome’s Prerender pages in Chrome documentation and the Make WordPress Core note on speculative loading in 6.8 are the source of truth. You do not need to re-implement the JSON by hand to diagnose a regression. You do need to know which layer owns the rules on the site in front of you: Core only, plugin only, or both plus a cache or CDN helper that also preloads links.

Failure modes that burn the current navigation

Eager prerender of too many URLs. Hover or viewport eagerness that prerenders every in-content link can start several speculative documents while the visitor is still waiting for LCP on the page they asked for. Dial eagerness down, prefer prefetch for broad lists, and keep prerender for a small set of high-probability next URLs.

Action and auth URLs in the candidate set. Add-to-cart, checkout steps, logout, and “add to wishlist” style endpoints should stay out of speculation. Accidental prerender of mutating routes wastes work and can create confusing side effects, so exclude them in plugin settings or filters before you debate hosting.

Stacked speculation sources. Core 6.8 plus Speculative Loading plus a theme “instant navigation” feature plus a CDN prefetch feature can all fire at once. The browser may honour more work than any single settings screen implies. Disable extras until one owner remains, then re-test.

Measuring the wrong navigation. A PSI run that lands on a URL already warmed by a previous speculative fetch is not the same as a cold entry from Search. Clear cache between runs, use a clean profile, and label screenshots as cold entry versus subsequent nav. If only the subsequent nav improved, say so in the client note.

Mobile contention. On constrained CPU and radio, the prerender tax shows up faster than a desktop demo suggests. Prefer mobile lab and field cuts when you decide whether to keep prerender or fall back to prefetch, especially on the money landing that Search actually sends.

Soft navigations vs speculative loading (do not mix the clocks)

Speculation Rules optimise hard navigations that the browser can prepare ahead of time. Soft navigations are Chrome’s model for in-document route changes (History API style) and how Core Web Vitals may eventually be sliced per transition. Enabling WordPress speculative loading does not mean soft-navigation Performance entries suddenly solve your SPA LCP story. Shipping soft-navigation observers also does not replace Speculation Rules on a classic multi-page WordPress theme.

If your stack is a hybrid (WordPress shell plus a React checkout, or a block theme with heavy client routing), keep the two programmes on separate checklists. Speculation asks which full document URLs may be prefetched or prerendered, and at what eagerness. Soft navigations ask whether Chrome detects route-like transitions and what you record for Interaction Contentful Paint. For the measurement prep on soft navigations, see Soft Navigations in Chrome 151: How to Prepare and What to Measure (Apogee Watcher). Mixing the two into one “we turned on instant nav” ticket is how teams ship the wrong fix.

What to measure before you roll back Core 6.8

  1. Identify the owner. View source or DevTools for type="speculationrules". Note Core, Speculative Loading plugin, or a third plugin. Remove duplicates.
  2. Cold entry LCP. Same money URL, speculation on vs off (or prefetch-only vs prerender). Mobile lab first. Capture LCP element identity so you know you did not change the hero by accident.
  3. Next-navigation feel. Timed click to the primary next URL with Network and Performance panels open. Confirm whether the browser used prefetch or prerender (Chrome’s speculation / prerender indicators in DevTools).
  4. Exclude list. Confirm cart, account, and form actions are not candidates.
  5. Field vs lab clocks. If Search Console or CrUX still looks worse after a lab win on subsequent navs, trust the cold-entry field cut for ranking conversations and keep speculation as a UX optimisation with an honest label.
  6. Schedule. One-off PSI after a plugin toggle is not enough. Keep a scheduled lab run on the entry URL so a later theme or plugin change cannot silently re-enable eager prerender.

If cold-entry LCP improves or holds and subsequent navigations feel faster, keep the feature. If cold-entry LCP worsens and the business cares about that URL in Search, prefer moderated prefetch or narrower URL lists before you disable Core’s speculative loading entirely. Write the choice down with the two clocks named so the next person does not re-enable eager prerender from a demo GIF alone.

FAQ

Does WordPress 6.8 prerender every link by default?

No. Core’s speculative loading default is conservative. Aggressive prerender usually comes from the Speculative Loading plugin settings or from third-party “instant” plugins. Check which script tag is present before you assume Core is the culprit.

Can Speculation Rules make LCP worse?

Yes, on the page that is loading now, if speculative work contends for network or CPU with the LCP element. They can still improve the next navigation. Measure both; do not report only the demo click.

Should I disable speculative loading if LCP regressed?

First remove stacked plugins, switch prerender to prefetch or lower eagerness, and exclude action URLs. Full disable is a last step after you know Core or a plugin is the owner and cold-entry LCP still fails that test.

How is this different from soft navigations?

Speculation prepares possible full document loads. Soft navigations describe client-side route changes inside an already loaded document. Different APIs, different metrics, different fixes.

Keep a schedule after you change eagerness

If you own WordPress performance for the site, treat every speculation settings change as a two-clock check: cold-entry LCP on the money URL, plus one primary next navigation, then keep those URLs on a schedule. Do that before the next client report, not a month later when CrUX has already moved. Run a free PageSpeed check on the entry URL today, then start a trial if you want that URL watched without waiting for a manual paste after every plugin update. The next click can still feel free; leaving eager prerender on while cold landings stay red is the cost of skipping that check.

References

Top comments (0)