I Ran Six Static Site Generators on the Same 400 Posts. Build Time Wasn't the Differentiator.
Every static site generator comparison opens with build times, and every one of them is measuring the thing that matters least. I took the same corpus, four hundred markdown files with frontmatter, images, tags and a couple of taxonomies, and pushed it through six generators to see what actually differed.
Build time differed by more than an order of magnitude. It changed nothing about which one I would pick.
The setup
Same content directory, copied six times. Same images, same frontmatter schema, same target output: a paginated index, per-post pages, tag archives, an RSS feed and a sitemap. Minimal theming, because theme complexity dominates build time in most generators and I wanted to compare the engines rather than my CSS.
Cold build times ranged from under a second to several minutes. That gap is real and it is also, for a four hundred post site, entirely irrelevant. A four minute build that runs on push is a four minute wait you spend doing something else. A one second build that runs on push is a one second wait you spend doing something else.
Where build time genuinely matters is the dev server, and that is a different measurement.
What actually differed, in rough order of how much it cost me
Incremental rebuild in the dev server. This is the number that affects daily work. Editing a post and waiting for the browser to update is a loop you run hundreds of times a day, and the difference between fifty milliseconds and four seconds is the difference between writing and waiting. Some generators that lose badly on cold build win comfortably here because they only rebuild what changed. Some that win on cold build rebuild everything every time.
Frontmatter portability. Four hundred files with a fixed frontmatter schema is an asset until you try to move it. Generators differ on which keys are reserved, how they handle unknown keys, whether dates need quoting, whether a colon in a title breaks the parse, and what happens to a field that one engine treats as a taxonomy and another treats as a string. Two of the six required a rewrite pass across every file before they would build at all.
That migration cost is the real lock-in, and it never appears in a comparison table.
Taxonomy handling. Tags are trivial. Tags plus categories plus a per-tag archive page plus a tag cloud plus related-post logic is where engines diverge sharply. Some give you the whole set as built-ins. Some give you a data structure and expect you to write the templates. Some make hierarchical taxonomies genuinely painful.
The image pipeline. Resizing, format conversion, responsive srcset generation and cache behaviour between builds. This is the single largest determinant of both build time and output quality, and it is the area where the generators differ most in philosophy. Built-in pipelines are convenient and opinionated. External pipelines are flexible and are one more thing to maintain.
Template language. Entirely a taste question until you need to do something the language was not designed for, at which point it becomes the only thing that matters. Ask any generator’s users what they complain about and it will be the templating.
Plugin dependency surface. A generator with a rich plugin ecosystem is a generator where your build depends on a dozen packages maintained by a dozen strangers. That is fine until one of them stops being maintained and your build breaks eighteen months later on a site you have not touched. Engines with fewer moving parts age better, which is a property that no benchmark measures because benchmarks run once.
The one place build time does matter
At a certain corpus size, the relationship inverts. A four hundred post site can afford a slow generator. A four thousand post site with an image pipeline cannot, because the cold build moves from an annoyance into the territory where CI timeouts and deploy queues become the constraint.
If you are running many sites rather than one, the arithmetic changes again. Slow builds multiplied across a network are a real cost, both in wall clock time and in whatever your CI provider charges for minutes.
That is the honest case for the fast generators, and it is a case about scale rather than about developer experience.
What I would actually optimise for
Ask these before you ask about speed.
Can I move my content out without a rewrite. How long does an incremental rebuild take in the dev server. What does the build depend on that I do not control. And can I read the template language in six months when I have forgotten everything about this project.
The fastest generator that fails the first question will cost you more time in one migration than it saves you in five years of builds.