Speed Week: Chasing the Waitless Internet
The Internet is full of waiting: waiting for a page to load, waiting for a video to buffer, waiting for an app to sync. Building an experience that eliminates that wait requires more than the bandwidth numbers that dominate ISP advertising. A truly fast Internet depends on three things: ample bandwidth, content and applications located close to the end user, and software optimized to run as quickly as possible. This week, we'll look at the layers involved in those three pillars—DNS, latency, reliability, caching, cryptography, and more—and how our global network works to reduce the numbers involved.
The Need for Speed of Sight
When you type a website name into a browser, the first operation is a DNS lookup, translating the domain name into an IP address. If this step is slow, nothing else can proceed. The resolver you use—whether from your ISP or a public one like Google's 8.8.8.8—is the first chance for delay. Cloudflare's public resolver, 1.1.1.1, is designed to be the world's fastest, and it's available for anyone to use.
How fast is "fast"? Human perception is a useful benchmark. Research indicates the eye can make sense of an image in as little as 13 milliseconds. High-quality video at 60 frames per second displays a new image every 16 milliseconds. This means web interactions need to be measured in tens of milliseconds, not seconds, to avoid visible delays.
DNS and the Speed of Light
1.1.1.1's speed comes from two principles: caching and proximity. Caching stores copies of data that haven't changed, allowing the resolver to answer instantly without asking an authoritative server. This is standard practice for all good resolvers, but it's not the whole story. When the cache is empty, the resolver must query an authoritative DNS server—like the one Cloudflare runs—to get the correct IP address. The speed of those authoritative servers also matters.
The bigger challenge is the physical world. The speed of light, while fast in absolute terms, is a fundamental bottleneck for Internet traffic that must travel in round trips between users and servers. A quick calculation illustrates the problem: with fiber optic Internet and a DNS resolver 100 kilometers away, the round trip alone consumes a millisecond at the theoretical maximum speed of light in fiber. Over longer distances and less direct paths, those milliseconds add up.
The solution is to move DNS resolvers closer to users. Cloudflare's network today spans 250 cities worldwide, and it's not just about geographic spread. Being "close" also requires interconnecting with multiple ISPs and transit networks, so that end users are always near a point of presence. This is why the network isn't just distributed; it's also one of the most interconnected in the world.
Beyond DNS: Handshakes and Encryption
Once the browser has the IP address, it must connect to the web server. This almost always uses TCP, a protocol that starts with a three-way handshake. This means one round trip at the speed of light, which again argues for having the server close to the end user.
But a connection isn't enough; it must be secure, so the browser and server need to establish a TLS session. This requires at least two more round trips for the cryptographic handshake, along with the server proving its identity. Having fast, secure DNS via protocols like DoH and DoT is also built on TLS, putting even more pressure on its speed. The answer to this is a combination of having servers near users and running highly optimized encryption software that supports the latest standards, like TLS 1.3, along with techniques like session resumption and 0-RTT resumption. By this point, four round trips have occurred—one for DNS, one for TCP, and two for TLS—before the browser has even requested a single byte of page content.
Congestion and the Shape of the Network
There are also two failure modes that slow down the Internet from a user's perspective: congestion and packet loss. The Internet is a shared network, so congestion control algorithms are designed to be fair and prevent any single user from overwhelming it. When packets are lost, it's a signal that this control is needed.
To give users the fastest, fairest experience, Cloudflare stays on top of congestion control algorithms like BBR. We also actively route around network weather using technologies like Argo and our private fiber backbone, which can send connections over dedicated fiber optical links to avoid paths experiencing packet loss.
Retrieving the Page: Protocols and Content
Finally, the browser sends a GET / request. The web server responds with HTML, but the complexity doesn't end there. It arises from two places: the HTTP protocol itself and the nature of modern web content.
HTTP/2 and HTTP/3 offer significant speed benefits through parallel request handling, better compression, and improved congestion management. Cloudflare Radar shows where these protocols stand globally.
The other factor is content. Before the browser finishes parsing HTML, it could start downloading images and other assets if it knew about them. Servers can address this by sending hints about required resources alongside the HTML. Images themselves are also a prime target for optimization. They are often large, and there is a vast variety of end-user devices with different screen sizes and format support. What's needed is an integrated way to deliver the correct format (like WebP or AVIF), size, and compression to each device without relying on a chain of slow, separate services.
Using the Cache
Caching is a powerful tool for DNS and for content too. Keeping copies of content on servers close to end users is a big part of a fast website. But populating and maintaining cache memories across thousands of servers worldwide presents a problem: the more servers, the harder it becomes to keep cache content fresh and ready.
Some providers respond to this by limiting their presence to fewer cities to make cache management easier. That approach comes at the cost of user latency in many parts of the world. Cloudflare's approach is different: using smart software for global load balancing aims to solve the challenge of keeping many caches full, thereby achieving high "cache hit ratios," low latency, and lower load on customer origin servers.
Zeroing in on Zero Milliseconds
The ultimate speed is zero milliseconds. When we launched Cloudflare Workers in 2017, it provided a serverless platform at the edge. Over the years, it's grown to support multiple languages, a distributed key-value store, Durable Objects, WebSockets, and Cron Triggers. A common concern with serverless platforms is cold start times, but last year we announced that we have the capability to eliminate those entirely.
A large global network still requires reliable measurement. Because third-party testing tools can be biased or lack clear methodology, we've built our own for like-for-like comparison to ensure we're seeing real performance across the Internet's many networks. Our focus is also on keeping all operations fast—from configuration updates and code deploys to log processing and cache purges.
Welcome to Speed Week.



