The same target URL can be fetched speculatively, fully prerendered, activated, cancelled or loaded normally. This lesson tracks the rule set, candidate state, network work, hidden document and final navigation as distinct evidence.
This lesson continues The Gold Standard of Websites, the Gold Standard of Education and the How X Works hub. Every candidate URL, rule and activation log is an original teaching fixture. It demonstrates an evolving web platform feature without promising support or resource savings in every browser.
Keep rule parsing, candidate selection, prefetch response, prerendered document, activation and final user-visible navigation in separate fields. Declaring a target cannot prove that work started or was used.
The WICG prerendering specification patches define speculation-rule prerender processing and activation concepts. The Chrome implementation guide documents practical prefetch and prerender deployment and debugging.
THE GOLD STANDARD · WEBSITES
Prefetch prepares response data; prerender prepares a hidden page for possible activation
A speculation-rule prefetch may fetch a likely next navigation so its response can be reused. Prerender goes further by preparing a hidden navigable and document before the user commits, then activates that prepared page if the eventual navigation is eligible. A candidate can be ignored, cancelled, downgraded or never used, so a rule declaration is not proof of either benefit.
Fast route
Start with the decisive rule.
Start this route
Measurement route
Build the browser evidence ledger.
Start this route
Comparison route
Separate the nearest lookalikes.
Start this route
Transfer route
Change the context and retest.
Start this route
Reporting route
State limits and continue reading.
Start this route
Chapter contents
Open the full chapter index
- 1. Give the short preparation rule
- 2. Parse the rule set
- 3. Separate candidate from execution
- 4. Trace a prefetch
- 5. Trace a prerender
- 6. Detect activation
- 7. Respect URL and navigation matching
- 8. Use eagerness as policy, not guarantee
- 9. Budget resources
- 10. Delay unsafe side effects
- 11. Handle authentication and freshness
- 12. Compare ordinary preload and prefetch
- 13. Debug status and cancellation
- 14. Solve a changed speculation matrix
- 15. Repair speculation shortcuts
- 16. State limits and misconceptions
- 17. Write a reproducible speculation record
- 18. Use authoritative sources and continue the route
1. Give the short preparation rule
Prefetch obtains navigation resources for possible reuse; prerender creates a hidden navigable and document that may later be activated.
Original worked example. /next is prefetched and later navigates using cached response data; /checkout is prerendered and activates a prepared document. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Cancel both candidates before click. The final navigation loads normally. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record action, candidate state, work performed and final use. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
2. Parse the rule set
A script of type speculationrules declares actions, source form, URLs or document rules and optional conditions.
Original worked example. One list rule names /next for prefetch and /checkout for prerender. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Introduce invalid JSON. No candidate is created. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Archive exact rule text and console diagnostics. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
3. Separate candidate from execution
A matching link becomes a candidate, but policy, capacity and implementation may prevent work.
Original worked example. Ten links match a moderate rule; the browser begins only two speculations. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Reduce resource pressure. More candidates start without changing markup. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Track matched, queued, started and cancelled states. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
4. Trace a prefetch
Prefetch can make response data available without constructing the final visible page in advance.
Original worked example. The browser fetches /next and later reuses an eligible response for navigation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Change credentials or cache eligibility. The final navigation refetches. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record request purpose, response, reuse and final request. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
5. Trace a prerender
Prerender creates a hidden document with lifecycle restrictions until activation.
Original worked example. /checkout loads scripts and builds DOM in a prerendering context, then activates after the click. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. The user never clicks. The hidden work is discarded. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Log document state, visibility, prerendering and activation. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
6. Detect activation
Activation is the transition that makes the prepared document the user-visible destination; prerender start alone is not success.
Original worked example. The prepared document records activationStart and becomes visible without a fresh document load. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Navigate with an ineligible target variation. The prerender is not activated. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Capture target URL, prepared identity and activation receipt. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
7. Respect URL and navigation matching
Activation requires the eventual navigation to match the prepared candidate under platform rules.
Original worked example. The candidate is /item?id=7 and the click targets the same URL. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Change the query to id=8. Treat it as a different navigation unless the platform explicitly supports reuse. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Store resolved URLs and redirects. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
8. Use eagerness as policy, not guarantee
Eagerness guides when candidates may begin; it does not promise that work or activation will occur.
Original worked example. A conservative rule waits for stronger user intent before starting. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Set eager under constrained resources. The browser may still limit execution. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record rule and observed start trigger. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
9. Budget resources
Prefetch spends network and cache resources; prerender can also spend CPU, memory and execute page code.
Original worked example. A broad eager prerender rule starts work for pages never visited. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Narrow candidates and upgrade only the most likely target. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Measure unused bytes, CPU and memory where available. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
10. Delay unsafe side effects
Prerendered pages must avoid user-visible or irreversible effects before activation.
Original worked example. Analytics queues a view but commits it only after activation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Send the receipt at prerender start. It counts a page the user never saw. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Separate preparation events from activation receipts. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
11. Handle authentication and freshness
Prepared content can become stale or inappropriate when identity and authorization change before activation.
Original worked example. A signed-in dashboard is prepared, then the account signs out in another tab. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Revalidate on activation and refuse stale privileged state. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record identity, policy version and activation time. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
12. Compare ordinary preload and prefetch
Resource preload for the current page and navigation speculation answer different jobs, even when the word prefetch appears in both ecosystems.
Original worked example. A font preload supports the current document; a speculation prefetch targets a future navigation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Move the resource hint to the wrong page. The intended navigation benefit disappears. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Label current-page resource and future navigation separately. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
13. Debug status and cancellation
Developer tools can show candidate status, rule source, failure reason and whether a prerender was activated.
Original worked example. A candidate is cancelled after the link disappears from a document rule. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Restore the link and observe a new candidate rather than relabelling the cancelled one. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Preserve candidate IDs and transitions. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
14. Solve a changed speculation matrix
Vary action, eagerness, origin, redirect, credentials and final click one at a time.
Original worked example. Six candidates yield prefetched reuse, activated prerender, cancellation, ineligibility and two normal loads. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Hide labels and infer the first failed obligation from evidence. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Require rule, execution, document and navigation fields. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
15. Repair speculation shortcuts
A matching rule is not a fetch, a fetch is not a prerender, a prerender is not an activation, and faster navigation is not proof of which mechanism ran.
Original worked example. A report counts every declared URL as a successful prerender. Repair uses observed status and activation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Add a prefetched-only case with similar speed and distinguish it. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Audit claims by lifecycle stage. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
16. State limits and misconceptions
Speculative loading is optional and evolving; it does not replace caching policy, authorization, side-effect control or ordinary navigation correctness.
Original worked example. A prerendered form submits before activation. Performance intent cannot excuse the side effect. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Gate submission on user action after activation. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Name platform support and application obligations. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
17. Write a reproducible speculation record
A reviewer should reconstruct rules, candidates, resource work, hidden documents and final navigation.
Original worked example. Record S14 stores rule JSON, browser version, candidate transitions, requests and activation evidence. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. A browser update changes support. Append S15 with the same test matrix. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Archive rules, traces and diagnostics. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
18. Use authoritative sources and continue the route
The incubation specification defines evolving prerender mechanics; implementation guidance shows deployment limits. Companion lessons cover ordinary preload, fetch priority and response timing.
Original worked example. Continue through them without merging current-page hints with future navigation preparation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Because support changes, retain exact source dates and browser versions. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Save authoritative URLs and feature-detection results. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Grouped reading routes
Core route
Companion lessons
- Separating First Input Delay from Interaction to Next Paint
- Separating Total Blocking Time from Long Animation Frame Blocking Duration
- Distinguishing a History Traversal from a Back-Forward Cache Restoration
Related specialist lessons
Sources and further study
WICG Prerendering Revamped. Used for the standard definitions, material mechanisms or method limits developed in this lesson.
Chrome speculation-rules implementation guide. Used for the standard definitions, material mechanisms or method limits developed in this lesson.
The worked examples and transfer checks are developed here and state their own assumptions. The linked sources support the underlying browser lifecycle, timing and measurement principles.
Return to contents · Return to The Gold Standard of Websites