Speculation Rules API Prerender Until Script: Test the Middle Ground

A reader opens a product page, adds an item, then follows a link. A page that appears instantly but shows an old cart count has failed the reader. A dashboard that records a visit before the person arrives has failed the analyst. Those are the costs hiding behind a quick performance demo.

The Speculation Rules API prerender until script addition gives Chrome a middle option between fetching HTML and executing a full hidden page. Chrome can fetch the document and subresources and start rendering. It pauses when it meets a blocking script and waits for navigation before it continues. The idea is useful because many sites want more than prefetch but cannot yet make every side effect safe for full prerender.

Speculation Rules API prerender until script: what this mode actually does

Chrome’s origin-trial announcement says that the feature starts from Chrome 144. A normal prefetch obtains the HTML document but does not fetch subresources or execute JavaScript. A full prerender fetches resources, renders and starts JavaScript as if the page were open in a hidden tab. That can make a later navigation feel instant, but it can also fire analytics or expose stale state before the person chooses the page.

prerender_until_script takes a different path. It can fetch CSS, images and other subresources and begin rendering, then stops before a blocking script. Deferred and asynchronous scripts do not block the parser, but Chrome delays their execution until activation. This leaves sites with a chance to test the performance gain while keeping a narrower set of JavaScript effects out of the speculative phase.

The feature remains an origin trial. Treat it as a controlled experiment, not a compatibility layer. Chrome’s guidance says an unrecognised value does not automatically become a fallback, so a site should include a normal prefetch rule beside it for browsers that do not support the new key.

Choose a route, then write down its forbidden effects

Make the first rule narrow. Use a known list of URLs or a document rule that matches a small content section. The technical rule may be only a few lines, but the rollout record should name the pages, the user signal that makes speculation reasonable, the owner and the signal that ends the test.

For each candidate page, list what must not happen before activation: purchase and account telemetry, an outbound request that represents a view, a mutation that writes server state, and a value that becomes inaccurate after the current page changes. This list makes a useful code review prompt. It also catches work that a performance specialist might not own, such as a marketing pixel or a cart service loaded by a tag manager.

Chrome calls out analytics and stale ecommerce state as concrete risks of prerendering. The same question applies here: if the user changes state after Chrome starts preparing the next route, what guarantees a refreshed result after activation? Your answer might be a server revalidation, a client-side state update or a decision not to speculate that route. “It looked fast locally” is not an answer.

Measure activation, not just preload work

Instrument the real user journey. You want to know whether the feature improves the navigation that the reader sees, how many prepared routes reach activation, and whether the page reports an event twice or too early. Chrome notes that activationStart is non-zero for the new mode, while the usual prerender state signals cannot be read before scripts run. Build your measurement around that documented lifecycle rather than guessing from a generic page-load event.

Check the fallback separately. In an unsupported browser, the prefetch rule should remain useful without claiming the stronger behavior. In a supported browser, Chrome can select the appropriate rule when both are present. That makes the fallback a first-class part of the test rather than a silent degradation someone discovers from support mail.

Keep the performance change legible to the rest of the site

Speculation can become invisible infrastructure. Give it a visible release note, a feature flag or a small operational document. Record which URLs receive it, how the rules are delivered, which metrics define success and who turns it off. A new framework feature that stays undocumented becomes expensive when an unrelated analytics or authentication change lands months later.

For the interaction layer, compare the feature with our same-document View Transitions guide. A transition changes how a route feels after it is ready. Speculation rules can change how much work is already done before the route is chosen. They can complement each other, but they solve different problems.

The question to keep open

Expand the trial only after a route stays correct under a state change, analytics shows one truthful journey, and unsupported browsers still get the promised fallback. If one of those checks fails, keep the page on prefetch while you fix the ownership boundary.

The Speculation Rules API can make the next click feel immediate. The durable outcome is a site that stays honest when it gets there.