The most recent development on this topic is a 2026 arXiv preprint on post-quantum certificate chains and time to first byte (TTFB). It notes that CDNs can trim certificate chains and keep several chains per domain for different clients. The preprint does not appear to have been peer-reviewed, and this piece did not review its results, so read it as a sign that researchers are still examining delivery overhead, not as a new measurement. The mechanism behind CDN speed-ups is long established.
How does a CDN reduce page load time? Distance first
A content delivery network keeps copies of a site's files on servers spread across many locations. Cloudflare's learning page describes this as geographically distributed caching, which shortens the distance data has to travel. Fastly puts the key step plainly: when the nearest edge holds a cached copy, it serves that copy without fetching from the origin, which is the site's own server. Cached copies can include HTML, JavaScript, stylesheets, images and video.
A single worked example
DebugBear, a testing vendor, gives one case: a user in Australia may wait for a file from a US server, while a CDN can serve it from Australia. The same article reports one file loading in about 0.1 seconds in both Japan and Canada. That is a single measured example, not general evidence, but it shows the distance effect in concrete terms.
Connection setup: the less visible gain
Distance also affects the connection. Before a page arrives, browser and server negotiate a secure TLS connection, which costs round trips beyond the basic TCP handshake. Terminating TLS at a nearby edge makes each of those round trips cheaper, and keep-alive connections avoid repeating negotiation for every request, according to Imperva's explainer. The principle is well supported. Millisecond savings quoted in vendor articles are illustrative arithmetic, and TLS 1.3 round-trip counts depend on assumptions such as session resumption. Check exact counts against RFC 8446 before quoting them.
Origin offload is a separate effect
A CDN also reduces work at the origin. By answering requests from its cache, it lowers the number of requests and the bandwidth that reach the origin server, as Cloudflare's learning page explains. Akamai has argued that distribution reduces origin load and improves reliability, but that claim reached this piece second-hand through DesignGurus, and no primary Akamai document was retrieved. Offload matters for capacity and resilience. It is not the same as a faster page, so judge the two separately.
Why a CDN-fronted site can still be slow
This is the caveat that matters most. Uncached or personalised HTML still travels to the origin on every view, so time to first byte can stay high after images and stylesheets have moved to the edge. Cloudways, a hosting vendor, describes sites that add a CDN and still wait on the origin for HTML. Google's web.dev guidance on TTFB covers personalised content and short cache lifetimes as reasons the origin keeps getting hit.
Cache misses across edge locations
A cache only helps once something has filled it. When an object is missing or has expired, the edge fetches it from the origin, and that visitor pays the full trip. Later visitors within the cache lifetime are served from the edge, which is why even a short lifetime can help a busy site. An eknix.com post reports that by default each point of presence misses independently, so one expiring object can trigger many origin fetches. An origin shield or tiered caching can reduce that. The mechanism is plausible, but confirm it in your provider's documentation.
How much faster? What the evidence supports
No independent benchmark was found that measures page load reduction across many sites, so no general percentage or seconds figure is given here. The effect depends on how much of the page is cacheable, where users sit, and how far they are from the origin. The most-cited comparison is a 2019 Cloudflare whitepaper, drawing on Cedexis data, which reports Cloudflare faster than competitors by 18% in North America, 23% in Europe and 69% in Asia. That is one vendor's own claim, with methodology not verified here, and it says nothing reliable about CDNs as a category.
The HTTP Archive's 2019 CDN chapter gives a more useful caution: measuring CDN use does not show its impact, and TTFB grouped 'by CDN' misleads without cache effectiveness data. The chapter is dated, so use it for method rather than current numbers.
Dynamic and personalised pages
Personalised content is not cached at the edge by default. Vendor sources say edge configuration can change that, so dynamic pages are not necessarily excluded, but the gain is usually smaller. Origin shield and tiered caching reduce how often the edge goes back to the origin, so ask your provider whether they are available. Speed Kit, a commercial vendor, argues that CDNs are limited to cacheable static content. It sells an alternative, so weigh that view accordingly.
How to check whether your CDN is working
Start with the Server-Timing header. web.dev describes it as a way to see time spent at the edge and at the origin. Cache status headers such as HIT and MISS show whether a response came from the edge's cache. Cloudflare does not cache HTML by default, so an HTML response that always reports MISS may be behaving as designed rather than broken.
Then compare TTFB for a cached request against an uncached one, over several runs from places your visitors actually are. WebPageTest and DebugBear can both do this. This piece did not compare them, so choose whichever you can read clearly.
A CDN is most likely to help where most of the page is cacheable and distance to the origin drives the wait. If the slow number is first-byte time on personalised HTML, a CDN alone will not fix it. Check your cache hit ratio and origin configuration first.