Delivery network latency in 2026: measured from a Russian server

On 27 August 2026 we measured the path from our server (Moscow, Selectel network) to eighteen public addresses. Five attempts each; the table shows the best. Time to first byte is broken into its parts:

Russian addresses answer in 40–72 ms, foreign ones in 65–133. So the difference between a domestic and an international delivery network, seen from Moscow, is a few tens of milliseconds rather than a multiple.

The breakdown shows why: the TLS handshake fits in 15–27 ms for everyone, and connection setup in 0–20. The network path from Moscow to Cloudflare, Google and CloudFront nodes is short — these networks keep points of presence in or near the region, and traffic does not cross an ocean to reach them.

What this means for a site owner: choosing between a Russian and an international delivery network is not a choice between fast and slow. Thirty to sixty milliseconds on the first byte is visible in a measurement and near-invisible to a person. Decide on other grounds — support availability, payment methods, data residency requirements.

The one component where the spread is real is DNS: 15–21 ms for everyone, 67 for Akamai. That is a third of its total, and it is where its resolution visibly travels further than the rest.

Azure at 1,264 ms — and it is not the network. We repeated the measurement four times in succession: 2.2, 2.3, 3.2 and 3.3 seconds. Meanwhile DNS takes 28–68 ms, connection 67–100, the TLS handshake 152–170. We reach the server faster than most others, and it then thinks for two to three seconds before returning a redirect. The problem is in the application, not the link.

That distinction generalises: if TLS is fast and the first byte is slow, the link is not at fault — look at the server. We described the same technique in our response-time breakdown: the gap between ping and HTTP on one host separates network from application.

aws.amazon.com does not answer at all — code 000 on every attempt. Yet neighbouring addresses from the same provider work fine: d1.awsstatic.com returns its first byte in 73 ms, docs.aws.amazon.com in 124.

We could not establish the cause, and will not invent one. We tested the IPv6 hypothesis — the address publishes AAAA records and our server has no IPv6 — but a forced IPv4 request fails too. So that is not it. Of our fourteen addresses carrying AAAA records the other thirteen work without complaint, meaning the fallback to IPv4 generally behaves correctly.

• One vantage point. Everything was measured from a Moscow server on the Selectel network. From Novosibirsk or Yekaterinburg the ordering would differ, and no general ranking of delivery networks follows from these numbers.
• Time to first byte includes the server thinking. Azure demonstrates it: a fast link and the worst figure in the table. Separating those requires the breakdown, not the total.
• The best of five attempts is taken. That is deliberate — it removes noise from one-off stalls — but it means the table shows achievable time rather than typical time.
• Different addresses return different things. Some return a redirect, some a refusal, some a full page. That does not affect path measurement, but response sizes must not be compared.

To measure the path to your own server, use the route trace; for the response time breakdown, the header check.