Absolutely agree on the geographic angle - we saw the biggest difference with an origin in Singapore. The Cloudflare WAF latency hit was nearly double what we measured from Virginia.
Your TTL/SWR point is crucial. I'd add one caveat: that 2-5 second TTL window can get tricky if your origin's clock is even slightly out of sync with Fastly's. We had a case where a 1-second NTP drift caused edge servers to treat fresh manifests as stale, triggering a thundering herd problem. Now we bake a timestamp into the manifest URL as a cache buster as a safety net.
And yes, we did quantify it. For our European viewers, the rebuffering reduction was about 0.7% during prime time. Not massive, but enough to keep the CFO off our backs about the extra setup cost.
Integration Ian
Disabling rules for static video chunks is a great tip, I wouldn't have thought of that granularity. I'm curious, when you exclude paths like `/chunk-*.ts`, does that create any blind spot you worry about? Like, could a malicious request be crafted to slip through on that path if it's not truly static?
On the `deliver_stale_if_error` question, yes! That's been crucial for us too. We found it's most effective when paired with a fairly long stale-while-revalidate window, especially for the video segments themselves. Lets the origin have a bad moment without the viewer noticing. Have you seen any downsides to leaning on it heavily?
You're putting a lot of faith in path exclusions. I've seen that bite teams when a "static" endpoint gets extended with a query parameter for tracking or reporting, and suddenly you've got a path that's excluded from SQLi rules accepting raw SQL. Your granular tuning becomes a liability.
On `deliver_stale_if_error`, yes, it's useful, but leaning on it heavily just masks origin instability. It treats the symptom, not the disease. If you're relying on stale content so often that it becomes a cornerstone of your design, your origin is the problem. Better to fix that than to build a caching cathedral around a crumbling foundation.
Show me the TCO.
Your split setup adds needless complexity for questionable gain. You're paying for two services to chase milliseconds that most viewers won't perceive.
The Cloudflare latency bump with OWASP rules is predictable. The real question is why you're running a full ruleset on static video chunks at all. That's like putting a guard on a brick. You can safely disable WAF for .ts and .m3u8 paths without opening a hole.
If you're already in Fastly's ecosystem for streaming, adding Cloudflare just for DDoS is overkill. Fastly handles that fine, and you cut out a whole failure point.
Trust but verify.