Build Time Benchmarks: Ranking Today's Static Site Generators by Real-World Delivery Speed

The promise of a static site is deceptively simple: pre-render everything, push it to a CDN, and let the edge do the heavy lifting. In practice, the generator you choose to produce those files has an outsized effect on how quickly you can ship, how reliably you can iterate, and how fast end users actually experience your content. Choosing the wrong tool doesn't just slow down your pipeline — it quietly undermines the entire value proposition of going static in the first place.

To cut through the marketing noise, we configured five of the most widely adopted generators — Next.js, Hugo, Jekyll, Astro, and Eleventy — with an identical content set: 500 Markdown pages, a shared set of images, a consistent navigation structure, and no third-party API calls. Every build ran on the same hardware profile and deployed to the same CDN edge network. The goal was not to declare a single winner, but to surface the tradeoffs that matter most depending on your project's scale and your team's existing expertise.

The Test Methodology

Benchmarks mean nothing without context. Our test environment used a mid-tier cloud VM (4 vCPUs, 8 GB RAM) running Node.js 20 for JavaScript-based frameworks and the latest stable binaries for Hugo and Jekyll. Each generator built the same 500-page corpus three times; we recorded the median result. Deployment targets were identical: a leading US-based CDN with edge nodes distributed across North America. Time-to-first-byte (TTFB) measurements were collected from five geographically distributed monitoring probes hitting a canonical test URL immediately after each deployment completed.

This is not a lab exercise designed to flatter any particular framework. It is a controlled attempt to answer the question engineers actually ask before committing to a stack.

Hugo: The Benchmark Everyone Else Is Measured Against

Hugo remains the reference point for raw build performance, and the numbers confirm why. Our 500-page corpus compiled in under four seconds — a figure that holds up even as page counts scale into the thousands. Hugo is written in Go, ships as a single binary with no dependency tree to manage, and parallelizes rendering aggressively. For teams producing documentation sites, marketing microsites, or content-heavy publications, Hugo's throughput is genuinely difficult to match.

The tradeoff is its templating language, which has a steeper learning curve than JSX or Nunjucks for developers coming from a JavaScript background. If your team already lives in the Node.js ecosystem, that friction has a real cost that doesn't show up in build time numbers.

Eleventy: The Quiet Contender

Eleventy — often stylized as 11ty — finished second in raw build speed, completing our corpus in roughly 18 seconds. That gap widens as page counts grow, but for projects under a thousand pages, Eleventy's performance is entirely competitive. More importantly, it ships zero client-side JavaScript by default, which means the HTML it produces is as lean as it gets before you add anything intentionally.

Eleventy's flexibility is both its strength and its complexity. It supports eleven templating languages out of the box, which makes it adaptable to almost any team's preferences. Teams that value explicit control over the output and want a minimal JavaScript footprint will find Eleventy a compelling choice for content-focused deployments.

Astro: The Modern Middle Ground

Astro completed our benchmark in approximately 35 seconds, placing it squarely in the middle of the field. What that number does not capture is Astro's architectural philosophy: its island architecture allows developers to ship fully static pages while selectively hydrating interactive components only where necessary. In practice, this produced some of the lowest JavaScript payloads of any framework in our test — directly translating to strong TTFB scores from our edge monitoring probes.

For teams building content sites that need occasional interactivity — think marketing pages with a single embedded form or a documentation hub with a search widget — Astro offers a genuinely thoughtful balance. It integrates with React, Vue, Svelte, and Solid components without forcing a full single-page application architecture on the entire site.

Next.js: Powerful, but at a Cost

Next.js is the most capable framework in this comparison, and also the slowest builder by a meaningful margin. Our 500-page static export completed in just over 90 seconds. At larger scales, that figure compounds quickly. Next.js is not primarily a static site generator — it is a full-stack React framework that happens to support static export. Teams using it for purely static output are carrying significant overhead that was designed to serve dynamic rendering use cases.

Where Next.js earns its place is in hybrid deployments: applications that mix statically pre-rendered pages with server-rendered routes, API endpoints, and incremental static regeneration. If your project requires that kind of flexibility, the build time cost may be entirely justified. If you are building a content site and reaching for Next.js out of familiarity alone, the performance data suggests it may be worth reconsidering.

Jekyll: Mature, Stable, and Showing Its Age

Jekyll, the oldest framework in our test and the one that popularized static site generation for a generation of developers, recorded the slowest build time: just over two minutes for our 500-page corpus. Ruby's runtime overhead and Jekyll's lack of parallel processing make it increasingly difficult to recommend for new projects where build speed is a priority.

Jekyll's continued relevance rests almost entirely on its deep integration with GitHub Pages and its enormous ecosystem of existing themes and plugins. For teams maintaining legacy projects or operating within GitHub's free hosting tier, Jekyll remains a viable choice. For greenfield work, the performance gap is too wide to ignore.

What the TTFB Data Actually Reveals

Build time is only half the story. Once files are deployed to the edge, TTFB differences between frameworks narrowed considerably — a reminder that a well-configured CDN is the great equalizer for static output. Hugo, Eleventy, and Astro all produced median TTFB values under 30 milliseconds from our nearest probe. Next.js static exports matched those numbers when configured correctly. Jekyll's output was equally fast once deployed.

The lesson here is worth stating plainly: the edge doesn't care which generator produced your HTML. What the edge does care about is payload size, caching headers, and asset optimization — factors that are framework-adjacent but ultimately within your control regardless of which tool you choose.

Choosing the Right Generator for Your Project

The honest recommendation depends on what you are building and who is building it:

• Hugo is the correct choice for large-scale content operations where build speed is a hard constraint and your team can invest in learning its templating system.
• Eleventy suits teams that want JavaScript familiarity, minimal output, and fine-grained control without the complexity of a component-driven framework.
• Astro is the strongest option for content sites that need selective interactivity and teams that want a modern developer experience without the bloat of a full SPA framework.
• Next.js belongs in hybrid architectures where static generation is one capability among many, not the primary objective.
• Jekyll remains defensible only for existing projects or GitHub Pages deployments where migration cost outweighs the performance benefits of switching.

Speed is not a single metric. Build time, deployment latency, and end-user TTFB each tell a different part of the story. Understanding which part matters most for your specific workload is what separates a well-reasoned framework decision from one made by convention.