Static Site Generators in Production

Astro vs Eleventy Build Times at 10,000 Pages

At a few hundred pages, every static site generator builds fast enough that the difference does not matter. At ten thousand, it decides how long every pull request waits for its preview, how much each CI run costs, and whether the build fits in a hosted build container at all. Documentation sites reach that size more often than teams expect: API references generated from code, versioned copies, translations and changelogs multiply a few hundred authored pages into thousands of built ones.

This benchmark builds the same documentation corpus with Astro 5 and Eleventy 3 at 1,000, 2,500, 5,000 and 10,000 pages, measuring cold builds, warm builds after a one-page edit, and peak memory. It belongs to Astro vs Eleventy for Documentation Sites and follows the method in How to Benchmark Hugo vs Astro Build Speeds.

Prerequisites and Method

  • Corpus: technical documentation pages averaging 1,150 words, with code blocks (syntax highlighted), tables, internal links and front matter; no images processed at build time, to isolate page generation.
  • Generators: Astro 5.x with a content collection and Shiki highlighting; Eleventy 3.x with Nunjucks layouts and @11ty/eleventy-plugin-syntaxhighlight (Prism).
  • Both sites share the same layout: header, sidebar navigation, table of contents, footer.
  • Runner: GitHub Actions ubuntu-latest (4 vCPU, 16 GB); hyperfine --warmup 1 --runs 5; peak memory from /usr/bin/time -v.
for n in 1000 2500 5000 10000; do
  node scripts/make-corpus.mjs $n       # copies/permutes real pages to size n
  hyperfine --warmup 1 --runs 5 --export-json "astro-$n.json" 'npx astro build'
  hyperfine --warmup 1 --runs 5 --export-json "eleventy-$n.json" 'npx @11ty/eleventy'
done

Cold Builds

PagesEleventyAstroAstro / Eleventy
1,0005.1 s14.2 s2.8×
2,50010.4 s29.8 s2.9×
5,00019.6 s57.1 s2.9×
10,00038.2 s112.4 s2.9×
Cold build time from 1,000 to 10,000 pages Two nearly straight lines. Eleventy grows from 5 seconds at 1,000 pages to 38 seconds at 10,000. Astro grows from 14 seconds to 112 seconds. The ratio stays close to 2.9 times at every size. Cold build seconds vs pages 0 60 120 1k 2.5k 5k 10k pages Astro 112 s Eleventy 38 s hyperfine, 5 runs, GitHub Actions ubuntu-latest (4 vCPU, 16 GB)
Both scale linearly with page count; Astro's line is simply steeper, by a nearly constant factor.

Both generators scale linearly, which is the good news: neither has a hidden quadratic step at this size. Astro's constant factor comes mainly from per-page Vite module handling and from rendering each page through its component pipeline even when the page is plain Markdown. Profiling with --verbose timings attributed about 40% of Astro's build to rendering, 25% to Shiki highlighting and the rest to bundling and writing. Eleventy's time split roughly evenly between Markdown rendering, Prism highlighting and template execution.

Warm Builds After a One-Page Edit

Cold builds are the worst case; what writers wait on is the rebuild after editing one page. Here the generators work very differently.

Astro's content layer stores a digest of each entry in node_modules/.astro/data-store.json. On a warm build, unchanged entries skip parsing, but every page is still rendered and written, because Astro builds the whole site.

Eleventy's incremental mode (--incremental) rebuilds only templates whose input changed, plus templates that depend on them through the data cascade. In CI it needs the previous output and .cache restored; locally it is automatic in --serve.

One-page edit, 10,000 pagesEleventyAstro
Full rebuild (no cache)38.2 s112.4 s
Warm, cache restored34.9 s (without --incremental)31.4 s
Incremental, changed page only3.6 sn/a
Incremental, changed page used in navigation36.1 sn/a
Rebuild after editing one page at 10,000 pages Bars for four rebuild modes. Astro cold 112 seconds, Astro with content-layer cache 31 seconds, Eleventy full 38 seconds, and Eleventy incremental 3.6 seconds. A note says Eleventy incremental falls back to about 36 seconds when the edited page appears in shared navigation data. Seconds to rebuild after editing one page (10,000 pages) Astro, cold 112 Astro, cache restored 31 Eleventy, full 38 Eleventy, incremental 3.6 Eleventy incremental falls back to ~36 s when the edited page feeds shared navigation data
For the edit-one-page loop, Eleventy's incremental mode is in a different class — as long as the page is not referenced everywhere.

The caveat in the last row matters for documentation. If the edited page's title appears in a sidebar built from a collection that every page renders, Eleventy correctly treats every page as dependent and rebuilds them all. The workaround — building navigation from a data file that changes only when structure changes, not from page titles on every build — is covered in Enabling Incremental Builds in Eleventy and Sidebar Navigation in Astro and Eleventy.

Memory

