Shipping less JavaScript than you think you need
Every performance conversation starts with a number that nobody measured. The useful version is smaller: what does one article page actually download, after gzip, with a cold cache?
Measure the page that pays
An article page is not the same as a landing page, and a bundle report is not the same as a network log. The build output tells you what you produced; only the network tells you what the reader downloaded.
# Cold cache, one route, gzipped transfer size.
curl -s -H 'Accept-Encoding: gzip' -o /dev/null \
-w 'transfer: %{size_download} bytes\ntime: %{time_total}s\n' \
https://example.com/an-article/What actually shipped
| Asset | Raw | Gzipped | Budget |
|---|---|---|---|
| Stylesheet | 12.7 KiB | 4.4 KiB | 25 KiB |
| JavaScript | 1.9 KiB | 1.0 KiB | 30 KiB |
| Fonts, cold cache | 69 KiB | — | — |
The rules that kept it small
- Enqueue per template, never globally. A 404 has no business loading article styles.
- Prefer the platform. A
<details>element costs nothing and needs no runtime. - Reach for a library only when the platform genuinely cannot do the job.
- Put the number in a test, or it will drift.
None of this is clever. It is mostly a refusal to add things, which is harder to sustain than it sounds.
Part of a series
Part 2 of 3 in Building this theme
- A WP_Query that does not query twice
- Shipping less JavaScript than you think you need
- Why this theme has no cascade layers
About the author
