· astro / eleventy / ssg

Astro vs Eleventy — content sites in 2026

Astro is the right default for TypeScript teams building content sites with CMS integration or interactive islands. Eleventy wins when build speed, zero-JS output, or maximum config freedom are non-negotiable.

By Ethan

1,456 words · 8 min read

Pick Astro if your team writes TypeScript, needs CMS integration, or wants interactive islands on otherwise static pages. Pick Eleventy if build speed at scale is the hard constraint, you need zero-JS output, or you want a bring-your-own-everything config model with no framework lock-in. The sections below tell you whether those distinctions matter for your project.

Who this is for

TypeScript-native developers choosing a static site generator for a content-heavy site in 2026. If build throughput at 10K+ pages is the primary question, that conversation lives at Astro vs Hugo — Hugo’s raw speed numbers put both tools in perspective. This article focuses on the flexibility and DX axis: Eleventy’s zero-framework philosophy vs. Astro’s opinionated component model.

What we tested

Astro v6.3 (stable as of May 7, 2026) against Eleventy v3.1.5 (stable as of March 2025). Build speed numbers come from Zach Leatherman’s SSG build benchmark (zachleat.com, July 2022, M1 MacBook Air). Note: that benchmark ran against Eleventy 1.0.1 and Astro 1.0.1 — both tools have improved since. Astro v5 Content Layer claimed 5× faster Markdown builds vs v4, and no direct 2025–2026 benchmark comparing Eleventy 3.x to Astro 5.x/6.x is publicly available. Version-pin the numbers accordingly.

Build speed

Eleventy is faster. The v1.0.1 benchmark:

PagesEleventyAstroEleventy faster by
2500.584s2.270s3.9×
5000.683s3.172s4.6×
1,0000.914s5.098s5.6×
2,0001.250s9.791s7.8×
4,0001.938s22.907s11.8×

Source: Zach Leatherman’s SSG build benchmark (Eleventy 1.0.1, Astro 1.0.1, July 2022, M1 MacBook Air, raw Markdown corpora).

Why Eleventy holds that lead: it has no component compilation step. Eleventy takes Markdown in and writes HTML out. Astro compiles .astro components, resolves imports, and handles island bundling. That overhead exists regardless of whether you use islands on a given page.

Below roughly 500 pages, both tools finish a cold build well under a second. Build speed stops being a decision criterion at that scale. Above 1,000 pages — and especially above 4,000 — the gap becomes an operational consideration: CI minutes, preview deploy times, the feedback loop during content-heavy development.

DX and templating model

This is the sharpest fork between the tools.

Eleventy is template-engine-agnostic. You get Nunjucks, Liquid, Handlebars, Mustache, WebC, JavaScript templates, TypeScript, and plain HTML out of the box — eleven engines, hence the name. Config lives in .eleventy.js, a plain Node module. There is no component model forced on you. If your team thinks in server-side templating or plain HTML, Eleventy stays out of the way.

Eleventy moved to ESM-native in v3.0.0 (October 2024) — the runtime is now written in ESM and full ESM support is first-class, but CommonJS is still supported. CJS plugins that load synchronously need await import(), but the runtime cleaned up considerably. Package size dropped from 35.2 MB to 28.1 MB. If you were on v2 and delaying the upgrade, the migration surface is documented and finite.

Astro is opinionated. The .astro single-file component format is JSX-adjacent: familiar the same day for teams coming from React, Vue, or Svelte. Layout components, slot patterns, scoped styles, reactive props — all composable without a separate framework. Astro v5 MDX support brought 2× faster build times vs v4, and you can use JSX components inline in Markdown without a plugin dance. The component model is the value proposition, not a tax.

One thing Astro does that Eleventy cannot match natively: Server Islands. Components marked server:defer compile to separate SSR routes — the page renders immediately with a static fallback, and the island hydrates on load. Stable since Astro v5.0 (December 3, 2024). Eleventy has no equivalent. It is a pure SSG: you would need a separate API endpoint plus client-side JavaScript to achieve the same pattern, and you are stitching it together yourself.

Content and data layer

