People pick a host on bandwidth numbers and then measure the result with ping. Both numbers say less than they appear to. A 10 Gbps port does nothing for a page that takes two seconds to start rendering, and a 5 ms ping says nothing about the three quarters of the load time that happens after the ping ends. This is a plain walkthrough of where the milliseconds actually go, so you can look at a hosting proposal and predict how it will feel to a visitor in Birmingham or Glasgow.
Round trip time, or RTT, is the time for a packet to reach the server and come back. The physics is fixed: light in fibre travels at roughly 200,000 kilometres per second, so the floor is about one millisecond per hundred kilometres of fibre each way, plus the switching equipment along the path. Within the UK, that puts a London server at roughly 5 to 12 ms RTT for a visitor in Manchester, Bristol or Edinburgh. From London to New York the figure is about 80 ms. From London to the Gulf, around 90 to 110 ms. No amount of hardware on either end changes those floors.
Ping is a useful sanity check and a poor buying metric, because a page load is not one round trip. It is a stack of them: DNS resolution, the TCP handshake, the TLS handshake, then the server thinking, then the browser fetching dozens of assets, most of which can only start after earlier ones arrive.
Before a single byte of your HTML moves, the connection has to be built. A cold HTTPS fetch over TLS 1.3 costs roughly two round trips: one for TCP, one for the key exchange, before the request even goes out. On a domestic London connection with 8 ms RTT that is about 16 ms, invisible. On a Dubai visitor hitting a UK-only server at 95 ms, the same sequence is nearly 200 ms before your application has done anything. Over a day of navigation, that tax repeats every time a connection is not reused.
Three things shrink it: keeping the server close to the audience, keeping TLS session tickets alive so repeat connections resume in one round trip, and HTTP/2 or HTTP/3 so the browser stops paying one round trip per asset. Any host that answers your quote request with the HTTP version and TLS session resumption enabled by default is telling you they have thought about this. One that cannot tell you their TLS version has not.
Time to first byte is DNS plus handshakes plus server processing. It is the number that most closely matches how "fast" a site feels, because a browser can render nothing until the first byte of HTML lands. Chrome's own user experience dataset buckets TTFB as good under 800 ms and poor over 1,800 ms, but that is grading the whole web. For a well-run UK site on a London server, a cached page should return its first byte in well under 50 ms, and a dynamic page with a couple of database queries under 200 ms.
The server-processing half of that number is where the host matters more than the distance. It decomposes into: the web server accepting and routing the request, the application doing its work, and the storage answering. A cache hit on a static file costs single-digit milliseconds. A cold application with four uncached database queries on busy SATA disks can cost hundreds. That is why we write so much about matching disk characteristics to workload, as in our piece on IOPS, throughput and latency: the storage layer is where the host's hardware spend turns into your visitors' waiting time.
If you are evaluating two hosts, do not benchmark with ping. Do this instead:
For a UK-facing site, a single-digit RTT is the cheap win that no tuning replaces. Every handshake, every redirect, every uncached asset fetch, every database connection setup over a misconfigured proxy: all of them pay the distance tax again. Reduce the RTT from 90 ms to 8 ms and every one of those steps gets twelve times cheaper, before you touch a single line of application code. A London region also keeps personal data in-country for the customers who ask about that, which comes up more in UK procurement than it used to.
There is a converse, and honesty demands it: if your audience is global, no single location fixes latency, and the answer is caching at the edge rather than pretending one datacentre is universal. For a UK business serving UK customers, though, a well-cached site on a London server is within a few milliseconds of what any global network can deliver here, without the extra moving parts.
The reliability half of the same decision, what an SLA does and does not compensate you for, is covered in our SLA writeup. And if you want a London node sized to your actual workload and measured properly before you commit, mail admin@servercabin.com with what you run and we will pull real numbers for your stack rather than a generic benchmark.