Why Perth Businesses Lose 50ms by Hosting on the East Coast (and What That Costs You)

If your customers are in Perth and your origin server is in Sydney, every request your visitors make pays a tax of roughly 40 to 50 milliseconds in round-trip time. That number is not marketing — it falls out of the physics of moving light through 3,300 kilometres of optical fibre and back. This post unpacks where the latency comes from, what users actually feel, and why hosting Perth-facing services on Perth-local infrastructure is the simplest performance win available to most WA-based businesses.

The physics: why Perth-to-Sydney is at least 33 ms

Network latency is, before anything else, a constraint set by the speed of light. In vacuum, light travels 299,792,458 metres per second by international definition. That figure has been fixed since 1983 — it is not engineering, it is geometry.

Inside an optical fibre, light moves slower because the glass has a refractive index of roughly 1.5. The effective speed of a signal in long-haul telecom fibre is therefore about 200,000 kilometres per second — two-thirds of the vacuum number. That two-thirds penalty is built into every fibre-optic link on the planet.

Perth and Sydney are roughly 3,300 km apart on a great-circle path. Real fibre routes are not straight lines — Australia's major terrestrial fibre runs follow the coast and railway corridors — so the actual cable distance is longer, but 3,300 km is a defensible floor. At 200,000 km/s, one-way photon travel is about 16.5 ms. A round-trip doubles that to about 33 ms. That is the absolute physical minimum: photon goes east, photon comes back, no routers in the path, no queueing, no processing.

Real-world Perth-to-Sydney RTTs sit closer to 45 to 60 ms once you add router hops, layer-2 switching, ISP peering, queueing under load, and the fact that fibre runs are not perfectly straight. You can confirm the rough order of magnitude with any traceroute or with the public country-level metrics on Cloudflare Radar.

Now contrast that with a Perth-to-Perth route. The origin and the visitor are both inside the Perth metro area, separated by maybe 10 to 20 km of fibre and a handful of hops. The same physics gives a theoretical floor of well under one millisecond and observed round-trip times that comfortably sit under 10 ms.

What 50 ms actually costs a browser

A modern HTTPS page load is not a single round trip. It is a sequence of them, and most of them are serialised — the browser cannot start the next step until the previous one has come back. The headline ones for a fresh visit:

• One RTT for the TCP three-way handshake.
• Roughly two RTTs for the TLS handshake (TLS 1.3 is faster than older versions; QUIC saves more, but only if the client and origin both speak it).
• One RTT for the HTTP request and the first byte of the HTML response.
• Further RTTs for every external asset (CSS, JS, fonts, images) that the page needs before it can render.

For a Perth visitor hitting a Sydney-hosted site, three to four serial RTTs of 50 ms each is 150 to 200 ms before the first byte arrives. The same visitor on a Perth-hosted origin pays 24 to 32 ms for the same handshakes. The savings compound as the page pulls in additional assets, and they show up directly in the metrics Google uses to score real-user experience.

Google's own performance guides — see web.dev on Largest Contentful Paint — treat Time to First Byte and server response time as primary inputs into LCP, the metric that most directly tracks “how fast does this page feel”. TTFB is bounded below by network RTT. Cut the RTT, you cut the TTFB; cut the TTFB, your LCP score goes up; your LCP score going up is what shows up in Search Console and Core Web Vitals reports.

Use cases where the difference is operationally real

Mining-sector telemetry

Operational telemetry from sites across the Pilbara and Goldfields typically lands somewhere in Perth before being processed, batched, and shipped upstream. If that “somewhere in Perth” is actually a Sydney cloud region, every batch crosses 3,300 km of fibre twice — once to be ingested, once to acknowledge. Most pipelines tolerate this, but anything with a real-time loop (anomaly detection on a control system, alarm correlation, automated remediation) pays the latency tax on every cycle. Putting the ingest and processing tier in Perth-metro removes that round-trip without changing any application code.

Professional services with a Perth-based team

Law firms, engineering consultancies, accountancy practices, design studios — anyone with a WA-based team using a shared web application all day — accumulates the latency tax across thousands of interactions. Every document save, every dashboard load, every search query, every form submission. None of those individual round-trips are slow enough to complain about, but the cumulative drag on a working day is real. It also shows up in user-perceived “snappiness”, which is a soft factor that nonetheless changes how staff feel about the tools they use.

WordPress sites serving WA visitors

WordPress in particular is RTT-sensitive because admin actions are uncached, plugin update checks chatter back to the origin, and many themes pull in multiple external requests per page view. A Perth-hosted WordPress site loads visibly faster for Perth visitors than the same site hosted in Sydney — not because the server is faster, but because the photons have a shorter way to go. Our managed WordPress hosting exists for exactly that reason.

The sovereignty angle (related, but separate)

Latency is the easy story to tell. The harder one is jurisdiction. East-coast hyperscaler regions are operated by US-headquartered companies. Even when the bits sit in a Sydney data centre, the parent company is subject to US law — including, notably, the CLOUD Act, which can compel disclosure of customer data held overseas. For workloads covered by the Australian Privacy Principles, or where contractual obligations require Australian jurisdiction over the data, that exposure can be a problem.

An Australian-owned operator with an ABN, running hardware physically in Australia, does not have that exposure. It is not a magic fix — you still need the contractual and operational hygiene to back it up — but it removes a class of jurisdictional risk from the threat model. We've written more about the company itself on the about page.

The bottom line

If your visitors are in WA, putting your origin in Perth gives you four things at once:

• Round-trip times in the single-digit milliseconds instead of 45 to 60.
• TTFB and LCP improvements that flow straight into Core Web Vitals scores.
• Australian legal jurisdiction over customer data.
• The option to bring your own hardware if managed hosting is not the right fit — see colocation in Perth.

None of this requires changing your application, your CMS, or your codebase. It is a hosting-layer change. The physics has been the same since 1983; the only variable you control is where you put the server.