The comparison matters more than any single number. A Sydney load time on its own can’t tell you whether the page is heavy, the server is slow, or the request is crossing the Pacific several times before the first byte arrives. A second measurement taken with the same Test Profile from a different location helps narrow down those causes.
Why Australian visitors feel distance more than most
Some websites that serve Australian audiences are hosted elsewhere, including the US East or West Coast, Europe, or Singapore. From Sydney, every one of those origins is far away.
Light in optical fiber travels at roughly 200 km per millisecond. That sets a hard minimum on round-trip time (RTT) before any routing, queuing or server work is added. The figures below are those theoretical floors, calculated from great-circle distance. They are not Latixo measurements. Real routes are generally longer than a straight line, so measured RTTs are usually higher.
| From Sydney to | Approx. distance | Theoretical minimum RTT |
|---|---|---|
| Auckland | 2,200 km | ~22 ms |
| Perth | 3,300 km | ~33 ms |
| Singapore | 6,300 km | ~63 ms |
| Tokyo | 7,800 km | ~78 ms |
| Seattle | 12,500 km | ~125 ms |
| Northern Virginia | 15,700 km | ~157 ms |
| Nuremberg | 16,300 km | ~163 ms |
Approximate great-circle distances and idealised two-way light-propagation floors in fibre (~200 km/ms); not measured Latixo RTTs.
One round trip is not the problem. Several are. On a cold connection, a browser may need DNS resolution, a TCP handshake, a TLS handshake and then the HTTP request before the first byte of HTML can arrive; caching and connection reuse can change that sequence. With an origin in Virginia, those round trips can add up to several hundred milliseconds of waiting before the server’s own processing time is counted. A third-party origin may require its own DNS and connection setup unless the browser can reuse or coalesce an existing connection. HTTP/3 and TLS 1.3 can reduce connection-establishment round trips compared with older handshakes. They cannot shorten the distance. The HTTP/2 vs HTTP/3 guide covers that trade-off in more detail, and Why Website Speed Varies by Location explains the general mechanics.
What a Sydney test represents, and what it doesn’t
Before comparing anything, it helps to be clear about what the Sydney measurement stands for.
It is one location in a very large country. Perth is substantially farther from Sydney than Auckland is. A Sydney result is a reasonable proxy for visitors on the east coast. It is a weaker proxy for Western Australia and the Northern Territory, and it does not represent New Zealand. If your CDN or hosting has a node in Perth, a Sydney test will not exercise it.
The Desktop profile uses the node’s own network. Desktop tests run at 1366 × 768 with native CPU and the Browser Node’s native data-centre connection. That makes it easier to investigate regional delivery differences without adding mobile throttling. It does not reproduce a household NBN connection or a mobile carrier network.
The Mobile profile is a fixed emulation. Mobile tests use a 390 × 844 viewport at DPR 3, a 4× CPU slowdown, and throttling to 1.6 Mbps down, 750 Kbps up with 150 ms latency. Because these limits are fixed and identical at every location, the Mobile profile is good for answering “how does this page cope with a constrained connection and a slower CPU?” It is a blunter tool for isolating route distance, because the profile’s own constraints can dominate the result. To measure distance alone, compare Desktop runs.
It is a lab measurement. One controlled browser load is useful for diagnosis. It is not a substitute for field data from real Australian users. The Latixo score is Latixo’s own heuristic, not a Lighthouse score or a Core Web Vitals assessment.
Choose the comparison that answers your question
Different pairs of tests isolate different causes. Choose the pair that matches the question you are asking.
| Report A (baseline) | Report B (comparison) | What the pair helps investigate |
|---|---|---|
| Location nearest your origin (for example Virginia or Seattle) | Sydney, same device | Effects of region, routing and edge/origin placement |
| Sydney, before a change | Sydney, after a change | Whether a change is associated with faster Sydney results |
| Singapore | Sydney | How Singapore and Sydney delivery paths differ |
| Sydney, Desktop | Sydney, Mobile | How much the constrained Mobile profile slows the same page |
| Sydney, run 1 | Sydney, run 2 | Run-to-run noise, which you need before trusting any other difference |
The last row is easy to skip and shouldn’t be. If two Sydney runs a few minutes apart differ by a similar amount to your Sydney-vs-Virginia gap, the gap is not yet evidence of anything.
Running an Australia comparison on Latixo
- Fix the exact URL. Use the final page URL, not a short link or an avoidable redirect. When two reports have a different submitted or final URL, the comparison view flags it, because the two runs may not have loaded the same document.
- Run the baseline. On the Latixo speed test, select the location closest to where your site is hosted and choose Desktop or Mobile. Each IP address can have only one queued or running test at a time, so run tests one after another.
- Run Sydney with the same device profile. Select Sydney, Australia, and keep the same device setting as the baseline.
- Repeat the Sydney run once or twice. The first request through a CDN may be a cache miss at the Sydney-area edge. A second run can show whether the measured delivery has become meaningfully faster. That difference is useful in its own right.
- Open the comparison. From your browser’s local test history, or by entering two saved report IDs or links, open the side-by-side comparison. Set the baseline as A and Sydney as B. Deltas are shown as B minus A.
- Read the condition warnings first. For a cross-region comparison, “Browser Node / location differs” is expected, because that is the variable you are testing. A warning that the device, test type or Test Profile differs means the comparison is mixing two variables. Re-run before drawing conclusions.
The comparison reads stored results and does not re-measure anything. By default, report metrics and screenshots are retained for 365 days and Loading Replay for 7 days. If you compare against an older baseline, the metrics may still be available after its replay has expired.
Reading the gap: what each pattern usually means
The comparison shows available timing, transfer-size, request and score metrics for both reports, alongside screenshots and replays where retained. The patterns below are interpretations, not automatic diagnoses. Treat them as hypotheses to check in the request list.
TTFB is much higher from Sydney, and everything after it shifts by a similar amount
This pattern is consistent with a longer path to the answering origin or edge, provided the two runs loaded comparable content. The rest of the page may simply start later. Options include caching HTML at a CDN edge with Australian locations, moving or replicating the origin closer (Sydney or Singapore), removing unnecessary redirect chains (redirects add requests and may also require new connections), and enabling HTTP/3 where your stack supports it. For context on which TTFB values are reasonable, see What Is a Good TTFB?
TTFB is similar, but DOMContentLoaded or load is much slower from Sydney
The HTML is reaching Australia quickly, perhaps from an edge cache, but some of the resources it pulls in may not be. Look for scripts, fonts and images served from origins without nearby edges: analytics, chat widgets, review apps, tag managers, or an uncached asset bucket. A new resource origin may need its own connection setup, unless connection reuse or coalescing applies. Large unoptimised images make this worse. Large images are often the easiest part to fix.
Failed requests appear only in the Sydney report
This often points to something region-specific rather than slow, such as a third-party service that blocks or redirects Australian traffic, a consent tool that loads a different flow, or an asset restricted by geography. Check which hosts failed.
The screenshots look different
Region-aware sites may serve Australian visitors a different storefront, currency, banner or locale redirect. If the final URL differs between the two reports, the comparison can warn you, and you may be comparing different page variants rather than one page from two places. Decide which version you actually want to measure and test it directly.
Sydney is close to the baseline even though the origin is overseas
This may mean a CDN is serving cached HTML near Sydney, or that the delivery path is efficient. It is encouraging, but timing alone does not prove a cache hit. Confirm it holds on repeated runs, and remember that uncached pages such as carts, search results and logged-in views will not get the same benefit.
Shopify stores selling into Australia
For a Shopify storefront, the Shopify Speed Test can run from Sydney as well. It classifies the resources observed in that load as Shopify platform, theme or third-party, and highlights the largest and slowest ones. This is useful when an app’s script is the part that travels badly. When both reports come from Shopify analysis, additional main-document DNS, Connect and TLS timings may be available where captured.
What Sydney lab tests won’t settle
Some questions need other evidence:
- Real-user Core Web Vitals in Australia. Lab runs don’t produce field data. Use field sources such as the Chrome UX Report or Search Console for that, and use Latixo to investigate the causes. The LCP guide explains how lab and field views of loading relate.
- Performance in Perth, regional Australia or New Zealand. These would need test locations there, or real-user monitoring.
- Specific carriers and home connections. The Desktop profile uses a data-centre network, and the Mobile profile is a fixed emulation, not a physical phone on a carrier network.
- Long-term trends. A pair of reports is a snapshot. Repeat the comparison after meaningful changes rather than relying on one before-and-after pair forever.
The methodology page documents the test environment and its limits, and Website Speed Test Metrics explains what each timing value measures.
Start with two runs
Run your page from Sydney, run it again from the location closest to your origin, and open the two reports side by side. If the gap is mostly TTFB, investigate where your content is served from and how requests reach it. If the gap opens up after the first byte, look at which resources are crossing the ocean.