Why does starting a destination's data request at navigation intent change the perceived wait, and what does that cost?

The fastest navigation is the one whose data was already being fetched before the user committed to it. **Intent** is any signal that a destination is likely: the pointer resting on a link, a link receiving keyboard focus, a row scrolling into the viewport, the pointer going down before it comes up. Each of those precedes the actual navigation by a meaningful interval — often 200-600 ms for a hover, tens of milliseconds even for a press — and that interval is free latency if you spend it on the request. ## What the destination has to do differently Starting early only pays if the destination can render against a result that has not arrived. That requires the framework to have a way for a subtree to say *not ready yet* and for an enclosing boundary to show something in the meantime, plus a shared place where an in-flight request can be found by identity. With both, the sequence becomes: 1. Intent is observed; the request starts and is registered under a key derived from the destination. 2. The navigation commits and the destination renders immediately. 3. The component that needs the data looks it up by the same key, finds the in-flight request, and suspends its own subtree rather than triggering a new request. 4. The response lands and only the waiting region renders. The wait has not been hidden, it has been **moved off the critical path and overlapped with the user's own decision time**. ## The failure that wastes the whole technique If the prefetch writes to a variable that the destination never consults, or is keyed differently from what the destination asks for, the destination starts a second identical request. The screen is exactly as slow as before and the server is doing twice the work. This is why the declaration of the request usually has to be shared — a named, parameterised description that the intent handler and the component both refer to — rather than duplicated at each site. ## Signals and what each is worth | Signal | Lead time | Precision | Good for | |---|---|---|---| | Pointer hover | large | medium | desktop lists, navigation menus | | Keyboard focus | large | medium | keyboard and assistive-technology users, who hover never covers | | Link in viewport | very large | low | short lists where most rows get opened | | Pointer down before release | small | very high | anything: cheap insurance with almost no waste | | Device idle after load | large | low | one or two likely next destinations, not a list | A viewport trigger on an infinite list is the classic over-reach: hundreds of speculative requests for a handful of visits. Hover and focus together are the honest desktop default, and a pointer-down trigger is worth adding everywhere because its waste is near zero. ## What it costs, stated plainly - **Requests for destinations nobody opens.** Server load and the user's data, spent on a guess. Cap concurrency, deduplicate by key, do not prefetch what is expensive to compute, and drop speculation when the connection reports itself as constrained or metered. - **Cache pressure and staleness.** A result fetched at hover may be read a while later or never; something has to decide how long a speculative result stays worth reading. - **Ownership questions.** A request started by an intent handler outlives the element that started it. Who cancels it if the user moves away, and who sees the failure if it rejects before any screen exists? Answer both deliberately — usually: nobody cancels a cheap speculative read, and a speculative failure is swallowed and retried by the real read, so the user never sees an error for a navigation they did not make. - **Code and data must start together.** Prefetching the destination's data while its code still loads on click, or the reverse, just relocates the staircase. A fast navigation needs both speculations fired from the same intent signal. ## Measuring whether it worked Judge it on the interval from the committed navigation to the destination being useful, and on the **hit rate**: what fraction of speculative requests were actually read. A hover prefetch with a 10% hit rate on a long list is a bandwidth tax with a rounding-error benefit; the same trigger on a four-item menu is close to free. Report both numbers when you propose it, because the technique is the rare optimisation that trades someone else's resource for the user's latency, and it should be defended with data rather than intuition.