Last Mile

The last mile is the final leg of a network into a user. It is the copper, coaxial, fibre or radio link between a service provider and the customer's premises. The classic examples are "the copper wire subscriber lines connecting landline telephones to the local telephone exchange; coaxial cable service drops carrying cable television signals from utility poles to subscribers' homes, and cell towers linking local cell phones to the cellular network" (Wikipedia, Last mile). It is not the middle mile or the backbone. Those are high-capacity trunks that a CDN can buy, peer over and route around. The access link, by contrast, belongs to the subscriber's ISP. A CDN cannot widen it, re-route it or repair it.

Two qualifications matter. First, the "mile" is a metaphor: "the length of the last mile link may be more or less than a mile". Second, where the last mile ends depends on what sits in front of the origin. Cloudflare's current documentation defines it as "the path from a user to the first point of ingress to the resource, whether that be a network like Cloudflare or directly to the origin server" (Cloudflare, Network Error Logging). So once a site is behind a CDN, the last mile runs from the user to the nearest point of presence. It does not run to the origin. Here is the helicopter view. The last mile is the segment with the least bandwidth and the most sharing. It is the segment you do not control. It is the segment your server logs cannot see. Everything a CDN does about it reduces to two levers: send fewer bytes across it, and spend less time on it.

How it works

Retail networks are trees. The last mile "is typically the speed bottleneck in communication networks; its bandwidth effectively limits the amount of data that can be delivered to the customer". That is because those networks have "the topology of 'trees', with relatively few high capacity 'trunk' communication channels branching out to feed many final mile 'twigs'" (Wikipedia). The twigs are also "the most numerous and thus the most expensive part of the system, as well as having to interface with a wide variety of user equipment". That makes them "the most difficult to upgrade to new technology". This is the economic reason the tail of the network lags the core, even where fibre to the premises has become "the deployed medium of choice".

• The medium is physical and often shared. Cable plant is the clearest case. Such systems "are by nature shared systems and the spectrum available for reverse information flow and achievable S/N are limited". These limits "set an upper limit on per-user information capacity, particularly when many users share a common section of cable or access network" (Wikipedia). That limited reverse spectrum is the mechanism behind the asymmetry of most consumer access links. A radio sector is shared in the same way.
• Direction is ambiguous, so say which end you mean. "Because the last mile of a network to the user is conversely the first mile from the user's premises to the outside world when the user is sending data, the term first mile is also alternatively used" (Wikipedia). Cloudflare uses "First Mile" for the opposite end of the path. In that usage, "the First Mile tends to represent the path from an origin server to the data that you are requesting" (Cloudflare, Unboxing the Last Mile). So the same phrase names the user's uplink in one usage and the origin's own data fetch in the other.
• Queues, not just capacity, set the latency. "One major source of delay is the buildup of queues in network devices. Queueing occurs whenever the arrival rate of data at the ingress to a device exceeds the current egress rate" (RFC 7567, section 1.2). The access link is usually the lowest-egress-rate hop on the path. So that is where that queue forms and where jitter is generated. Active queue management such as FQ-CoDel exists as "a powerful tool for fighting bufferbloat and reducing latency" (RFC 8290). But it runs in the ISP's equipment and the home gateway. It never runs in the CDN.
• Loss on the last mile is ambiguous too. "Since the most common cause of packet loss is congestion, TCP treats packet loss as an indication of potential Internet congestion along the path between TCP end hosts" (RFC 3819, section 8.4). On a radio link, a share of loss is corruption rather than congestion. A loss-based sender still backs off anyway. This is one of the gaps BBR targets. Relative to loss-based algorithms such as Reno or CUBIC, it "offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers" (draft-ietf-ccwg-bbr-05, an Internet-Draft, not yet an RFC).
• Physics sets a floor. "Physical distance from where servers are matters a great deal, because nobody can outrun the speed of light" (Cloudflare). Some access technologies have a floor no edge placement can lower: "the very long paths of geostationary satellites cause information latency that makes many real-time applications unfeasible" (Wikipedia).

Why it matters for a CDN

A CDN owns everything up to its own edge and nothing after it. The part it does not own is the part the user actually feels. Cloudflare states the division plainly. An unhealthy access network is "something Cloudflare can't control". Cloudflare adds that "the only thing Cloudflare can do to mitigate performance problems like these is to limit how much time you spend on these networks" (Cloudflare).

• Edge proximity is the one structural lever. "Getting close to end users is important for one reason: it minimizes the time spent on the Last Mile. These networks can be unreliable and slow." Concretely, "by placing data centers close to our users, we reduce the amount of time spent on these Last Mile networks, and the latency between end users and Cloudflare goes down" (Cloudflare). Shortening the leg you control is the only way to shrink the share of the total spent on the leg you do not.
• Network health can dominate distance. "A healthy network has no downtime, minimal congestion, and low packet loss." Cloudflare published one measurement in 2021, comparing three ISPs in the same country with similar user distribution. In that comparison, "the latencies to Cloudflare for ISP C are 360% higher than ISPs A or B" because ISP C's network quality was worse (Cloudflare). That is one measured example, not a general ratio. But it shows the size of the effect an ISP's own condition can have on numbers a CDN gets blamed for.
• The distribution is what you serve, not the mean. "The tail for Last Mile latencies is very long" (Cloudflare). A page that is comfortable on fibre can be unusable on a congested cell sector. A single average hides the users who are actually failing.
• It bounds what tuning can achieve. No cache configuration, anycast footprint or origin optimisation removes an access link's capacity ceiling or its queue. Once the edge is close, the remaining wins come from putting less on the wire.

