Where the time goes
A recent page at thenodebook.com built by Ishtmeet Singh walks the reader along a single network request, end to end, through all the complicated machinery that sits between a click and its answer. In its example someone in a San Francisco cafe clicks "Buy", and 211 milliseconds later the screen says "Order confirmed".
200ms is worth the read (opens in new tab) for a clear and complete picture of how the internet "just works", with each stage drawn to scale as you scroll.
In those 211 milliseconds the request does everything the modern web does: it looks up a name, opens an encrypted connection, wakes the server, runs a database query, and carries the answer home. By the essay's own accounting, the server's share of that time, every line of code and the database query included, is under 3 milliseconds. Everything else is the signal travelling and waiting: the handshakes that open the connection, and the trips out and home. The computer barely stops to think. Almost the whole wait is motion.
The same distance, measured from Perth
For a business in Perth, it's the same story. The route that the article clocks (San Francisco to Virginia) is about 4,700 kilometres of fibre each way. Perth to Sydney is 4,675. The coast-to-coast American crossing is, to within a rounding error, the distance from our racks to the other side of our own country.
A server in our Perth data centre reaches Sydney in 50.76 milliseconds and Singapore in 51.31, each an average over the past week. Sydney is interstate. Singapore is another country. To the network, they're the same distance.
That cuts against how the choice feels. Sydney feels as local as Singapore feels offshore, and for tax and data-sovereignty questions the difference is real. For the software your staff open every morning it doesn't exist, because the only thing an application feels is the clock, and the clock can't tell Sydney from Singapore.
We're Rackmill, a Perth hosting company. We run our own servers at Equinix PE2 in Shenton Park and colocate other businesses' gear in the same hall, so we have a stake in where your files live.
Most of the delay is speed of light
Light travels slower through glass than through empty space, at roughly two-thirds the speed. Standard single-mode fibre has a group index of refraction of about 1.47, the value Corning, PDF (opens in new tab) lists for the fibre these cables are built from. Divide the speed of light by it and a signal manages roughly 204,000 kilometres a second in the glass, close to five microseconds for every kilometre of cable. That figure is fixed.
Side note: Nobody can sell a shortcut around physics, but fibre technology is changing. Hollow-core fibre carries light through a core of air instead of solid glass, so it runs close to full speed in a vacuum, faster than any glass allows. Microsoft is already running it live in Azure (opens in new tab), carrying real customer traffic across its own network. So far it's going into city data-centre links. The cables we're talking about in this article are still ordinary glass, so the trip to Sydney hasn't changed.
The cable that carries Perth's traffic to the east coast is INDIGO Central. Its operator, Subco, describes it (opens in new tab) as a "4,675km-long cable system" with "~46ms direct connectivity". Those two figures agree with each other. A round trip covers 9,350 kilometres, and at the speed of light in glass that takes 45.8 milliseconds. The advertised 46 is almost all cable, with barely a millisecond left for the equipment along the way.
Our own Perth to Sydney measurement is 50.76 milliseconds. Against the 46 the physics demands, everything a network engineer can actually change, every router, every queue, every switching decision across 9,350 kilometres, comes to about 5. When a provider offers to cut your latency to the east coast, that 5 milliseconds is the whole of what they're selling. The rest is the width of the country, and it's the same for all of us.
Why 50 milliseconds becomes 10 seconds
Fifty milliseconds feels like nothing. Nobody notices it. But everything you do on a network takes many exchanges, and even at 50 ms, it adds up.
In the "200ms" essay, the signal makes six crossings of the country for one request. Business software multiplies that without trying. Opening one file from a Windows share is a back-and-forth of several round trips: the computer checks permissions, reads the file's details, confirms nobody else has it locked, then reads the contents, all before the document appears. Listing a folder asks about every item in it. One screen in an accounting or job-management system can fire hundreds of separate queries at the database, one after another. Remote desktop is the plainest case of all, because every keystroke and every flicker of the screen makes its own trip down the wire. Staff rarely have the words for it. They just say the system feels slow.
Put two hundred round trips on a single screen, one after another, the kind of number a chatty database app reaches on its own. Set the distance against them, and the network waiting alone comes to this:
| Where the server is | One round trip | 200 round trips |
|---|---|---|
| Perth (same city) | 1.38 ms | 0.3 seconds |
| Sydney | 50.76 ms | 10.2 seconds |
| Singapore | 51.31 ms | 10.3 seconds |
| London | 210.68 ms | 42.1 seconds |
Seven-day averages ending 20 July 2026.
These are what stacks up when one task makes that many trips in a row. A single click is one trip, and a file opened across a share only a handful, so lighter work finishes in a fraction of these times. Each trip still waits out the full distance, and on a busy screen they stack in order until the person is just sitting there.
The Sydney row crosses a line. Ten seconds on a single screen. Jakob Nielsen has documented that threshold (opens in new tab) for decades, on research reaching back to 1968: 10 seconds is "the limit for keeping the user's attention focused." Cross it and you've lost them. The same screen on a Perth server answers in a third of a second.
And it repeats every time someone opens that screen. The processor sits idle through all 10 seconds. So do the disks. The machine is waiting for light to cross the country and come back, a wait built into the map and untouched by any upgrade to the hardware. It's the answer to a complaint most IT managers know well: the server benchmarks fast, the vendor swears it's fine, and the staff still say the thing drags.
What caching can and can't fix
There's a fair objection here, and some hosts build their whole pitch on it. Put a website behind a content delivery network and copies of its pages sit close to every visitor, so the distance to the origin server stops mattering. For a public website that's mostly pages which don't change, that works, and it's a good reason not to fuss over where the server sits.
It does nothing for the systems this post is about. A cache can only hand back an answer it already holds. There's no cached copy of a live query against your own data, a file locked for editing, a keystroke in a remote session, or anything a user saves. Every one of those has to reach the real server and come back. The part of a business its staff sit inside all day, the ledger, the client files, the booking screen, is exactly the part a cache can't touch.
How we measured this
We run our own Rackmill monitoring from our Perth site that sends a test signal every five minutes to twenty-four locations around the world. The Australian targets are RIPE Atlas anchors (opens in new tab), measurement boxes run by other organisations on their own networks, so they're not ours to tune. The figures here are seven-day averages.
Two things flatter these numbers. The test starts from our racks, so it skips the first leg your traffic would take, the hop out of your own office. And a test signal isn't real application traffic, which some equipment along the way treats as lower priority. Take the figures as the shape of the thing, not a promise about any one workload.
The unflattering rows belong in the table too. From Perth we measure Tokyo at 151.32 milliseconds, Los Angeles at 179.29, London at 210.68 and New Jersey at 255.66. Brisbane, at 62.18, sits further away in time than Sydney, almost certainly because the path reaches the south-east coast first and then runs north.
Where your server belongs
About 46 of those milliseconds from Perth to the east coast are pure distance, and no provider can shave them off. It's the speed of light over a fixed length of cable, the same whoever you buy from, and your software pays it again on every round trip. The one thing that brings it down is putting the server closer to the people who use it.
A file server the whole office reads across the local network all day is already where it belongs, which is why some servers belong in the office and not in any data centre. The question under all of it is a plain one: where are the people, and how far does the machine sit from them?
Tell us what you run and where your staff work, and we'll give you a straight read on where it should live. When the answer is a rack in Perth, the details are on our colocation page. When it's a machine you'd rather not run yourself, a Perth VPS is the place to start.