A short-video platform finds that video startup time, not playback quality, is the strongest predictor of engagement. Which network-level optimisations matter most?

Why startup time dominates

In a feed of short videos, the user's decision to keep watching happens in the first moments. A delay before the first frame is a delay before any value is delivered, and it recurs on every video — so a 200-millisecond improvement compounds across dozens of videos per session in a way that a bitrate improvement never does.

This inverts the usual video optimisation priority. For long-form video, sustained quality dominates. For short-form, startup dominates, and the architecture should reflect that.

The optimisations that matter

1. Prefetch the next videos. The single largest win. While the current video plays, fetch the opening segments of the next few in the feed. Startup latency becomes zero because the data is already local. This is a product-and-network decision jointly: it trades the user's bandwidth and the platform's delivery cost against engagement, and the trade needs an explicit policy — how many videos ahead, how much of each, and what to do on a metered connection.

2. Eliminate handshakes from the critical path. A cold connection costs a DNS lookup, a TCP handshake and a TLS handshake before any data moves — several round trips, which on a mobile network is close to a second. Connection reuse, connection pre-warming and a transport that combines transport and cryptographic handshakes remove most of this. Zero-round-trip resumption removes it almost entirely for returning users.

3. Start with a low-bitrate segment and adapt upward. The first segment should be small enough to arrive almost immediately. Quality ramps within the first seconds, by which time the user is watching. Optimising the first segment for size rather than quality is counter-intuitive and correct.

4. Edge presence close to users. No protocol trick beats reducing the physical round trip. For a globally distributed audience, this is the foundation everything else builds on.

5. Aggressive edge caching of popular content, with predictive warming for content the recommendation system knows is about to be widely distributed. The platform has an unusual advantage here: it decides what becomes popular, so it can warm caches before the demand it is about to create.

The measurement discipline

Measure time to first frame at the client, segmented by network type, region, device class and whether the content was prefetched. Server-side latency is nearly irrelevant to this metric — most of the time is in the network and the client, and a backend dashboard showing healthy response times will happily coexist with a terrible user experience.

The architectural insight

The dominant optimisation is not making the request faster; it is not making the request at the moment it is needed. Prefetching converts a latency problem into a bandwidth and prediction problem, both of which are far easier to solve — and the prediction is something a recommendation system already produces.

That reframing — spend a cheap resource in advance to eliminate an expensive wait — is the general pattern, and it applies well beyond video.