Design the First Request After Idle

Performance & Reliability · performance, loading, latency

Updated 2026-08-04

Expect the first request after a quiet period to be much slower than the rest. Serverless platforms scale down when nothing is happening and have to start up again, and that cold start lands on whoever arrives first.
Recognize who pays it. It is disproportionately the new visitor, the user in a timezone where your product is quiet, and the person testing your product for the first time.
Set expectations rather than hiding the wait. A first load that takes several seconds needs a state that explains itself, and every load after it can be silent.
Warm the path before the user asks for it. Starting the work on hover, on focus, or when a wizard reaches the step before the slow one turns a visible wait into an invisible one.
Never let the slow first call block the whole screen. Render everything local, then fill in the part that had to wake up.
Time the states from the slow case, not the fast one. A skeleton tuned to a two hundred millisecond response flashes distractingly, and one tuned to four seconds looks broken at two hundred milliseconds.
Watch the same effect in less obvious places:

Measure the slowest arrivals rather than the average. Averages are dominated by the warm requests and hide the experience that decides whether someone comes back.

The first visitor after a quiet hour gets the worst version of your product, and they are frequently the one deciding whether to use it.