Build Speed Across Six Popular Static Site Generators
Choosing a static site generator (SSG) means balancing developer experience, ecosystem, and plain old build speed. A colleague's evaluation cheatsheet covers the feature side of that equation, but what’s missing is how these tools actually perform under load.
Every SSG shares a core job: run input data through a templating engine, then emit HTML. That process, The Build, is hard to compress into a comparison spreadsheet because performance depends on context and configuration. Rather than chase a single “fastest” champion — Hugo already claims that title — this benchmark compares widely used SSGs to see where the real bottlenecks are and what the timing spread actually reveals about each tool’s design.
Test Setup and Scope
Six popular SSGs were tested:
- Eleventy
- Gatsby
- Hugo
- Jekyll
- Next
- Nuxt
Each build followed the same conditions. Source data consisted of Markdown files with randomly generated titles in frontmatter and three paragraphs of body content, with no images. Output was plain unstyled HTML. Each run was a cold run: caches cleared and Markdown regenerated before every test. All tests ran in series on a single machine, making relative comparisons more meaningful than absolute numbers.
The methodology mirrors baseline benchmarks rather than real-world projects. No image optimization, no plugins, no additional asset processing. In practice, those decisions significantly alter results — most often by slowing builds down. It also means warm or incremental builds, which can cut build times dramatically for tools like Gatsby, aren’t accounted for here.
Basic vs. Advanced Generators
Before looking at data, it helps to separate the field into two groups. Basic generators behave like focused command-line tools: take data, render HTML, optionally process assets. Advanced generators include server-side rendering, integration with front-end frameworks, and other dynamic features.
Eleventy, Hugo, and Jekyll fall into the basic bucket. Gatsby and Next are React-based; Nuxt is built on Vue — all three are advanced framework-bound tools.
| Basic generators | Advanced generators |
|---|---|
| Eleventy | Gatsby |
| Hugo | Next |
| Jekyll | Nuxt |
Hypothesis
The working theory was that advanced SSGs would consistently trail basic ones because of higher baseline overhead. Webpack bundles alone add significant weight regardless of content volume. The expected results: Hugo and Eleventy take an early lead, with Go potentially outperforming Node at higher scale. Gatsby was predicted to lead the advanced group (being purely static compared to server-rendered peers), and Nuxt was expected to edge out Next based on Vue’s lighter footprint.
Jekyll was the outlier. Ruby isn’t known for raw performance, but Jekyll lacks framework baggage. Initial runs might look competitive with Eleventy, only to fall behind sharply as file counts climb — possibly even hitting last place in scale.
Results: What the Data Showed
Testing produced 10 runs per framework across three dataset categories: a single base file, small sites scaling from 1 to 1,024 files with doubling increments, and large sites from 1,000 to 64,000 files also doubling per run. The upper limit stopped at 64,000 due to bottlenecks in some frameworks; previous attempts at 128,000 files were unreliable.
Key Findings
- Hugo won decisively at every size. The gap at single-file runs was larger than expected — roughly 250 times faster than Gatsby at one file, still about 40 times faster at 64,000 files.
- The basic/advanced split was clearly visible on small sites. However, a surprise emerged at 64,000 files: Next and Eleventy nearly converged, and Jekyll actually outperformed Eleventy on every single run.
- Gatsby under-performed its expectations. Predicted to be the fastest advanced generator, Gatsby produced the steepest curve and landed as the slowest of all six.
- Absolute differences narrowed as sites grew, even though the ordering held — a pattern showing that overhead matters most at small scale.
Interpreting the Gap
Feedback from the SSG creators and maintainers converged on a similar explanation. Builds take longer when tools do more work — beyond templating, they bring extensive developer tooling, component models, and optimization machinery. Slower generators aren’t lazy; they’re carrying more.
The takeaway is conditional: scaling a Jamstack site is difficult in different ways depending on the entire toolchain. Build-time benchmarks capture only one dimension. Gatsby’s plugin ecosystem and component architecture justify long build times for image-heavy sites, where Jekyll’s simpler pipeline might mean more manual engineering to stay organized. On the developer experience side, Gatsby provides structure for complex builds; Jekyll requires discipline for the same complexity.
There is no universal winner. In practice, a site built entirely with an advanced framework like Gatsby or Next succeeds by combining micro front-ends, offloaded image processing, content previews, and other optimizations to manage build times. Meanwhile, projects built for simple content needs — particularly solo or low-maintenance sites — may prefer Eleventy for output-level control and fast client-side performance.
The actual numbers matter less than understanding how each tool’s built-in overhead interacts with content scale. Every SSG in this test builds real, deployable websites by spec. Whether the wait fits your project is a question of how much that generator delivers beyond markup — and how much build time you’re willing to trade for it.
