Prerender Until Script: The Middle Ground Between Prefetch and Prerender
Load subresources and build the DOM without firing scripts or polluting analytics

Origin Trial: prerender_until_script is available as an Origin Trial in Chrome 144 through 150. You need to register for a token or enable it locally via chrome://flags/#prerender-until-script. No Intent to Ship has been filed yet.
Last reviewed by Arjen Karel on March 2026
Prerender Until Script: The New Mode for Speculative Loading
Latency is the bottleneck. I have said this for years, and it remains the single biggest problem in web performance. No matter how much we optimize our Critical Rendering Path or shave kilobytes off our bundles, we are ultimately bound by the laws of physics and the round-trip time (RTT) of the network.
For a long time, we have tried to cheat these laws using Speculative Loading: guessing where the user will go next and loading it beforehand. Until now, we had two main tools, and neither was perfect:
- prefetch: Safe and lightweight, but it only fetches the HTML. The browser still has to parse, build the DOM, and discover subresources (CSS, images) after the user clicks. It solves the network wait, but not the rendering work.
- prerender: The nuclear option. It loads everything, executes JavaScript, and renders the page in a hidden background tab. It is instant, but it is expensive. It eats bandwidth, consumes memory, and fires analytics pixels and executes code for pages the user might never see.
We needed a middle ground. The visual readiness of a prerender without the cost and risk of executing application logic.
How prerender_until_script works
prerender_until_script decouples parsing from execution. When you use this Speculation Rule, you instruct the browser to:
- Fetch the document (like a prefetch).
- Parse the HTML stream and construct the DOM.
- Run the Preload Scanner. This is the critical part. The browser discovers and downloads subresources like high-priority CSS and the LCP image.
The moment the parser encounters a JavaScript execution point, two things can happen:
- Synchronous scripts: The parser halts immediately.
- Async/defer scripts: They are downloaded and queued, but not executed.
The browser builds the visual shell of the page: the layout, the typography, the images. But the application logic stays frozen. The page sits in memory, fully laid out, waiting for the user to click.
When the click happens, the page is swapped in instantly. The JavaScript executes, the event handlers attach, and your analytics fire exactly when they should.
Prefetch vs prerender_until_script vs prerender
| Action | Fetches HTML | Parses HTML | Fetches subresources | Executes scripts | Analytics fire |
|---|---|---|---|---|---|
prefetch | Yes | No | No | No | No |
prerender_until_script | Yes | Yes | Yes | No | No |
prerender | Yes | Yes | Yes | Yes | Yes* |
* Full prerender can guard against premature analytics using document.prerendering, but you have to add that code yourself.
This is why prerender_until_script matters. You get the subresource loading and DOM construction of a full prerender, but without the analytics pollution and memory cost of running JavaScript. For content sites with heavy third-party scripts, this is the sweet spot.
The Implementation
We implement this using the Speculation Rules API. Because prerender_until_script is experimental (Origin Trial, Chrome 144 through 150), you need backward compatibility.
Browsers that do not recognize the prerender_until_script key will ignore it. Add a prefetch fallback for the same set of URLs. Chrome will deduplicate these rules and apply the most capable action available.
<script type="speculationrules">
{
"prerender_until_script": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/cart" } }
]
},
"eagerness": "moderate"
}
],
"prefetch": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/cart" } }
]
},
"eagerness": "moderate"
}
]
}
</script> The prefetch block is the fallback. In browsers that support prerender_until_script, Chrome picks the most capable action automatically. In browsers that do not, the prefetch rule still runs. You get the best available behavior without user-agent sniffing.
If you want to generate your own custom set of speculation rules, use the speculation rules generator.
How to enable prerender_until_script
Since this is an Origin Trial, you have two options:
- Register for an Origin Trial token at the Chrome Origin Trials dashboard. Add the token as a
<meta>tag in your<head>:<meta http-equiv="origin-trial" content="YOUR_TOKEN"> - Test locally by navigating to
chrome://flags/#prerender-until-scriptand enabling the flag.
The Origin Trial runs from Chrome 144 (January 2026) through Chrome 150 (approximately mid-2026). If the Chrome team ships it as a stable feature after that, the token will no longer be needed. The official Chrome blog post covers the full details.
Real-world speculation rules performance
No one has published prerender_until_script benchmarks yet (it is too new). But the broader Speculation Rules API has hard data from major deployments:
- Ray-Ban implemented prerender speculation rules and saw a 43% LCP improvement on mobile (4.69s to 2.66s). Conversion rates doubled.
- Shopify rolled out prefetch speculation rules across all Liquid storefronts and measured 130ms faster on desktop and 180ms faster on mobile across all loading metrics.
- Cloudflare Speed Brain uses speculation rules with an ML prediction model and reports a 45% LCP reduction on successful prefetches.
Adoption is growing fast. According to the 2025 Web Almanac, 35% of mobile websites now use the Speculation Rules API. Most of that growth comes from WordPress 6.8, which baked speculation rules into core in March 2025.
prerender_until_script should deliver results between prefetch and full prerender. The subresources are already cached and the DOM is built. The only work left on activation is script execution. Across sites monitored by CoreDash, I typically see speculation rules cut subsequent navigation LCP by 30 to 50%.
Considerations
Eagerness: I almost exclusively recommend moderate. This triggers the speculation on hover (when the pointer lingers for 200ms). immediate is too aggressive for most sites and risks wasting bandwidth on mobile connections.
Exclusions: Be disciplined here. Never speculate on state-changing URLs like /logout or /add-to-cart. While prerender_until_script protects against script execution, you should not even fetch these endpoints unnecessarily.
Parser blocking: The parser halts immediately upon encountering a synchronous <script> tag. If you have inline scripts early in the DOM (for example, <script>loadWhileIdle(chat.js)</script>), the prerender will stop there. Move scripts to the bottom of the page or use defer to maximize how much of the DOM gets prebuilt.
Inline handlers: prerender_until_script only pauses <script> elements. Inline event handlers on other elements (like <img onload="track()">) will still execute if the parser reaches them before a blocking script. Make sure your analytics and tracking are not triggered by inline handlers.
You can debug speculation rules in Chrome DevTools under the Application panel. The Chrome DevTools Network panel will also show speculative fetches with a distinct icon. Use Real User Monitoring to verify the actual INP and LCP impact after deploying speculation rules in production.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
