Nothing about a stream matters if viewers leave before it starts, and they do: abandonment climbs steeply with every second of spinner. Time-to-first-frame is not one delay but a chain of sequential steps — page, player, manifest, manifest again, init segment, first media segments, decode — and because they are sequential, every link you shorten moves the whole number. Here is the chain, and the checklist for attacking it in order of payoff.
What actually happens before the first frame
Walk one cold playback in a waterfall and you will see something like: the page loads and initializes the player (often the biggest single cost, and nothing to do with the CDN); the player fetches the master manifest, parses it, then fetches a media playlist; then the init segment for the chosen rung; then enough media segments to satisfy its startup buffer; then decode and render. On a typical unoptimized setup that is five to eight sequential round trips after player init — and if any of them misses cache and travels to a distant origin, one link can cost more than all the others combined. So the first task is measurement with attribution: capture the waterfall on real devices and label each step, because teams routinely optimize segments while the actual time sits in player boot or a redirecting manifest URL.
Shorten the chain: requests you can delete
The cheapest milliseconds are requests that stop existing. Redirects before the manifest — geo bouncers, token issuers that 302 to the real URL — each cost a full round trip; replace them with edge logic that serves the manifest directly. If your platform generates per-session manifests at request time, make sure generation is at the edge or fast and close, not a two-hundred-millisecond origin round trip on the critical path. Inline what can be inlined: startup metadata the player would otherwise fetch separately can ride in the page. And let the browser start early: preconnect to the media hostname from the page head, and preload the master manifest so it is in flight while the player script still parses — the same mechanics as Early Hints and preload, applied to video’s chain.
Connections: TLS, protocols and one hostname
Each new hostname on the startup path costs DNS, TCP or QUIC, and TLS before its first byte moves. Keep manifests, init and segments on one hostname so a single warmed connection carries the whole chain, and serve it over HTTP/3 or HTTP/2 so the player’s parallel segment fetches multiplex instead of queueing — verification that H3 is actually serving, not just enabled, is its own guide. This is also where the CDN’s geography earns its keep: TTFB on the manifest chain is dominated by distance when the edge serves it, and by origin distance when it misses — which previews section five’s point about keeping the head of every title cached.
The starting rung and the player’s appetite
Two player-side settings routinely dominate everything delivery can do. The starting bitrate: a player that begins on a top rung must download large segments before showing anything; starting one or two rungs down and switching up after a segment or two trades a moment of softer picture for a much faster first frame, and viewers reliably prefer it. The startup buffer: players default to buffering two or three segments before play — with six-second segments that is a mandatory multi-second wait regardless of network. Shorter segments shrink that floor (one reason two-second segments help startup even outside low-latency contexts), and most players expose the startup buffer target directly. Tune both against your rebuffer numbers rather than in isolation — startup and stability pull on the same rope, and the other end of it is covered in fighting rebuffering.
Keep the head hot, and measure like a viewer
Delivery’s remaining contribution is making the startup chain’s objects — manifests, init segments, the first few segments of each rung — the most reliably cached bytes in the estate. For VOD, treat title heads as a warming target on premieres; for live, the newest objects are hot by construction and your manifest TTL does the work. Watch hit ratio specifically on manifest and init paths, not blended into segment traffic where the tail hides problems. Then measure the result the only way that counts: time-to-first-frame from real devices via your player’s beacon into RUM, segmented by device, network and title — setup in deploying RUM — with the waterfall from section one re-captured after each change. Teams that run this checklist typically move startup from several seconds to close to one; past that point you are trading against picture quality, and that is a product decision, not a delivery defect.