What we did — and what this is not
On 19 August 2026 we requested the homepage of every .au domain in the
Tranco top-1 million list
published 17 August 2026 (list ID K9L5W) —
8,376 of them — and recorded how the response arrived.
6,421 answered and are the basis for every figure below.
This is not a Lighthouse report and these are not Core Web Vitals. The tool on our homepage runs Lighthouse through Google's PageSpeed Insights API, which takes ten to thirty seconds per URL — covering eight thousand domains that way would take most of a day. The Chrome UX Report API, which would have given real-user vitals in one call per origin, is not enabled for our key. So this report measures what can be measured directly, completely and for free: delivery. Time to first byte, compression, protocol, weight, redirects and caching. Those are causes rather than symptoms — every one of them happens before a Core Web Vital can be measured, and every one is something a site owner can change. For a full Lighthouse score of a single page, use the tool on the homepage.
Time to first byte
How long from starting the request to the first byte of HTML arriving — DNS, connection, TLS and the server's own thinking time combined. Everything else waits behind it.
Median 480 ms, 75th percentile 924 ms, 90th percentile 1,588 ms. Measured from a connection in Australia, so this is roughly what a local visitor experiences.
Compression
HTML is text, and text compresses extremely well. Serving it uncompressed is one of the few genuinely free wins left in web performance — it is a server setting, not a rebuild.
521 homepages (8.1%) sent their HTML with no compression, 40.0 MB in total. Compressed at the median ratio we measured across the sites that do compress (84% smaller), that same HTML would have been about 33.5 MB lighter — on the homepage alone, on a single visit each. Enabling gzip is one directive in nginx or Apache.
HTTP version
HTTP/2 removed the need to hoard connections and inline everything; HTTP/3 removes head-of-line blocking on lossy links, which matters on mobile.
How heavy is the HTML itself
This is the HTML document only — no images, CSS, fonts or JavaScript. A megabyte of markup before a single asset is a sign of a page assembling itself server-side and shipping the result whole.
Median 202 KB, 90th percentile 789 KB.
Redirects before the page appears
Each redirect is another round trip before any content arrives — and the apex domain is where
they cluster, because example.com.au so often has to become
www.example.com.au.
Response headers
Does a CDN actually help?
Splitting the population by whether the response carried CDN headers.
| Delivery | Domains | Median TTFB | Compressed | HTTP/2 or 3 |
|---|---|---|---|---|
| Behind a CDN | 4,145 | 525 ms | 96.7% | 99.0% |
| Direct from origin | 2,276 | 329 ms | 83.0% | 77.9% |
That result is the wrong way round from what you would expect, and it is worth being careful about. Sites behind a CDN answered slower at the median (525 ms against 329 ms) while being far more likely to compress and to speak HTTP/2.
The likely explanation is not that CDNs are slow. A CDN in front of a site does not cache HTML by default — the common configuration proxies every page request through to the origin, so time to first byte becomes the origin's own response time plus a hop, while the static assets we did not measure are the part actually being accelerated. It is also a selection effect: the sites that reach for a CDN tend to be the larger, more complicated ones with more work to do per request, and we are measuring from inside Australia, where a locally-hosted origin has a genuine geographic advantage.
What this does not support is "turn your CDN off". What it does suggest is that a CDN alone will not fix a slow origin, and that HTML caching at the edge is the setting most of these sites have left on the table.
CDN detection is based on response headers
(cf-ray, x-amz-cf-id, x-cache, x-served-by),
so a CDN that strips its own headers is counted as direct.
What is serving Australian websites
By type of Australian domain
| Namespace | Domains | Median TTFB | Compressed | HTTP/2 or 3 | CDN |
|---|---|---|---|---|---|
com.au |
4,797 | 470 ms | 92.2% | 91.8% | 65.8% |
au (direct) |
510 | 1,498 ms | 97.5% | 98.6% | 92.4% |
org.au |
375 | 382 ms | 89.6% | 89.1% | 56.8% |
gov.au |
312 | 291 ms | 88.1% | 89.4% | 33.7% |
edu.au |
206 | 344 ms | 92.2% | 89.8% | 61.2% |
net.au |
204 | 362 ms | 80.4% | 76.0% | 32.4% |
Methodology
- Population
- Every domain ending in
.auin the Tranco list published 17 August 2026 (IDK9L5W, permanently retrievable at https://tranco-list.eu/list/K9L5W) — 8,376 domains, the whole.ausubset. - Measurement
- One HTTPS GET of
https://<domain>/, following up to five redirects, 20-second overall timeout, advertising gzip, deflate, Brotli and zstd so the server's own preference is what gets recorded. Timings come from curl: time to first byte isstarttransfer_time, which includes DNS, TCP, TLS and the server's processing. Only the HTML document is fetched — no sub-resources — so page weight here means markup weight, not total page weight. - What failed, and why it is excluded
- 1,955 of 8,376 domains did not return a page: 1,003 http error response; 602 connection failed or timed out; 350 did not resolve to a public address. A large tail of any popularity list is parked, expired or firewalled, and counting those as slow sites would be wrong, so they are excluded from every percentage rather than folded in.
- One measurement, from one place
- A single request per domain from a single Australian connection. That means no cold-cache versus warm-cache distinction, no allowance for a server that happened to be busy, and no view of what a visitor overseas would see. Percentiles across thousands of domains are robust to that; any individual domain's number here is one sample and should be treated as such.
- Point in time
- A single scan on 19 August 2026.
- Reproducing it
- The aggregated results are published as JSON under a CC BY 4.0 licence. The Tranco list ID pins the exact input, and every measurement here is one curl request per domain — reproducible with a one-line command.
Corrections welcome. If a domain here is measured wrongly, or you can see a methodological problem we have missed, tell us and we will correct the page and say what changed.