Astro vs 11ty: A CTO’s decision guide for content sites, docs, and marketing

Astro vs 11ty: A CTO’s decision guide for content sites, docs, and marketing

Astro’s adoption jumped from 29 active domains in July 2021 to 38,861 at peak in April 2025, a 1,340x increase. Curves like that change hiring pools and vendor bets. At the same time, Eleventy still puts blunt build numbers front and center, like 1.93s to build 4,000 Markdown files in a benchmark Eleventy cites. Astro shows 22.90s in the same table. Momentum and speed don’t always point in the same direction, and that’s why the decision gets messy.

My thesis is simple: pick Astro when you want component-driven UI and selective interactivity with strong defaults. Pick 11ty when you want fast builds, minimal dependencies, and long-lived content pipelines you can reason about.

Astro vs 11ty: what are you really choosing?

Astro and Eleventy both generate static HTML. Both can pull content from Markdown, APIs, or a headless CMS. Astro’s own migration guide calls out those similarities, and it also highlights the big differences in structure and asset handling Astro migration guide from Eleventy.

The real choice isn’t “framework A vs framework B.” The real choice is how much structure you want the tool to impose, and how much you want your team to invent.

Astro gives you:

• Component-first templating with .astro files and scoped styles.
• Islands architecture so you ship zero JS by default, then hydrate only interactive parts.
• Bundled asset pipeline out of the box, including CSS and JS handling Astro migration guide from Eleventy.
• Framework interop so React, Svelte, Vue, and others can live inside a mostly static site.

Eleventy (11ty) gives you:

• Many template languages so teams can keep Liquid, Nunjucks, Handlebars, or plain JS templates.
• A smaller dependency footprint and faster installs in common comparisons, like 34 MB node_modules weight in Eleventy’s cited table Eleventy performance docs.
• A build pipeline you assemble instead of a pipeline you inherit.

CloudCannon’s comparison frames the core trade: Eleventy’s template decoupling makes migrations easier, while Astro’s component model makes reuse and UI composition easier CloudCannon: Eleventy vs Astro.

Here’s the crisp framing I use with teams: Astro is a product with a golden path. 11ty is a toolkit.

Performance and build times: what matters in production

Most CTOs I talk to over-index on Lighthouse scores and under-index on build pipelines. Both matter. They just fail in different ways.

Runtime performance and user experience

Astro’s pitch is straightforward: ship less JavaScript. A comparative study summarized Astro’s islands model as a hybrid strategy that keeps static output while loading interactive components only where needed, and it reported an 83 percent score for Astro in its evaluation Comparative study: React, Astro, Eleventy.

Third-party benchmark roundups claim extreme results for Astro, like Lighthouse performance 100 and Time to Interactive 0.3s in one Sparkbox comparison cited by TechnologyChecker TechnologyChecker: Companies using Astro. I treat those numbers as directional, not a promise. A content site with three islands behaves nothing like a docs site with search, tabs, and client-side navigation.

Eleventy can also hit 95 to 100 Lighthouse scores, since it outputs static HTML with no required client runtime. Index.dev summarizes that pattern and calls out near-instant page loads for pure static output Index.dev comparison.

The runtime question I’d actually ask is: how often will teams add JS, and how hard is it to keep that under control? Astro makes the default safer.

Build times and CI throughput

Build time turns into real money when you run CI 200 times per day. Build time also shapes behavior. Slow builds push teams to skip checks.

Eleventy leans into build performance and publishes benchmark tables. One table Eleventy cites shows:

• Eleventy: 1.93s to build 4,000 Markdown files
• Astro: 22.90s to build 4,000 Markdown files

Eleventy attributes the data to a July 2022 benchmark, and the docs keep the numbers visible for a reason Eleventy performance docs.

A more “real world” test from Piper Haywood used 770 posts and about 2,550 pages. The average of 10 builds came out to:

• Astro: 10.07 seconds
• Eleventy: 4.29 seconds

Piper also tested incremental builds and reported 2.17 seconds for Eleventy in that setup, with caveats about pagination and CI support Piper Haywood benchmark.

Build speed isn’t just comfort. Build speed is release frequency, preview environments, and cost.

