Video startup time
Video startup time is the wait between a viewer asking for playback and the first frame appearing on screen. It covers fetching the manifest, which lists the available renditions, any DRM license request, downloading the first segments and decoding the first frame. Many teams also track the time to load the page and initialize the player, because viewers feel those waits too. Startup time is the first quality signal in every view: viewers who wait too long leave before anything plays.
How is video startup time measured?
The clock starts when playback is requested: a tap on play, or an autoplay attempt. It stops when the first frame is rendered, which most players report as a playing event. That interval is video startup time.
It is rarely the whole wait. Before playback can be requested, the page has to load and the player has to initialize, which means downloading and running the player script and setting up the media pipeline. Measuring those as separate stages, and adding them into a total startup time, shows which team owns the delay: web, player or video delivery.
Two outcomes need their own counters. A view where the viewer pressed play and left before the first frame is an exit before video start. A view that never started because of an error is a startup failure. Neither has a startup time, so averaging only successful starts can make a bad experience look fine.
What is a good video startup time?
Research on 6.7 million viewers found that people start abandoning a video if it has not begun within two seconds, and that more leave with every extra second. Two seconds is therefore a useful upper bound for on-demand playback, and many services aim lower.
The right target depends on how viewers arrive. In a vertical feed, the next clip has to appear as the swipe ends, so the target is close to instant and the player usually prepares the next item in advance. A viewer who chose a film from a catalog will tolerate slightly more. Live streams often start a little slower because the player must find the live edge.
Whatever the target, track the slow tail, not only the median. The slowest tenth of views is where devices, regions and networks with real problems show up, and it is usually where viewers give up.
What causes slow video startup time?
Every request before the first frame adds a round trip. A typical HLS start loads the multivariant playlist, then a media playlist, then the first segment, each possibly from a new hostname that needs its own DNS lookup and TLS handshake. On a mobile network each of those steps can take noticeable time.
The first segment itself is often the largest cost. If the player opens on a high rendition, or segments are long, it must download several megabytes before it can show anything. Protected content adds a DRM license request before decoding can start.
Other delays sit outside video delivery: a heavy player script that loads late, a page that renders the player only after everything else, or a player created only when the viewer taps play. New uploads add one more case. If playback has to wait for the full encode, the first viewers wait minutes, not seconds.
How do you reduce video startup time?
Shorten the path to the first frame. Start on a lower rendition and let ABR climb once the buffer has some video in it. Keep segments short, or use a shorter first segment. Serve manifests and segments from the same CDN hostname, and preconnect to it from the page so DNS and TLS are done before the tap.
Prepare work in advance where the product allows it. In feeds, initialize the player and fetch the first segment of the next item while the current one plays. For protected content, request the DRM license as early as the flow permits.
On the delivery side, keep cache hit ratios high so first segments come from the edge rather than the origin. Then measure each stage separately, by device, region and DRM type, and fix the largest one first. The largest stage is often outside the video, in the page or the player script.
How does FastPix handle video startup time?
FastPix measures startup in stages. Video Data reports page load time, player initialization time and video startup time for every view, and adds them into total startup time, so the slowest stage is visible. Exits before video start and video startup failures are flagged with their error code and context, and startup breaks down by device, country, CDN, ASN and DRM type. Each view gets a startup score of 8 divided by 8 plus the startup seconds, so a 2 second start scores 0.8. It carries 0.275 of the QoE score.
The player works on the same clock. On the Android SDK, built on Media3, fast start is on by default: playback begins after 500 ms of buffered media instead of Media3's stock 1000 ms, and a feed-tuned profile starts at 250 ms. Preloading prepares upcoming playlist entries, pre-caching warms items before a player exists, disk caching plays scroll-backs from local storage, and pre-rendering prepares the next entry up to its first frame, so swiping never shows a black frame (preload and cache). A player pool keeps players ready for reels and carousels (video feeds). The web, iOS and Flutter SDKs share one playback ID.
On the delivery side, each upload gets a per-title ladder with a light rendition to start on, segments are served across 300+ points of presence with per-viewer routing, and just-in-time encoding lets new uploads play before the full encode finishes.
Startup measurement is part of Video Data, free for the first 100,000 plays every month. The video bills on usage: Standard encoding free up to 4K, storage per rendition-minute and streaming per minute watched. No card is needed to start.
By the numbers
- A study of 6.7 million unique viewers found that viewers begin to abandon a video if it does not start within two seconds, and each additional second of delay raised abandonment by roughly 5.8 percent. (EurekAlert!: UMass Amherst and Akamai study of video quality and viewer behavior (2012))