What CDNs do

The levers are largely the same at every vendor. That is because none of them can widen the physical link. What differs is whether the vendor exposes any visibility into it.

• Compress the response. "Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type" (RFC 9110, section 8.4). Brotli is registered as the br content coding (IANA HTTP Content Coding Registry). It is defined as "a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods" (RFC 7932), while gzip remains the universal fallback.
• Multiplex, with the transport caveat. HTTP/2 gains "a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection" (RFC 9113). But on a lossy access link, a single TCP connection is a liability. Here is why: "because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet" (RFC 9114, section 1.1). HTTP/3 avoids that, because QUIC provides "reliable, in-order, per-stream delivery" (RFC 9114, section 1.2).
• Adapt the bitrate. Adaptive bitrate streaming exists for exactly this link. HLS "is designed for reliability and dynamically adapts to network conditions by optimizing playback for the available speed of wired and wireless connections". It supports "multiple alternate streams at different bit rates". It offers "intelligent switching of streams in response to network bandwidth changes" (Apple, HTTP Live Streaming).
• Report failures from the browser. Network Error Logging is "a browser-based reporting system that allows users' browsers to report connection failures to an endpoint specified by the webpage that failed to load" (Cloudflare). The CDN, not the origin, sets the policy header on its responses. The browser then posts reports naming the failure phase and type. Cloudflare surfaces the result as Edge Reachability. It is documented as "last mile insights for Enterprise customers" (Cloudflare, Types of analytics), and it is reached under Analytics & Logs > Edge Reachability. It reports "why a request failed", "the country a request failed from", "the last mile network a request failed from" and "the Cloudflare data center the request was most likely meant for" (Cloudflare, View Reports).
• Nothing stops you doing it yourself. The reporting mechanism is an open specification, not a vendor feature: "many services can operate their own reporting endpoints and set their own headers indicating that users who connect to their site should upload these reports to the endpoint they specify" (Cloudflare). Where another CDN does not document a last-mile product, treat that as not documented rather than as evidence the data is unobtainable.

Watch out for

• The failures you most want are missing from your logs. Network errors on the last mile "cannot be detected purely server-side, since by definition the client might not have been able to successfully establish a connection with the server" (W3C, Network Error Logging). If the user never reaches the edge, no edge or origin log line is ever written. A last-mile outage then looks like a small dip in traffic rather than an incident.
• Browser reporting is not a census. NEL is a W3C Working Draft, published 5 May 2025. It says it is "inappropriate to cite this document as other than work in progress" (W3C). Support is Chromium-only. MDN's compatibility data records the NEL response header in Chrome from version 71, and no support in Firefox or Safari (MDN, NEL). Counts from NEL undercount your Safari and Firefox users entirely.
• Attribute latency before you optimise it. The tree topology makes the access link the bandwidth and reliability bottleneck. But the latency a user measures is the sum of two things: the queue in that link, and the distance to the ingress point. Only the second of those moves when you add edge locations. Measure both before concluding which one you are fighting.
• Uploads contend on the same link. The access link is usually asymmetric. So a user pushing video, backups or a conference call saturates the narrow return direction. Page loads on that connection then slow down for a reason that has nothing to do with your throughput at the edge.
• The last hop is often inside the building. Wi-Fi from the router to the device is its own miniature last mile. On a shared LAN, "the decrease in information capacity made available to an individual user is roughly proportional to the number of users sharing" it (Wikipedia). Plenty of reports of a "slow site" are one congested radio in a house.
• Last-mile visibility is plan-gated, not universal. Cloudflare's Edge Reachability is documented for Enterprise customers only (Cloudflare). Do not design an incident process around a view your plan does not include.

Best practice

• Measure from the users' own networks. Data-centre probes ride healthy peering and never see the failing tail. Pair real-user monitoring with browser-reported network errors so both slow sessions and failed connections are visible. Set acceptance thresholds on high percentiles, because "the tail for Last Mile latencies is very long" (Cloudflare).
• Spend the byte budget deliberately. Serve br or gzip on everything compressible, right-size and re-encode images, and cut payload before tuning anything else. Bytes are the one variable you fully control on a link you do not.
• Prefer HTTP/3 for mobile and lossy populations. The per-stream recovery in QUIC is precisely the property that matters where packets are lost for reasons other than congestion (RFC 9114, section 1.1). Keep HTTP/2 available for clients and networks that cannot use it.
• Shorten the leg you own. Put capacity in the markets your audience is in. Let anycast keep users on the nearest site, since minimising time on the access network is the documented reason for proximity (Cloudflare).
• Give video a low bottom rung. An adaptive ladder is only as good as its lowest rendition. If the worst-served sector cannot sustain the lowest variant, the stream stalls. This holds regardless of how good the top of the ladder is.
• Treat the worst realistic access link as the acceptance line. Test on a throttled, lossy, high-latency profile as a matter of course. Then the fibre desktop is the easy case, not the only case you have measured.