Keeping a performance budget
The numbers this site holds itself to, how each one is measured, and what happens when a page goes over the limit.
author-one2 min read
A performance budget is a set of numbers that a page must stay under. Without one, pages get slower by small amounts that nobody notices until the site feels slow everywhere.
The budget
| Metric | Limit |
|---|---|
| HTML of one article | 30 KB before compression |
| CSS for the whole site | 20 KB before compression |
| JavaScript on a post page | 5 KB before compression |
| Largest contentful paint | Under 1.5 seconds on a fast connection |
The JavaScript limit is the strict one. A static blog needs almost no client code. The only script this site ships is the theme switch.
How the site stays inside it
No client framework. Pages are HTML and CSS. There is no hydration step, so there is no framework payload to pay for.
One stylesheet. The theme is a single file of custom properties and component classes. One file means one request and a high cache hit rate.
System fonts. The site uses the fonts already on the reader’s device. A web font would add at least two network requests and a period where text is invisible or swaps.
Optimized images. The build resizes each upload, converts it to a modern format, and writes the width and height into the markup so the layout does not shift.
What happens when a page goes over
The build prints the size of each output file. When a page passes a limit, the fix comes before the next feature. In practice the cause is almost always an image that was uploaded at full camera resolution, or a code block that should have been a link to a repository.
Why this matters for a blog
Readers arrive from search results and from social links, often on a phone and on a slow connection. A page that renders in under a second gets read. A page that takes five seconds gets closed. The budget is the cheapest way to protect that.