Prompt and scope
A news site wants to speed up article-detail navigation with the Speculation Rules API. Explain how you would choose prefetch versus prerender, scope rules, and handle logged-in side effects, freshness, browser fallback, cancellation, and monitoring.
Chrome documents that prefetch primarily fetches resources ahead of time, while prerender loads and renders a page in an invisible context. Prerender can therefore deliver a larger navigation win but may run scripts and trigger side effects earlier. The question tests performance engineering, progressive enhancement, and security boundaries.
What the interviewer evaluates
The candidate should connect strategy to navigation hit rate and side-effect risk; constrain selectors, origin, cache, and privacy; preserve ordinary navigation when the API is unsupported or speculation is cancelled; and prove impact with real-user data rather than a lab score alone.
30-second answer framework
“I would start with conservative prefetch for high-probability, read-only, same-origin article links. I would use prerender only after verifying no write side effects, sufficient hit rate, and a resource budget. Rules would exclude login, payment, personalization, and mutating routes. The server would enforce idempotency and private caching; the client would detect document.prerendering and defer analytics. Unsupported browsers use normal links. I would compare activation rate, LCP, INP, bandwidth, and cancellation rate.”
Step-by-step deep answer
Step 1: Classify navigation risk
Include read-only article and help pages; exclude checkout, logout, likes, payments, and strongly personalized pages. Prerender runs page lifecycle code, so writes must require a real user activation.
Step 2: Choose prefetch or prerender
Use prefetch when hit rate is low or side effects are uncertain. Use prerender for high-probability, same-origin pages with stable first paint and enough CPU and memory budget. Never prerender every link by default.
Step 3: Bound rules and resource cost
Generate document or server rules that match article links only. Limit concurrent candidates and resource size. Set appropriate cache, Vary, and invalidation behavior so private responses are not shared incorrectly.
Step 4: Isolate side effects and login state
Write endpoints must require real interaction and CSRF protection; a speculative request cannot mutate state. Delay analytics, ads, and notifications while document.prerendering is true, then send one deduplicated event after activation. Use private caching or exclude personalized responses.
Step 5: Design fallback and cancellation
Unsupported browsers use ordinary links. Speculation can be cancelled by memory, network, or browser limits, so the page must still load normally. Do not block click feedback while waiting for a speculative page.
Step 6: Handle freshness
For frequently edited articles, shorten cache lifetimes and validate the version at activation; use conditional requests with ETag. If content changed after prerender, refresh mutable regions without flashing stale content or replaying user actions.
Step 7: Measure real-user value
Run a controlled comparison of activation rate, navigation wait, LCP, INP, CLS, bandwidth, CPU, memory, and cancellation. Segment by browser, network, device, and login state. If speed improves while cost or errors rise, narrow rules or return to prefetch.
Trade-offs and boundaries
Hit rate versus resource cost
Low-hit-rate prerender wastes CPU, memory, and bandwidth. Prefetch costs less but offers a smaller win. Set thresholds from observed activation and a defined budget.
Freshness versus instant navigation
Long caching improves hit rate but increases staleness. Version static URLs; validate dynamic content at activation and refresh only mutable regions.
Compatibility versus maintenance
Speculation is a progressive enhancement layer and ordinary links remain canonical. Keep business state transitions independent of the prerender lifecycle.
Failure drills and evolution
A speculative page triggers a write
Log speculative requests in staging and verify that likes, analytics, and notifications have no mutations. Remove the route from rules and move writes behind real activation.
Low hit rate wastes resources
Disable prerender for constrained devices and networks, compare bandwidth and INP, and graduate from a small prefetch experiment to prerender only when the data supports it.
Content expires before activation
Simulate a publication update between prerender and click. Verify ETag validation and partial refresh so the activated page shows the current title and body.
Common mistakes and follow-ups
Mistake 1: Prerender every link
Ask for hit-rate, concurrency, and memory thresholds plus an explicit disable condition.
Mistake 2: Treating prerender as cache
Ask which scripts execute and how analytics and login state are delayed or isolated.
Mistake 3: Looking only at Lighthouse
Ask how activation, cancellation, and bandwidth are segmented in real-user measurement.
Mistake 4: Omitting ordinary navigation
Ask whether a click still works when the browser lacks support or cancels speculation.
Mistake 5: Ignoring freshness
Ask how a publication update between prerender and click avoids stale content.
Extended follow-ups and reference answers
Why not prerender every page?
Prerender consumes extra resources and may execute scripts. Select only high-hit, read-only, same-origin pages within budget.
How do you avoid duplicate analytics?
Detect document.prerendering, defer the event until activation, and deduplicate with a navigation identifier.
How do you prove the optimization works?
Use real-user assignment and compare activation navigation LCP, INP, wait time, bandwidth, and cancellation by device and network.