Static sites that stay fast
A static site is not automatically a fast site. It just removes a whole category of excuses. Once every page is a file, the remaining budget is spent on HTML, CSS, images, and whatever JavaScript you decide to add.
The build is the easy part
Generating HTML ahead of time means readers never wait for a template engine or a database query. A build can be as slow as it likes; nobody is watching.
The trade-off is that the output becomes the product. A 300 KB JavaScript bundle is still a 300 KB JavaScript bundle, even if it was built by a static site generator.
The fastest page is the one the browser can render before the network gets interesting.
Keep the critical path boring
A useful checklist for a text-first site:
- Serve one stylesheet, and keep it small.
- Use system fonts instead of downloading a webfont.
- Defer anything that is not needed to read the page.
- Optimise images before they reach the server.
- Pre-render search data instead of querying an API.
That last point is the one people tend to overcomplicate. For a personal blog, a JSON file with the plain text of each post is usually enough.
Measure the output, not the intention
A quick sanity check after a build:
Get-ChildItem dist -Recurse -File |
Measure-Object -Property Length -Sum
If the total is small and the individual pages are mostly text, the site will feel fast on almost any connection.
| Concern | Better default |
|---|---|
| Fonts | System stack |
| CSS | One small file |
| Search | Pre-built index |
| Images | Compressed, lazy-loaded |
| JavaScript | Optional |
None of this is novel. It is just easier to maintain when the site is built from files instead of assembled per request.