If your marketing team expects a preview link for every PR, a 20 second build can be fine. If your docs repo gets 300 PRs per week, build time becomes a bottleneck fast.

Dependency weight and supply chain risk

Eleventy’s performance page also cites install-time comparisons. The table lists 34 MB node_modules weight for Eleventy and 169 MB for Astro, with Astro taking 12.52s in that cited install test Eleventy performance docs.

Dependency weight isn’t a moral issue. Dependency weight is risk and maintenance cost. More packages means more CVEs, more lockfile churn, and more “why did CI break” mornings.

Developer experience and team fit: the hidden cost center

Tool choice turns into org design. The wrong tool forces a team shape you didn’t plan.

Component model vs template freedom

Astro’s component model wins hearts. Random Geekery called out “component-based design” and the joy of keeping styles next to markup, while still writing CSS Starting 2025 with Astro.

Eleventy’s template freedom wins pragmatists. CloudCannon points out that Eleventy supports many template languages, and that decoupling reduces lock-in CloudCannon: Eleventy vs Astro.

A CTO-level read looks like this:

• Astro fits teams that already think in components, design systems, and UI reuse.
• 11ty fits teams that want simple HTML output and a content pipeline that survives staff changes.

Golden paths and off-road costs

Astro has explicit structure. Random Geekery described that as both a pro and a con. The same post also warned that once you step off the golden path, you end up in forums and repos hunting for clues Starting 2025 with Astro.

That off-road cost matters. A tool with a strong happy path can still burn weeks on edge cases.

Eleventy has fewer guardrails, so teams build their own trail. That sounds risky, but it also means the team owns the mental model. Wavebeem’s “migrate to Astro and back” story captures the vibe. The author needed a weekend of real work to feel the tradeoffs, and ended up back on Eleventy for fit Becoming an Astro-not.

One question decides a lot: do you want your site to feel like a small app?

If the answer is yes, Astro’s component model and integrations pay off. If the answer is no, 11ty’s simplicity keeps you honest.

Content modeling and information architecture

Astro’s content collections show up often in migration stories. Stephan Max switched from Eleventy to Astro for a notes workflow that emphasizes updates over publish dates. The switch took “a couple of hours”, and content collections helped unblock a specific Eleventy limitation around WebC and permalink: false Stephan Max migration.

That example matters because it’s not about speed. It’s about content semantics.

If your company runs a docs site with versioned content, changelogs, and “last updated” sorting, content modeling becomes a product feature. Astro has a clearer story there.

A CTO decision matrix for Astro vs 11ty

Most comparison posts stop at features. CTOs need a repeatable call that survives debate.

Here’s a link-worthy element you can reuse with your staff.

The STATIC decision matrix

I use a simple model called STATIC. Each letter is a factor you can score 1 to 5.

• S, Speed of builds: CI minutes, preview links, local rebuild time.
• T, Team familiarity: component mindset, template language comfort, TypeScript comfort.
• A, Asset pipeline needs: images, CSS bundling, MDX, search indexing.
• T, Templating lock-in risk: how hard a future migration will be.
• I, Interactivity footprint: how much client JS you expect in 12 months.
• C, Content complexity: collections, versioning, “last updated”, multi-language.

Score Astro and 11ty side by side. Then write down the top two factors. The top two factors decide the tool.

A quick comparison table

What top-ranking pages miss

Most pages treat this as developer preference. CTOs should treat it as a portfolio decision.

A marketing site, docs site, and blog aren’t “small.” Those properties drive pipeline load, brand trust, and support deflection. A slow docs build can slow product releases.

Enterprise implications: why this matters for CTOs

1. Your content stack becomes a release system. Docs and marketing ship daily at many companies. A 2x build time difference can show up as fewer preview environments and slower approvals. Piper Haywood’s 10.07s vs 4.29s numbers look small, until you multiply by hundreds of runs Piper Haywood benchmark.

2. Hiring and internal mobility follow ecosystem gravity. State of JS 2025 put Astro at the top of meta-framework satisfaction with a 39 point lead over Next.js, as summarized by Strapi State of JavaScript 2025 summary. Satisfaction correlates with what engineers want to work on. That affects retention.

