Incremental Rebuild Times Across Astro, Eleventy and Hugo

"Incremental builds" means different things in each generator. Hugo rebuilds the whole site so quickly that its incremental behaviour lives mostly in the dev server. Eleventy has an --incremental flag that shines in watch mode. Astro caches content processing in its content layer between builds but still renders every page. Comparing their documentation does not tell you how long a typo fix takes to reach production, which is the number teams actually care about.

This comparison builds the same 5,000-page documentation site — Markdown content, 900 processed images, a sidebar and tag pages — with Astro 5.2, Eleventy 3.0 and Hugo 0.139, and measures full builds, cached CI rebuilds after a one-page change, and dev server rebuilds, all on the same machine. It belongs to Incremental Builds and Build Caching for SSGs.

Method

• Content: 5,000 Markdown pages (average 900 words), 900 images in 3 widths and 2 formats, 120 tag pages, a section sidebar on every page.
• Equivalent templates in each generator: same HTML, same image widths, same sidebar.
• Machine: GitHub Actions standard runner (4 cores, 16 GB) for CI numbers; an M3 laptop for dev server numbers.
• Measurement: hyperfine with 5 runs (1 warm-up) for builds; dev server rebuild time from the generator's own log line or file timestamps, median of 20 edits.
• Change: edit one paragraph in one page.

Full Builds

Image processing dominated cold builds for all three. With image caches restored, Hugo's full build of 5,000 pages took six seconds.

Rebuilds After a One-Page Change in CI

In CI, every run starts a fresh process, so only what each generator can restore from disk helps:

Astro's content layer, with node_modules/.astro restored, skipped parsing and rendering Markdown for 4,999 unchanged entries, which halved the cached build. Page generation still ran for all 5,000 routes. Eleventy has no persistent content cache across processes; a custom script that builds only changed inputs plus listing pages, as in Fixing Stale Pages From Incremental Builds, got it to 9 seconds, at the cost of maintaining that script and a nightly full build. Hugo needed nothing: its full build was already faster than the others' best case.

Dev Server Rebuilds

What writers feel when they save a file:

Astro's dev server renders pages on request, so it does almost no work on save and only re-renders the page being viewed. Hugo re-renders affected pages in memory. Eleventy's incremental mode rebuilds the changed page quickly, but layout and data changes trigger rebuilds of every page that uses them, which on 5,000 pages takes about ten seconds.

Deploy Time

The build is only part of commit-to-live. With each host uploading only changed files:

What Changes at 50,000 Pages

The 5,000-page site is a common size, but the ranking matters most for teams heading towards much larger sites. Scaling the content tenfold by duplication with varied text gave a sense of the trend, measured once each with image caches restored:

All three grew roughly linearly, slightly worse than linear, mostly from memory pressure; Eleventy needed a raised heap limit at 50,000 pages. The gap between Hugo and the others stayed around an order of magnitude. At that size, Hugo's segments and parallel builds, described in Parallel Hugo Builds Across CI Jobs, become relevant; for Astro and Eleventy, the realistic path to fast content updates is not rebuilding all pages at all — splitting the site, or rendering the long tail on demand.

Choosing With Writers in Mind

Build time in CI determines how long a change takes to go live; dev server speed determines how pleasant it is to write. The two can point in different directions. On this content, a writing team that spends its day editing Markdown would be happiest with Astro's or Hugo's dev servers, both well under a second per save; a team that changes layouts and shared data often would find Eleventy's ten-second rebuilds at this size a real cost. Measuring both, on your own content, is worth an afternoon before committing to a generator for a site that will grow.

Verdict

• Hugo needs no incremental strategy for CI: full builds of 5,000 pages take seconds once images are cached. Its dev server is also very fast. Choose it when build speed at scale is a priority, as discussed in Hugo Build Times for Large Repositories.
• Astro benefits most from restoring the content layer data store and image cache in CI; it halves the rebuild. Its dev server is the fastest of the three for writers, because it renders on demand.
• Eleventy is fast in watch mode for content edits, slow for layout edits at this scale, and needs a custom affected-files approach to be fast in CI, with the correctness risks that brings.

Pitfalls

• Comparing cold builds only. Image caches change the ranking of the differences.
• Assuming dev server speed equals CI speed. They measure different things.
• Custom incremental scripts without a full-build check. They drift out of correctness.
• Ignoring tests and upload. At Hugo speeds, they are most of the time to live.

Conclusion

On the same 5,000 pages, Hugo's full build with cached images (6 seconds) beat the other generators' best incremental CI rebuilds; Astro's content layer cache halved its rebuild to 39 seconds, and Eleventy reached 9 seconds only with a custom script. In the dev server, Astro's on-demand rendering felt fastest for writers. The right "incremental" strategy depends on the generator: caching for Astro, raw speed for Hugo, and careful scripts — or patience — for Eleventy in CI.

FAQ

Which static site generator rebuilds fastest after a small change?

In this comparison, Hugo's full rebuild of 5,000 pages took 6 seconds, faster than either other generator's incremental rebuild in CI. Eleventy's incremental mode rebuilt a single changed page in about 1.4 seconds in watch mode, and Astro's content layer cache brought a CI rebuild from 74 to 39 seconds. For CI builds, Hugo's raw speed matters more than incremental features.

Does Astro support incremental builds?

Partially. Astro's content layer caches parsed and rendered content between builds when its data store is preserved, so unchanged entries skip parsing and Markdown rendering. Every page is still generated in a static build, so the saving is in content processing, not page rendering. The dev server rebuilds only what is requested.

Does Eleventy's incremental mode work in CI?

Eleventy's incremental flag is designed for watch mode and the dev server, where the process stays running and knows what changed. In CI, a fresh process does not have that state. CI speedups for Eleventy come from caching image processing and remote data, or from building only affected inputs with a custom script.

What should I cache in CI for each generator?

For Hugo, the resources directory with processed images and the module cache. For Astro, node_modules slash .astro with the data store and the assets cache. For Eleventy, the image plugin's cache directory and the fetch cache. In all three, dependency installs are cached through the package manager.

Related

• Parent: Incremental Builds and Build Caching for SSGs — strategies for faster builds.
• Incremental Builds in Astro with the Content Layer — the Astro cache in depth.
• Enabling Incremental Builds in Eleventy — Eleventy's incremental mode.
• Caching Hugo Builds in GitHub Actions — the Hugo caches used here.
• Astro vs Eleventy Build Times at 10,000 Pages — full builds at twice the size.