Measured in your browserWe advise on speed. We practice it.Loaded just now · real numbers from this visit, not a lab score.
Page loaded
First byte
DOM ready
First paint
Largest paint
DNS lookup
TLS handshake
Transferred
Saved by compression
Requests

Video is the one workload where multi-CDN can transcend DNS entirely: because a stream is thousands of independently fetched segments, the player itself can choose a platform per session, per failure, even per segment — switching mid-stream in milliseconds with the viewer none the wiser. That power comes in three tiers of ambition, from simple retry insurance to measurement-driven selection, and the good news is they stack: each tier is the foundation of the next.

Why video multi-CDN is a different game

Web failover moves future page loads; video switching moves the current experience, because the player makes a fresh HTTP request every few seconds and each one is a routing opportunity. That grants three abilities DNS steering lacks: mid-session failover (a platform dies, the next segment comes from the other one, the buffer absorbs the blink), per-network optimization at the individual-viewer level rather than per-resolver, and instant reaction speed with no TTL tail. It also relocates the machinery: the switching logic lives in the player and the manifest layer, shipped and versioned like application code — the trade dissected in steering vs client switching. Most estates still keep DNS-level splitting underneath for non-video traffic and as the coarse layer; the tiers below are what video adds on top.

The groundwork: identical objects on every platform

Every tier depends on one property: the same segment, at the same path, retrievable from every platform — so the player can substitute hostnames freely. That means all CDNs pull from one origin (a shared, egress-friendly store is the natural fit — see zero-egress origins), packaging is single-sourced (one packager output, never per-CDN packaging, or segment names and timing drift apart), and the delivery-affecting configuration is in parity: token schemes validating identically on both edges (the bit-level compatibility work from security parity — for video this is the item that bites first), CORS headers matching, range behaviour matching. Verify with the two-platform diff: fetch the same segment through each CDN explicitly and compare bytes, headers that matter, and token acceptance. Only when that diff is boring is the player allowed to start choosing.

Tier 1: failover retries in the player

The entry tier costs an afternoon and removes the scariest failure mode: configure the player with an ordered list of base URLs (one per CDN), and on a failed or timed-out segment fetch, retry the same segment from the next platform before surfacing any error. Modern players support this natively or via a request-interceptor hook, and done right the viewer experiences a platform outage as nothing — the buffer covers one slow segment while the retry lands. Two tuning notes: set the failover timeout meaningfully below the buffer depth (a three-second timeout under a ten-second buffer switches invisibly; equal values stall first, switch second), and make the demotion sticky for the session — after N failures, prefer the healthy platform for subsequent segments rather than re-trying the sick one each time. This tier alone converts multi-CDN video from “failover in minutes via DNS” to “failover in one segment,” and every estate running two CDNs for video should have it regardless of ambitions above.

Tier 2: content steering, the standardized middle

The middle tier moves the choice server-side without losing per-session granularity: content steering, now standardized in both major formats (HLS’s second-edition spec defines EXT-X-CONTENT-STEERING with pathway IDs; DASH has its equivalent steering manifest), lets your manifests advertise multiple delivery pathways and point players at a small steering server that returns, per session and refreshed on an interval, the current pathway priority order. You get central control — shift the fleet’s preference in near-real-time, no player release, no DNS wait — while retaining tier 1’s client-side failure handling underneath. Implementation notes from the field: the steering server is tiny but availability-critical, so make its failure mode “players keep their last order” (which the specs support) and host it off both CDNs; player support is present in the mainstream open players and improving across devices, so verify your actual device fleet rather than assuming; and treat steering decisions as another config artifact with history, because “why did APAC move to platform B at 14:00” deserves an answer in a log.

Tier 3: measurement-driven selection, and choosing

The top tier closes the loop: feed the steering decisions (tier 2) or the player’s own choice logic (tier 1’s hooks, upgraded) with measured performance — per-session throughput and segment latency the player already knows, aggregated into per-ASN-per-CDN QoE via your QoE pipeline — so each network cohort streams from whichever platform currently serves it best, with damping and minimum-sample rules to prevent flapping (the same statistical hygiene as RUM-driven steering, applied at the video layer). This is the tier where multi-CDN becomes a measurable QoE feature — broadcasters running marquee events live here — and also where complexity earns real scrutiny: you now operate a control system, and control systems need dashboards, damping and drills. Choosing your tier: everyone builds the groundwork and tier 1; build tier 2 when you need fleet-level control without player releases (live events, commercial rebalancing); build tier 3 when QoE is competitive and your measurement is already trustworthy. And rehearse the composite — kill a platform during a test stream and watch the tiers catch it — before the event night does the test for you.

Get the free assessmentMore analysis