demo · v147

Shell architecture simulator

The canonical use case for this opt-in: a shell page (think Office, Google Chat, JS Bin, a checkout host) where the meaningful content lives in a cross-origin iframe. With the new opt-in header, both render in parallel during prerender — activation is interactive immediately. Without it, the iframe waits until activation.

Origin trial: the Supports-Loading-Mode: prerender-cross-origin-frames opt-in is enabled in Chrome 147 behind chrome://flags/#enable-prerender2 in some builds. This page simulates both branches with deterministic timers so the comparison is reproducible no matter the browser.
winner: waiting for data…

Without opt-in

shell.example → checkout.embed.com (no header)
Order summary
Shell HTML/CSS/JS finishes prerendering in ~200ms.
cross-origin iframe held back
TTFI on activation: —

With opt-in

shell.example → checkout.embed.com (Supports-Loading-Mode: prerender-cross-origin-frames)
Order summary
Shell and iframe prerender together.
cross-origin iframe loading…
TTFI on activation: —

What's modelled

  1. Shell HTML: ~200ms to render.
  2. Cross-origin iframe: 600ms to load + 200ms to hydrate.
  3. Without the header, the iframe is held until activation — the user pays 800ms after click.
  4. With the header, the iframe runs concurrently with the shell — activation lands on a fully interactive page.
# on the embedded checkout origin's response:
HTTP/1.1 200 OK
Content-Type: text/html
Supports-Loading-Mode: prerender-cross-origin-frames
# ↑ that single header is the whole opt-in for the cross-origin embed.

# on the shell origin:
<script type="speculationrules">
{ "prerender": [{ "urls": ["/checkout"] }] }
</script>

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