3. Supply chain and maintenance costs scale with dependencies. Eleventy’s cited install table shows smaller node_modules weight than Astro Eleventy performance docs. Smaller dependency graphs reduce patch churn and security review load.

4. Design systems either thrive or rot. Astro’s component model makes it easier to ship a shared header, nav, and callouts across 20 microsites. Eleventy can do it too, but teams often reinvent partials in different template languages.

CTO recommendations: how to make the call and execute

Immediate actions

1. Run a two-day spike with real content. Use 200 to 1,000 Markdown files, not a starter template. Measure local build time, CI build time, and preview deploy time. Piper Haywood’s test used 770 posts and 2,550 pages, and that scale exposed differences fast Piper Haywood benchmark.

2. Set a Lighthouse budget and a JS budget. Use Lighthouse in CI and fail builds on regressions. The comparative study and benchmark roundups both point to performance wins from shipping less JS Comparative study.

3. Pick one interactivity pattern and standardize it. Astro teams should define islands rules, like “no client hydration on docs pages unless product requires it”. 11ty teams should define how JS bundles get built and loaded.

4. Decide who owns the site as a product. A docs platform needs a roadmap, not a repo. Assign a named owner and a quarterly plan.

If you need a place to track the decision and the follow-on work, use Command Center (/command-center) to log the migration, risks, and SLOs for build and deploy.

Policy framework

1. Build vs buy for content editing: Use a headless CMS only when non-engineers publish weekly. Use our Build vs Buy Matrix (/tools/build-vs-buy-matrix) to make the call with cost and risk on paper.

2. Dependency policy: Set a rule for new packages, like “one new dependency needs one owner and one update plan”. Astro’s ecosystem can tempt teams into integration sprawl.

3. Performance policy: Track DORA-style lead time for content changes. Use our Engineering Metrics Dashboard (/tools/engineering-metrics-dashboard) to keep the pipeline honest.

Architecture principles

1. Content as data: Store content in Git, model it explicitly, and generate feeds and indexes from the same source. Astro content collections can help, and Eleventy’s data cascade can help too. The key is consistency.

2. Static first, dynamic last: Keep the default output static. Add interactivity only for search, auth, or embedded tools. Astro’s islands model makes that easier to police.

3. Fast builds as an SLO: Set a target like “CI build under 5 minutes” and “local rebuild under 5 seconds for a single page change”. Eleventy’s incremental build story still has CI gaps, so test your own pipeline early Piper Haywood benchmark.

4. Document the golden path: Random Geekery’s warning about off-road docs is real Starting 2025 with Astro. Write your own internal guide for the 10 things engineers do weekly.

For architecture documentation, map the content platform and its integrations in ArchiMate Modeler (/tools/archimate). A simple model helps when marketing, product, and engineering all touch the system.

And when the site breaks at 2 a.m., run a clean review. Use our incident postmortem template (/tools/incident-postmortem) and treat the docs pipeline like production.

Bigger picture: content stacks are becoming product stacks

State of JS 2025 also noted that the average developer has used only 2.6 frontend frameworks in their career, as summarized by Strapi State of JavaScript 2025 summary. Teams don’t switch tools every quarter. A static site generator choice can last five years.

Astro’s momentum and satisfaction numbers suggest a long runway. Eleventy’s speed and simplicity suggest a long half-life. Both can be true.

So the question to answer is practical: does your org want a content platform that behaves like a small app, with components and selective hydration, or a content pipeline that behaves like a build tool, with minimal moving parts? Pick the one that matches your team’s habits and your release cadence.

Sources

1. Starting 2025 With Astro, Random Geekery
2. Comparative Study of React, Astro and Eleventy, SCIRP
3. Companies Using Astro in 2026, TechnologyChecker.io
4. State of JavaScript 2025: Key Takeaways for Dev Teams, Strapi
5. Eleventy (11ty) vs. Astro, CloudCannon
6. Why I Switched from Eleventy to Astro, Stephan Max
7. Becoming an Astro-not, wavebeem
8. Migrating from Eleventy, Astro Docs
9. Inexactly benchmarking Eleventy vs Astro build times, Piper Haywood
10. Performance, Eleventy Docs
11. Astro vs Next.js vs Eleventy: Framework Comparison 2026, Index.dev