Design Prefetching Around User Intent

Performance & Reliability · performance, navigation, loading

Updated 2026-07-28

Use the gap between intent and action. A user hovers, focuses, or starts pressing a link a few hundred milliseconds before they commit, which is enough time to have the next screen ready.
Escalate the signal rather than guessing early:

Prefetch the data as well as the code. Arriving instantly at an empty screen that then spins has moved the wait, not removed it.
Respect the connection and the device. Skip speculative loading on slow networks, on metered connections, and when the user has asked for reduced data usage.
Never let a prefetch have side effects. Speculative requests must be safe to repeat and safe to throw away, so they cannot mark things as read, consume quota, or write analytics.
Budget it. Prefetching every visible link on a dense index page can cost more bandwidth than the page itself and slow down what the user actually asked for.
Cache what you fetched so the real navigation uses it. A prefetch that gets refetched on click is pure waste.
Measure the hit rate. If most prefetches are never used, the trigger is firing too early and you are spending users' data on guesses.

The fastest screen is the one that was already loading while the user was still deciding.