PagesEleventy peak RSSAstro peak RSS
1,000310 MB820 MB
5,000640 MB2.1 GB
10,0001.1 GB3.6 GB

At 10,000 pages Astro exceeded Node's default old-generation heap on one run and crashed with JavaScript heap out of memory until NODE_OPTIONS=--max-old-space-size=6144 was set. On hosted build services with 4 GB or less, that is a hard ceiling rather than a slowdown. Eleventy stayed well under 2 GB throughout.

Peak memory against common build container limits Bars of peak resident memory at 10,000 pages: Eleventy 1.1 gigabytes and Astro 3.6 gigabytes. Dashed lines mark typical build container limits at 2 gigabytes and 4 gigabytes. Astro sits just under the 4 gigabyte limit, leaving little headroom. Peak memory at 10,000 pages vs container limits 2 GB 4 GB Eleventy 1.1 GB Astro 3.6 GB /usr/bin/time -v maximum resident set size, median of 5 cold builds
Wall time degrades gracefully; memory does not — past the container limit the build simply fails.

What This Means for Previews and CI

Build time at this scale is mostly a preview-deploy problem. Production deploys happen a few times a day and can afford two minutes; previews happen on every push to every pull request, and reviewers wait for each one. On a team pushing 60 times a day, the difference between a 38-second and a 112-second build is about 75 minutes of runner time daily and, more importantly, the difference between a preview that is ready when the reviewer opens the pull request and one that is not.

Both generators can cut preview time well below their cold numbers. For Eleventy, restoring _site and .cache and running incremental builds makes most previews take seconds. For Astro, restoring the content-layer store and the highlight cache brings a one-page change to about 31 seconds; beyond that, the realistic option is building only the section a pull request touches for its preview, using a path filter and a smaller content collection, while production always builds everything. The caching mechanics are the same as in Caching Hugo Builds in GitHub Actions, with different directories.

Reducing Astro's Build Time

Three changes brought Astro's cold build at 10,000 pages from 112 s to 71 s without changing the site's output:

  • Highlight once, not per build. Shiki is expensive per code block. Caching highlighted HTML keyed by code and language (a small remark plugin with an on-disk cache) cut 21 s.
  • Avoid per-page component work on plain pages. Rendering Markdown pages through a lightweight layout without islands or MDX-only components cut 12 s.
  • Raise concurrency. build.concurrency: 4 in astro.config.mjs renders pages in parallel on a 4 vCPU runner; it cut 8 s and raised peak memory by about 15%.

Eleventy's equivalent levers — caching expensive filters with eleventy-fetch or memoisation, and avoiding collections.all loops in layouts — are covered in How to Reduce Bundle Size in Eleventy Builds and apply to build time as much as to output.

Pitfalls & Rollback

  • Benchmarking a toy corpus. Lorem-ipsum pages without code blocks understate highlighting costs, which dominate both builds on real docs.
  • Ignoring memory. Wall time hides the crash risk; record peak RSS alongside time.
  • Single runs. Build times on shared runners vary by 10–15%; always report the median of several runs.
  • Comparing Astro warm with Eleventy cold. Compare like with like: both cold, both with caches restored.
  • Incremental builds without the dependency caveat. Shared navigation data turns incremental into full rebuilds.
  • Rollback: the benchmark changes nothing in production; the Astro optimisations are config and plugin changes that can be reverted individually.

Conclusion

At 10,000 documentation pages, Eleventy built cold in 38 seconds and Astro in 112, a near-constant 2.9× gap from 1,000 pages upwards, with Astro also needing over three times the memory. For the edit-one-page loop, Eleventy's incremental mode rebuilt in under four seconds against Astro's 31-second warm build. Astro narrowed the cold gap to about 1.9× with highlight caching, lighter layouts and parallel rendering. If build time is your bottleneck at this scale, Eleventy has the structural advantage; if Astro's component model and islands matter more, budget for the memory and invest in caching.

FAQ

Which is faster at 10,000 pages, Astro or Eleventy?

On our corpus, Eleventy built 10,000 Markdown pages cold in 38 seconds and Astro in 112 seconds. With a warm cache after a one-page edit, Astro's content layer brought it to 31 seconds, while Eleventy's incremental mode rebuilt the changed page in under 4 seconds.

Does Astro's build time grow linearly with pages?

Roughly, yes, for Markdown pages without heavy components. Time per page stayed near 11 milliseconds from 1,000 to 10,000 pages. Pages with many MDX components or image processing cost considerably more per page.

How much memory do the builds need?

Eleventy peaked at about 1.1 GB for 10,000 pages and Astro at about 3.6 GB. Astro's default Node heap limit can be exceeded on large sites, which requires raising max-old-space-size or splitting content.

Should build time decide between them?

Only if builds are genuinely a bottleneck, which at 10,000 pages they can be for preview deploys. Otherwise, component model, writer experience and page weight usually matter more, and both generators have ways to keep incremental builds fast.