Website Speed Test from Sydney, Australia – Real Chrome Test

Latixo’s Sydney Browser Node opens your public URL in a real Chromium browser running in Sydney. It returns Time to First Byte (TTFB), total load time, page weight, request count, a screenshot and a Loading Replay from that run.

Sydney is one of eight live Latixo test locations. The others are Virginia, Seattle, Nuremberg, Tokyo, Singapore, São Paulo and Beijing. You can test from Sydney with the Desktop profile or the simulated Mobile profile, and the same location is available in the Shopify Speed Test.

Why does a site that is fast elsewhere slow down in Australia?

Australia is a long way from where much of the web is hosted. Many sites run on a single origin server in the United States or Europe, on a shared host or VPS, or on a cloud region chosen years ago for reasons that had nothing to do with Australian visitors. When a browser in Sydney requests one of those pages from a distant origin, each required round trip has to cover a long route.

A CDN can shorten that distance, but only for traffic that actually reaches an Australian edge and finds the content already cached there. When a request misses the cache, isn’t cached at all, or bypasses the CDN entirely, the long path comes back.

The distance floor, worked through

Light in optical fibre travels at roughly 200,000 km per second, about two-thirds of its speed in a vacuum. That sets a minimum round-trip time no amount of optimisation can remove. The figures below are calculations from approximate great-circle distances, not Latixo measurements. Real cable routes are longer than straight lines, and routers add their own delay, so measured round trips are higher.

Distance alone is only part of the cost, because a new HTTPS connection can take several round trips before any HTML arrives. On HTTP/1.1 or HTTP/2 over a fresh TCP connection using a full TLS 1.3 handshake, one round trip typically establishes TCP, another negotiates TLS, and a further round trip carries the request and first response. That is about three round trips before counting additional server work or DNS resolution. With a distant origin in Virginia, the physics floor for those three trips alone is close to half a second. A full TLS 1.2 handshake can add another round trip. HTTP/3 combines transport and TLS setup, potentially reducing the connection-establishment cost. Connection reuse, session resumption and other optimisations change the picture. The HTTP/2 vs HTTP/3 guide covers that trade-off in more detail.

This is why a TTFB that looks acceptable from a test near your origin can look poor from Sydney even when nothing on the server has changed.

What happens when you test from the Sydney node?

The test runs on a Browser Node physically located in Sydney. The result is not a local run with an artificial location label or an added delay. Chromium starts in a fresh, isolated browser context for each job, with service workers blocked. The browser therefore behaves like a first-time visitor, without previously populated page storage or cached files in that context.

Then the page loads the way a browser loads it. HTML is parsed, stylesheets and fonts are fetched, JavaScript runs, and third-party requests fire. A third-party hostname may need its own DNS lookup and connection, depending on caching and connection reuse. If your analytics, chat widget or font provider responds from outside Australia, that cost is part of the run as well.

Two Test Profiles are available:

• Desktop1366 × 768 viewport, DPR 1, using the node’s native CPU and network.
• Mobile390 × 844 viewport, DPR 3, with a fixed 4× CPU slowdown and network limits of 1.6 Mbps down / 750 Kbps up / 150 ms latency.

The two profiles run under deliberately different conditions. Compare Desktop with Desktop and Mobile with Mobile.

What the report shows, and what it doesn’t

A Sydney run returns the same result fields as every other Latixo location:

• TTFB, measured from the start of navigation to Chromium’s responseStart
• Total load time, based on the browser’s load event
• Page weight from transferred bytes observed during the run
• Request count
• HTTP status, negotiated protocol and content type for the main document
• A WebP screenshot and a WebM Loading Replay when capture succeeds
• The Latixo performance grade and recommendation checks based on the run

The standard result does not list DNS, TCP or TLS timing as separate rows, and it does not report FCP, LCP or CLS. Those connection phases still happen and can contribute to TTFB when a new connection is needed, but they cannot be read off individually. The performance grade is Latixo’s own heuristic. It is not a Lighthouse score, a PageSpeed Insights score or a Core Web Vitals assessment. The methodology page and the speed test metrics reference explain how each value is captured.

Which location should you compare Sydney with?

A single Sydney number is hard to interpret on its own. It becomes more useful next to a run from somewhere closer to your infrastructure. Use the same URL and the same profile for both runs.

If Sydney and your origin-region location produce similar TTFB across repeated runs, distance isn’t the main problem in those tests. If Sydney stays consistently higher, look at where the response is coming from before you start tuning the application.

How to read a slow Sydney result

High TTFB in Sydney, normal TTFB near the origin. This points to distance, routing or edge coverage rather than server code. Check whether the HTML document is served through a CDN at all. Many setups cache images and scripts at the edge while every HTML request still goes back to the origin. For a sense of what counts as high, see What Is a Good TTFB?

High TTFB everywhere. Look at the backend first: uncached page generation, slow database queries, redirect chains or an overloaded host. A slow response from the origin is slow from every location, and distance adds to it.

Fast first run, then a slow one, or the reverse. CDN cache state can differ between runs. Where a site gets relatively little Australian traffic, the local edge may hold fewer cached objects than edges in busier regions, so cache misses can be more common. Before treating a result as a stable regional effect, run the test more than once.

Reasonable TTFB but long total load time. The delay happens after the document begins arriving. Heavy images, render-blocking CSS and JavaScript, web fonts and third-party scripts are the usual causes. On long routes, each additional hostname can make them more expensive. The Loading Replay shows what the screen looked like while this happened. See also how large images slow a website down and the LCP guide.

For the general reasons speed changes with location, beyond Australia specifically, see Why Website Speed Varies by Location.

What a Sydney test can’t tell you

A Sydney run describes one controlled page load from one data-centre network at one point in time. It is good evidence for diagnosis and for checking a change right after deployment. It does not stand in for all Australian traffic:

• Sydney is not Perth, and it is not New Zealand. Perth is roughly 3,300 km from Sydney, and Auckland is across the Tasman Sea. Visitors there may reach different edges or take different routes.
• It is not a home or mobile connection. The node sits on a data-centre network. Residential broadband and mobile networks add last-mile latency and variability that the Desktop profile does not reproduce. The Mobile profile applies fixed throttling but is still a lab simulation.
• It is lab data, not field data. Real-user data, such as the Chrome User Experience Report, aggregates many visits across many devices. Use it alongside Latixo results, not as a replacement for them.