The numbers, and how to check them.
This site claims to be small, fast, and usable on a cheap phone. Claims are free, so here is the measurement, the method that produced it, and the part it does not cover.
The claim sits in the footer of every page, which makes it the easiest thing on the site to fake. Publishing the measurement is the only version of that claim worth making, and it costs me the ability to quietly let it stop being true.
What one visit costs
| The page itself | 7.1 kB41.7 kB before compression |
|---|---|
| Code and fonts | 207.4 kBacross 11 files |
| Everything needed to read the page | 214.5 kB237.8 kB over gzip |
| The photo at the top, phone size | 16.5 kBAVIF, loaded after the text |
| Requests to render it | 13no third-party domains |
Sizes are brotli, which is the encoding the server negotiates with any browser from the last several years. The gzip figure is what an older Android browser falls back to, and those are the readers the claim is actually about.
About half of that total is two font files and a compatibility bundle for older browsers. The text of the page is a small fraction of it. I keep the fonts because the typography is doing real work rather than decoration, and I keep the compatibility bundle for the same reason the site exists: it is what lets an older phone run the page at all.
Every file, largest first
chunks/4bd1b696-c023c6e3521b1417.js | 45.7 kB |
|---|---|
media/9d5a263311222317-s.p.woff2 | 40.3 kB |
chunks/255-64e783496c90356a.js | 37.2 kB |
chunks/polyfills-42372ed130431b0a.js | 34.3 kB |
media/313510e2713fb214-s.p.woff2 | 33.9 kB |
css/bd03f02742e3fca7.css | 8.5 kB |
chunks/619-ba102abea3e3d0e4.js | 2.9 kB |
chunks/app/layout-71ee6e89209db43a.js | 2.2 kB |
chunks/webpack-d804fee0d7622df3.js | 1.5 kB |
chunks/app/page-fb68ea47c2b77f31.js | 0.8 kB |
chunks/main-app-f0e9d3cf3f974729.js | 0.2 kB |
How fast, on a throttled phone
Phone
1638.4 kbps down, 150 ms round trip, processor slowed 4×
Median of 5 runs. Performance scored between 96 and 99.
- 98Performance
- 100Accessibility
- 100Best practices
- 100SEO
| First contentful paint | 0.8 s |
|---|---|
| Largest contentful paint | 2.3 s |
| Speed index | 0.9 s |
| Total blocking time | 90 ms |
| Cumulative layout shift | 0 |
| Time to interactive | 2.3 s |
Desktop
10240 kbps down, 40 ms round trip, processor slowed 1×
Median of 5 runs. Performance scored 100 every time.
- 100Performance
- 100Accessibility
- 100Best practices
- 100SEO
| First contentful paint | 0.2 s |
|---|---|
| Largest contentful paint | 0.5 s |
| Speed index | 0.3 s |
| Total blocking time | 0 ms |
| Cumulative layout shift | 0 |
| Time to interactive | 0.5 s |
Lighthouse's mobile run models a slow connection and a phone roughly four times slower than a laptop. It is the closest repeatable approximation of the reader this site is built for.
Lighthouse 12.8.2. Lighthouse CLI against the deployed build served locally over brotli, matching production's Content-Encoding. Timings exclude the network round trip to the server.
What this does not prove
- The network is not in these timings
- Every measurement above ran against the deployed build served on the same machine, so the round trip to the server is missing. A real visit is slower by whatever your connection adds. The bytes are exact; the milliseconds are a floor.
- It is a model of a slow phone, not a slow phone
- Lighthouse simulates the connection and slows the processor by a fixed multiple. It does not reproduce a five-year-old handset with a full storage chip on a congested cell at 7pm. Nothing that runs in a data centre does.
- The accessibility score is automated only
- A perfect automated score means no machine-detectable failures. Machines cannot judge whether alt text is meaningful, whether focus order follows the reading order, or whether an error message tells a person what to do. So this is a clean automated audit and not a WCAG 2.1 AA conformance claim. I am not going to claim conformance I have not had independently tested.
- A single run would have flattered me
- Lighthouse varies between runs of an identical build. The first mobile run I did scored 100 with a 1.6 second largest paint. The median of five scored 98 at 2.3 seconds. The median is what is published, along with the range, because publishing the good run and calling it the number is the specific dishonesty this page exists to avoid.
- The numbers are one build behind
- They are generated from the previous build, because writing them into the page changes the page's size. The gap is a few hundred bytes and it is stated here rather than rounded away.
- Production itself blocks the tools
- The host serves automated clients a challenge page instead of the site, so these runs use the identical build served locally with the same compression. If that ever stops being an honest substitute, this page should say so instead of quietly continuing.
Check it yourself
Nothing above requires trusting me. The site is a static export, so the artefact you download is the artefact I measured.
- In your own browser, right now
- Open developer tools, go to the Network tab, tick Disable cache, and reload. The transferred total is the number in the table. This is the version I would believe if I were you.
- Turn JavaScript off and reload
- Every page keeps its text, its navigation and its contact form. The scroll animations stop, which is the only thing they were ever load-bearing for.
- Run the measurements from source
- npm run build, then npm run measure for the byte tables and npm run measure:lh for the Lighthouse run. Both regenerate the JSON files this page reads.