Warmup or preload can move first-hit cost to a moment the user does not feel

What it is

The cover charge does not have to be collected on the spot. Warmup and preload move handshake, split download and cache fill into a gap before the person has issued that action: while a boot animation plays, while the previous page is still being read, while the cursor rests on a button. The first-hit cost is still there; the bill is moved from “after I pressed” to “before I asked”. The first attempt the person feels is already close to steady state.

Transfer works when the gap is truly idle and the next step was guessed right. Guess wrong and the spend is traffic and battery on a path nobody wanted — that cost lives with prefetch. This leaf is only about the moment of transfer.

Why it happens

The perceptual clock starts when intent is issued. Work before that, if it does not steal frames from the current interaction, does not enter the wait experience. Splash, reading pauses, hover, scroll deceleration are windows where intent has not yet been issued. Stuffing cold work into those windows removes the objective slowness of first response from the user’s wait budget.

Windows have a length cap. A splash stretched to cover warmup turns the cover itself into a wait. Hover warmup that fires inside 100 ms will launch a pile of cold requests on accidental hovers. So transfer is not “the earlier the better”. It is “where intent is already likely, and waiting has not started”.

Where it stops holding

Privacy-sensitive data must not preload because “they might look next”. On metered networks and low battery the gap is no longer free. Warmup that steals the main thread makes the current page’s scrolling heavy: the in-flight experience pays for a first hit that has not happened. Branches the user will not take (permission already denied, feature closed for this role) are pure waste to warm.

Applying it

• Warm the most likely next module after boot, once the first screen is interactive. Do not cover it with a longer splash.
• Idle preconnect or prefetch high-probability next steps (the first list item, the obvious primary). Skip low-probability entries.
• Warmup must yield: once the user starts scrolling or typing, drop its priority or cancel it.
• How to check: after a cold start, do not tap the target immediately; wait two seconds, then tap. Duration should approach steady state. The control is tapping immediately after cold start. If both are equally slow, warmup did not finish in the gap, or never ran.

Related

• Same group: I1.07.1 The first response carries extra init cost and is usually slower than steady state · I1.07.2 Patience is higher for the first action than for later repeats · I1.07.4 A large first–steady gap makes users misjudge overall performance
• Nearby: I2.04 Prefetch and preload · I1.04 Input latency and tracking
• Search terms: warmup · preload · speculative connection