Running an Australian website from the other side of the world

Australia is a long way from where most web infrastructure lives, and from where a lot of web agencies live. That distance shows up in two specific places, and both are fixable once you know to look.

The first is physics, and it is measurable

Every request from a browser in Sydney to a server in Virginia crosses the Pacific and comes back. That round trip takes somewhere around 200 milliseconds before the server has done any work at all.

One round trip is tolerable. The problem is that loading a page is never one round trip. There is a DNS lookup, a connection, a TLS handshake, the HTML, then whatever the HTML asks for. Each is another crossing. Two hundred milliseconds becomes a second and a half of pure waiting, before anyone has rendered anything.

You can measure this yourself. Test your site from a Sydney or Melbourne test location and compare it with a US one. If the gap is large, distance is your problem rather than your code.

What actually fixes it

A CDN, which is the big one. A content delivery network keeps copies of your files in Sydney and serves them from there. For a site whose pages do not change per visitor, this removes almost the entire distance penalty. It is usually a configuration change rather than a migration, and it is the highest value hour of work available to most Australian sites.

Hosting in the region, if the site is dynamic. If pages are generated per request, against a database, a CDN helps less because the page has to be built somewhere. Then the server itself should be in Australia or nearby Asia Pacific.

Fewer round trips. Every third party script is another set of connections to another server, possibly also overseas. Distance multiplies the cost of script bloat, which is why an Australian site feels the weight of a chat widget and three analytics tools more than an American one does.

We cover the measurement side in performance and Core Web Vitals.

The second distance problem is support

This one is less discussed and often more expensive.

If your site goes down at 9am Tuesday in Brisbane and your developer is in London, that is 11pm Monday for them. You are not getting an answer until their morning, which is your Tuesday evening. A problem that would have taken twenty minutes to fix costs you a trading day.

This is worth deciding deliberately rather than discovering during an outage. There are three workable answers.

• Local support. Simplest, and usually the most expensive per hour.
• Overlapping hours. Plenty of the world overlaps with an Australian working day. A team in Asia, or one that deliberately staffs early or late, can cover most of your business hours.
• Agreed response windows. Whoever you use, agree in writing what happens for something urgent, and test it once before you need it. An arrangement nobody has ever exercised is a hope rather than a plan.

What does not work is assuming it will be fine. It is fine right up until the one morning it is not.

Where to host, in practice

For a marketing site, a brochure site, or anything largely static, a CDN in front of hosting anywhere reasonable will give you excellent performance in Australia. Where the origin server physically sits matters much less than people assume.

For a store, a booking system or anything with logged in users and live data, put the origin in the region. The database round trips are the expensive part and a CDN cannot cache those.

For email, keep it separate from your website hosting regardless. Bundling them means a website problem becomes an email problem, which turns an inconvenience into a crisis.

The thing worth testing today

Run your homepage through a speed test with the location set to Sydney. Then run it again from the United States. If the Australian number is much worse, you have found a problem that a day of configuration will largely solve, and that your customers have been paying for silently.

See how we work with Australian businesses, or send us your URL and we will run both tests for you.