Astro v5 Content Layer extended what v4 Content Collections could reach. v4 handled local Markdown/MDX in src/content/. v5 introduced a Loaders API — pluggable functions pulling from any source: CMS REST APIs, databases, RSS feeds, flat JSON files. Same getCollection() / getEntry() surface. Community loaders exist for Contentful, Sanity, Storyblok, and Notion. Loaders cache between builds; advanced loaders store last-modified tokens for incremental sync. Astro v6 (March 2026) added live collections — per-request data fetching for hybrid static-plus-dynamic pages.

Eleventy’s data cascade is a 7-level priority system, highest to lowest: computed data → front matter → template data files → directory data files → layout front matter → config global data → _data/*.js global files. The _data/*.js files run arbitrary JavaScript: API calls, DB queries, file parsing, whatever Node can do. Custom Data File Formats API handles YAML, CSV, TOML, and anything else. Deep merging by default; override: prefix to opt out.

The gap has narrowed. Astro’s Loaders API covers most CMS integration scenarios with less setup than Eleventy’s manual approach. But Eleventy’s cascade is more granular for non-standard pipelines: directory-level inheritance lets you set metadata for an entire subtree without touching individual files. There is no equivalent in Astro’s content model.

If your content is in a headless CMS and you want type-safe queries at build time, Astro’s Content Layer is the cleaner path. If your data pipeline is non-standard — mixed formats, directory-level overrides, transforms that don’t fit a loader shape — Eleventy’s _data/*.js gives you full Node control without a framework in the way.

Ecosystem and plugins

Astro has the larger ecosystem: 59,363 GitHub stars as of May 2026 against Eleventy’s 19,642. Native framework integrations (React, Vue, Svelte, Solid, Preact, Lit), an official integration directory, and an active community that ships loaders for most major CMSs. CloudCannon joined as official CMS partner in March 2026. npm packages work directly inside .astro files — the component model makes the ecosystem directly accessible.

Eleventy’s ecosystem is smaller and more specialist. The appeal concentrates in government sites (18F), documentation projects, and developers who want zero framework risk on a long-lived archive. The plugin model is plain Node modules added via addPlugin() — simple to write, but you find fewer ready-made solutions compared to Astro’s integration directory.

Astro v6 (March 2026) shipped an opt-in experimental Rust compiler (experimental.rustCompiler) — a signal of continued investment in build performance. Eleventy v4.0.0-alpha.7 is in canary as of March 2026, with no stable v4 release yet.

Hosting fit

Both tools output static HTML that deploys to any CDN or static host. Cloudflare Pages and Vercel both support both tools on their free tiers.

The substantive difference is what comes after static. Astro ships official adapters for Cloudflare Workers, Vercel Edge, and Netlify Edge Functions. If you start with a static site and later need SSR, Server Islands, or API routes, Astro handles the pivot without a rewrite. Eleventy is pure SSG — adding server-side logic means a separate function layer wired up manually.

For pure static output with no plans to add server-side logic, hosting choice doesn’t differentiate the tools.

Verdict

Pick Astro if:

  • Your team writes TypeScript and expects JSX-adjacent component patterns.
  • Content lives in a headless CMS (Contentful, Sanity, Storyblok, Notion).
  • You need Server Islands — deferred or personalized components on otherwise static pages.
  • You’re building in MDX and want Zod-validated frontmatter schemas.
  • You anticipate adding SSR or API routes later.
  • Your team knows TypeScript conventions and wants the tooling to match.

Pick Eleventy if:

  • Build speed at scale is a hard constraint (1,000+ pages, tight CI minutes).
  • You need zero-JS output with no component compilation overhead.
  • Your data pipeline is non-standard: mixed formats, directory-level inheritance, arbitrary JS transforms.
  • You want a framework-free config model — no JSX, no component model, no build-time magic beyond what .eleventy.js declares.
  • You’re building a long-lived archive where zero framework risk matters more than ecosystem size.

Caveats

The build speed numbers come from Zach Leatherman’s 2022 benchmark (Eleventy 1.0.1, Astro 1.0.1). No direct benchmark comparing Eleventy 3.x to Astro 5.x/6.x is publicly available. The ratios are directional — run measurements on your actual corpus before treating them as a contract.

Eleventy v4.0.0-alpha.7 is in canary as of March 2026. No stable v4 release yet; use v3.1.5 in production.

No affiliate relationship with Astro, Eleventy, Cloudflare Pages, or Vercel.

References