[cj]

> If you’re okay with every request having the latency all the way to your origin, you can have the CDN revalidate its cache on every request.

It's also worth mentioning that even when revalidating on every request (or not caching at all), routing through a CDN can still improve overall latency because the TLS can be terminated at a local origin server, significantly shortening the TLS handshake.

[spondyl]

Ah, the TLS shortening aspect of a CDN is something that seems obvious in hindsight but I'd never really thought about it. Thanks!

[hinkley]

Some of the HTTP/2 and HTTP3 design choices are seen as trying to solve this problem another way.

If a round trip to New York is too long, then twenty of them is way worse. So I can either do 20 round trips to Nevada, which does <20 round trips to Chicago, which does <<20 round trips to New York. Or, I can do some more cleverness with transport and session bootstrapping and end up with 14 round trips to New York.

[dilyevsky]

Not just tls but generally tcp will slowstart faster on lower rtt connection (and edge can keep origin connection always open so it stays “warm”)

[champtar]

Also CDN providers will hopefully have good pearing. My company uses OpenVPN TCP on port 443 for maximum compatibility. When around the globe the VPN is pretty slow, so I proxy the tcp connection via a cheap VPS, and speed goes from maybe 500kbit/s to 10Mbit/s, just because the VPS provider pearing is way better than my company "business internet". (The VPS is in the same country as the VPN server).