Astro or a custom static generator.
Both end up producing static HTML; the difference is not in the file but in which work you delegate — and what that delegation costs.
If the comparison starts with “which is better” it stays unanswered, because both produce the same thing: HTML prepared ahead of time. The useful question is this: which of the jobs done at build time are you delegating to a framework, and where do you pay for that delegation? The same question is asked one layer up as well: static site or CMS.
What the framework takes over
A static site framework brings ready-made what every project otherwise rewrites: file-based routing, schema validation for content files, derivative images, a sitemap, a component model, and an island architecture that ships JavaScript only where it is needed. Each of those is days of work on its own, and all of them are documented. The cost shows up in two lines: the installed dependency tree and the framework’s release calendar. The second is not abstract — while preparing this comparison, a measured project’s framework version refused to run on the machine’s Node version and asked for the environment to be upgraded first.
What a custom generator gives you
A custom generator means the whole output is your responsibility. The gain appears with unusual requirements: this site has a machine layer on every page, a schema graph in three languages, figures fed from measurement ledgers and a link graph derived from content files — none of it toggled by a plugin, all of it written into the generator. The cost is in the same sentence: you write all of it, you measure all of it, you maintain all of it.
Two measured numbers, and what they do not say
Same machine, 22 September 2026: an Astro project produced 122 pages in 1.57 seconds; this site’s generator produced 466 pages in 1.03. These are not the results of a race but the durations of two different job descriptions. Astro compiles components, processes assets and produces image derivatives; this generator prints HTML from approved JSON, draws figures in its own drawing language and leaves image derivatives to separate tools. The correct reading is this: both stay far below the time a person is willing to wait — so build speed is not what decides this choice.
How to decide
If the team is growing, the work is standard and the project is expected to change hands, the framework side holds fewer surprises: the documentation is shared, the patterns are known, a newcomer can produce on day one. If the requirements are unusual, every byte of output has to be auditable and the team is small, a custom generator means fewer layers — the time spent hunting for a framework’s escape hatches can exceed the time spent writing your own code. Both paths are legitimate; what is wrong is deciding without measuring.
Criterion
- Getting started — Astro: Install and configure in minutes; routing, content collections, image processing and sitemaps come ready · A custom static generator: Every part is written: route map, templates, sitemap, feed, multilingual routing
- Dependencies (measured · 2026-09-22) — Astro: Two runtime and four dev packages; the installed tree is 478 megabytes on this machine · A custom static generator: No runtime dependency in this repository; there is no `node_modules` directory
- Build (same machine · 2026-09-22) — Astro: 122 pages in 1.57 seconds (warm image cache) · A custom static generator: 466 pages in 1.03 seconds (best of three runs: 1.03 · 1.03 · 1.13)
- Runtime — Astro: Island architecture: only components that need interaction are hydrated · A custom static generator: Whatever you wrote is what ships; there is no default runtime
- Versions and environment — Astro: The framework version drives the environment: in this project Astro 7 refused to start on Node 20 and asked for 22.12 or newer · A custom static generator: No framework upgrade; your own code sets the environment requirement
- Ecosystem — Astro: Integrations, themes, documentation and a community · A custom static generator: None — every need is met in your own code
- Handover and learning — Astro: Widely known: a new developer learns from the docs · A custom static generator: Specific to the organisation: handover depends on written docs and readable code
- Limits — Astro: Needs outside the framework’s scope send you looking for an escape hatch · A custom static generator: No limits — and no shared cost either
- Where it fits — Astro: Teams, standard needs, a fast start, handover · A custom static generator: One person or a small team, unusual requirements, output that must stay auditable for years
FREQUENTLY ASKED QUESTIONS
Is a site built with Astro slower?
No; both serve static HTML, and runtime speed is decided by the weight of the page rather than by the generator. The numbers in this comparison are from the build side: on 22 September 2026, on the same machine, an Astro project produced 122 pages in 1.57 seconds and this site’s generator produced 466 pages in 1.03. The two numbers do not measure the same work — Astro compiles components and processes images, this generator prints HTML from JSON and draws its own figures.
How long does writing your own generator take?
On this site the generator was not written in one go; it grew with the site. The real question is not “should I write one” but “which work am I delegating”: should routing, schema, multilingual routing, feeds and image processing arrive ready, or should all of it be measurable and auditable?
What is the risk of a custom generator?
Two risks: handover and the cost of measurement. In a framework the community finds defects you would otherwise have to find yourself. In this repository the answer to that is a gate behind every decision — which is exactly why the verification suite exists.