Back in August I wrote about how we rolled out Speculation Rules on Liquid storefronts. That post ended with a section on where we wanted to take the feature next. This one is a short update on one of those follow-ups: we switched our default configuration from eagerness: conservative to eagerness: moderate, and the numbers turned out even better than we hoped.
What changed Jump to heading
With conservative eagerness, the browser prefetches the next page on pointerdown, right when the buyer presses the mouse button or places their finger on the screen. That is already pretty early, but it still leaves very little time for the response to arrive before the browser fires the actual navigation.
Moderate eagerness starts earlier. On desktop, the browser triggers the logic once the cursor has hovered over a link for at least 200ms. On mobile, where hover does not exist, Chromium recently switched to a viewport-based heuristic: a link is prefetched once it has been sitting in view close to the buyer's last pointerdown for long enough to look like a plausible destination. You can read more about how that heuristic works in the design document.
In practice, this gives the browser a couple hundred extra milliseconds to fetch the next page on desktop, and a smaller but still useful head start on mobile.
Results Jump to heading
We measured the change against same-site requests speculated with eagerness: conservative.
The desktop result is the one that stands out. Across the curve, the median gain is -285ms TTFB, -224ms FCP, and -228ms LCP. Median TTFB for a speculated navigation is now close to zero, which means the HTML response often arrives before the buyer even commits to clicking. For roughly 10% of speculated navigations, TTFB is exactly 0: the response is already sitting in the cache when the navigation fires.
Mobile gains are smaller but consistent: -25ms TTFB, -20ms FCP, and -24ms LCP across the curve, with no regression at any percentile. Without hover as a signal, the browser falls back to a viewport heuristic. That heuristic may be a little conservative for storefront browsing, but making it more aggressive risks wasting data on links the buyer never taps. The Chrome team is actively experimenting with tuning it, so we may expect mobile numbers to improve over time.
The tradeoff Jump to heading
Prefetching earlier means the browser occasionally fetches a page the buyer never ends up visiting. At the same volume of actual page views, moderate triggers nearly 4x as many speculated requests as conservative on desktop, while on mobile the volume barely moves. In our case, that translated to about a 14% increase in the total number of HTML requests from supported browsers. Those numbers will depend on multiple factors: share of same-site navigations and device mix, to name a few. The desktop-versus-mobile gap is also wide enough to raise a question: should the API let authors set a different eagerness for them separately?
For us, the tradeoff is acceptable from both infrastructure and user perspectives. Still, your mileage may vary.
Scope and what's next Jump to heading
This change is live on all Liquid storefronts. For now, the benefit still applies only to Chromium-based browsers. The Firefox implementation is still in the works. For Safari, the prefetching support was in Technology Preview but got disabled due to a race condition bug. This has since been fixed by our own Yoav Weiss and we're hoping the feature will finally land in an upcoming Beta.
We are now looking at the prerender_until_script Origin Trial, a strategy we advocated for during design discussions with the Chrome team. We're hoping it will let us take advantage of the extra time we already have (that 0 TTFB tail) without the analytics and API-call issues that full prerender would cause.
More to come once we have data on that one.