Why is my CDN 'slow' for mobile clients?

By Ilya Grigorik on March 26, 2014

We're using a CDN but when we look at the performance numbers it appears to be far less effective for mobile clients. We're considering disabling it entirely as we're not sure that it's worth it. Someone needs to build a special CDN for mobile, we'd definitely use that to improve latency!

The frequency with which I've been hearing this and similar arguments has been rapidly increasing as more teams are finally focusing on improving performance of their mobile sites. The problem is, while the statement is often based on real data (i.e. the relative performance improvements offered by a CDN are smaller for mobile clients), the conclusion is wrong: the absolute improvements are likely the same for all clients and hence worth every penny. Also, we don't need a "mobile CDN", we need carriers to fix their networks.

The many components of latency

To understand why the relative metrics between desktop and mobile CDN performance are misleading many otherwise well-informed teams, it helps to take a step back and consider the actual topology of the internet, plus what CDNs can and cannot do. In fact, for sake of a concrete example, let's assume the following:

• Client is located on the west coast; server is located on the east coast.
• The propagation latency between west and east US coasts is 50 ms.
• The server response time is 50 ms.
• Last-mile latency for "tethered" clients: ~18 ms for fiber, ~26 ms for cable, ~44 ms for DSL.
• Last-mile latency for "wireless" clients: ~50 ms for 4G, ~200 ms for 3G.

The total time to service the request is a combination of all of the latencies in both directions: last-mile → coast to coast (50 ms) → server response (50 ms) → coast to coast (50 ms) → last-mile. For example, if the client happens to be on a fiber connection with a 18 ms last-mile path, then the total time is 18+50+50+50+18, or 186 milliseconds.

Accelerating content delivery with a CDN

The whole premise of a CDN is to move the bytes as close to the user as possible and to do so CDNs deploy cache servers within various data centers and peering points around the globe. In other words, in the optimal case the CDN servers are located immediately outside the ISP / carrier network: the client makes a request, incurs the cost of last-mile latency to exit the ISP / carrier network and immediately hits a CDN server that returns a response. As a result, CDN minimizes the propagation latency and if a static resource is served, also reduces the server response time by returning a cached asset.

To continue with our earlier example, let's assume that our CDN server is optimally placed (~5 ms path instead of 50 ms coast-to-coast path) and that we are requesting a publicly cacheable asset that can be served by the CDN (~5ms) without hitting the origin. For our fiber client, the new total time is the sum of the last-mile roundtrip plus the CDN response times: 18+5+5+5+18, or 51 ms in total. As a result, adding a CDN took our request time from ~186ms down to ~51ms: a 365% improvement in total latency!

Repeating the same calculation for each connection profile reveals an unfortunate trend: the relative effectiveness of the CDN "declines" as the last-mile latency increases. If you consider the topology of where the CDN servers are typically placed this makes perfect sense: CDN servers are outside the ISP network. That said, note that the absolute latency improvement is still the same regardless of the last-mile profile.

CDNs help minimize propagation and server response times. If your only metric is the relative before and after improvement, then it would appear that a CDN is not doing much for mobile clients - e.g. a mere 33% improvement for 3G clients. In reality, the savings are the same, and the real takeaway is that the last-mile latency of most mobile carriers dominates all other latencies of the resource transfer - yes, a rather sad state of affairs.

Operational and business costs of living at the edge

One obvious strategy to improve the end-to-end latency is to move the cache servers even closer to the client: instead of positioning them outside the ISPs network, could we move them inside? In principle, the answer is yes, and many ISPs already deploy their own cache servers. However, in practice, this is a tricky problem.

First, the number of peering points is relatively small, which allows CDNs to deploy in dozens of well known locations around the globe to provide their service. Also, to do so, they don't have to do any special deals with individual ISPs: typically, the servers are deployed in shared data centers (peering points). By contrast, moving servers into the ISP network would require individual deals with each ISP - not impossible, but obviously a much harder operational and business problem.

For the sake of argument, let's say a CDN does strike a deal with an ISP. Now the CDN needs to deploy many more servers, and ideally as close to their customers as possible (near the radio towers and other aggregation points). Doing so would require a lot of hardware, makes maintenance and upgrades an operations nightmare, and opens a lot of security questions - e.g. would you deploy a TLS termination node within a third-party operated network that you don't have direct access to? In short, it's a cost, security, and a logistics nightmare.

That's not to say this can't be done. Many ISPs have long been trying to move "upmarket" and provide CDN functionality. However, ISPs have a different problem: it's very hard for them to sign clients because most sites are not interested in signing individual deals with every ISP on the planet. In recent news, Verizon acquired EdgeCast... It remains to be seen what they do with it and if this will actually benefit Verizon clients.

Business and operational costs aside, there is nothing particularly special about optimizing CDNs for mobile clients. The root problem is that the last-mile latency of mobile carriers is atrocious - that's what we need to fix. Instead of pushing cache servers closer to the edge, we need transparency into performance of these networks, and we need more competition between carriers to address the underlying last-mile performance problems.

CDNs are not slow for mobile, use them

In short, there is no reason why CDNs are inherently 'slower' for mobile clients: don't confuse relative gains with absolute savings. That said, the actual performance will obviously vary for each CDN provider based on location of their servers and connectivity with various mobile carriers - measure, gather real data, optimize.

Ilya Grigorik is a web ecosystem engineer, author of High Performance Browser Networking (O'Reilly), and Principal Engineer at Shopify — follow on Twitter.