--- title: "Why I migrated my stack from Eleventy to Astro 6" url: "https://alex.zappa.dev/blog/astro6-migration/" description: "Two years on a DIY toolchain, an acquisition that changed the vibe, and why moving FreshJuice to Astro 6 felt like switching from Arch Linux to macOS." --- # Why I migrated my stack from Eleventy to Astro 6 June 22, 2026 * [#astro](/tags/astro/) , * [#eleventy](/tags/eleventy/) , * [#migration](/tags/migration/) , * [#oss](/tags/oss/) Two years ago I [upgraded my site to Eleventy v3](/blog/upgrading-to-eleventy-v3/). The future looked bright. Eleventy (11ty) was lean and fast, and it never tried to have an opinion about how I built things. Then about a year later it landed firmly inside Font Awesome, the icon company where Zach Leatherman (Eleventy’s creator) works. At the time that sounded like good news. More resources, a bigger team, a project that could actually pay its bills. I figured any monetization would show up as an optional add-on, and honestly, fair enough. You build something valuable, you should get paid for it. I don’t want to sound alarmist. But earlier this year the Eleventy possum quietly changed. The classic red balloon got swapped for softer, paler pastels. Then came the announcement: Eleventy as I knew it was being folded into BuildAwesome, part of the bigger Font Awesome platform. Technically nothing was wrong with that. A little seed of doubt got planted anyway. ![The classic Eleventy possum with its red balloon morphing into a corporate BuildAwesome version with a pastel-green balloon](/_astro/11ty-metamarphose.3gBCc9Fw_ZJ42UI.webp) ## What actually stings is the open-source part First, some skin in the game, because it matters for what comes next. I’m not throwing rocks from outside the fence. I back Eleventy on [Open Collective](https://opencollective.com/reatlat), and I’m a listed author in the [11ty community](https://www.11ty.dev/authors/). I’ve shipped sites with it, written about it here, and put money behind it. So when I say the next part, read it as someone who’s invested, not someone looking for a reason to leave. I’ll be honest, I never loved Font Awesome. As a web dev I’ve spent way too many hours explaining to clients that no, you don’t need the whole thousand-icon collection. You’re using five of them. _Five._ That conversation gets old fast. But the icons aren’t really the point. What gets to me is bigger and quieter than that. It’s the drift you can feel across a lot of open source lately. Something starts as a labor of love, the community shows up, and then it usually goes one of two ways. Either it slowly gets abandoned, or it gets pulled toward more and more monetization until the original spirit has worn thin. Almost never in one big dramatic move. It just erodes, a bit at a time. Eleventy doesn’t feel abandoned. But the center of gravity moved somewhere else. The license is still open, BuildAwesome is distributed openly, and I don’t even mind the soft paywalls showing up around the edges. It’s the energy I miss. A year ago the community was everywhere, building things and jumping into each other’s PRs. Now PRs sit for months, and that buzz feels like it’s happening in some other room. Go look at the [community showcase](https://github.com/11ty/11ty-community/issues) right now. There are around thirty open “Built with Eleventy” submissions, people proudly showing off sites they made, and the oldest ones have been sitting there since February with not a single reply. Thirty-odd little “hey, I built this” posts, and nobody’s home to say nice work. That’s the part that gets me. Not a paywall. A room that used to be full and now echoes. And here’s the thing that really made it click: that backlog is exactly what I tried to fix. I opened a [tiny PR](https://github.com/11ty/11ty-community/pull/1023#issuecomment-4655234373) to automate the whole flow, check that a submitted site is genuinely built with Eleventy, then add it to the collection without anyone having to babysit every issue by hand. Zero dependencies, just a few lines of plain Node. I was, honestly, trying to make the maintainer’s life easier and clear that queue. The reply went looking for complexity instead: use an existing utility, `@11ty/find-generator`, which drags in `cheerio` and `sharp` as transitive deps. Reasonable on its own, sure, but the exact opposite of the minimalism Eleventy built its whole identity on. Reach for the library, eat the dependencies. I kept mine dependency-free and left the final call to the maintainer. It’s still sitting there, open, along with everyone else’s. And to be clear, this isn’t a callout. Zach built something genuinely great, and he has every right to make a living from it. It’s closer to grief than anger, if that makes sense. The open-source kind of grief. You watch something you love change shape, and there’s nobody to be mad at, just a direction it’s drifting in. That’s the part that stings. ## On benchmarks and fairness The number everyone keeps quoting comes from [Zach’s build benchmark](https://www.zachleat.com/web/build-benchmark/), and credit where it’s due, it’s a genuinely useful test. But two things about it never quite sat right with me. First, what it actually measures: markdown files and nothing else. No images, no CSS, no pagination. Just how fast each engine turns plain text into HTML. At 4,000 files Hugo finishes in well under a second and Eleventy is the quickest of the JavaScript bunch. Impressive numbers. They’re also nothing like a real site, where the slow part is almost always images and assets, not parsing text. Putting that next to Astro, which comes with image optimization and asset bundling already wired in, is a bit like timing two runners when only one of them is carrying the groceries. Second, and this is the one that really gets me: that benchmark is from 2022. It pits Eleventy 1.0 against **Astro 1.0.1**, a version that had been stable for about three weeks when the test ran. Judging a four-year-old, preview-era Astro and calling the race is like timing a sprinter on their very first day in the sport. Astro 6 is a completely different machine now: Vite under the hood, islands, parallelized builds, image optimization baked in. Here’s what actually got me curious, though, and it wasn’t a livestream. It was migrating [FreshJuice](https://freshjuice.dev) itself. After moving it to Astro I braced for slower deploys, because Astro does more work per build, so surely my Cloudflare build times would climb. They didn’t. They stayed inside the margin of error of the old Eleventy setup. Same ballpark, more features, zero penalty. That mismatch between what the famous benchmark implied and what my own deploy logs showed is the whole reason I went and measured it properly. So I built my own, [open and reproducible](https://github.com/reatlat/ssg-benchmarks). Same content for every engine, generated from a fixed seed, with the real ingredients this time: 500 posts, images processed into responsive variants, Tailwind, pagination, tags. Then I timed cold, warm, and incremental builds, five runs each, on an M3 Max with the whole CPU off the leash. And the result genuinely surprised me. On a cold build, the one CI runs every single time you deploy, Astro was the fastest of all three: 27 seconds, ahead of Eleventy (34s) and even ahead of Hugo (31s). Hugo’s legendary speed is real, but it’s _markdown-parsing_ speed. The moment you make every engine resize the same images into responsive variants, that lead evaporates, because now the bottleneck is image processing, and Astro’s sharp pipeline happily spreads across all 16 cores. Eleventy takes its wins where it always has: warm and incremental rebuilds (around 2.3s versus Astro’s 4s) and memory, where it peaked at 319 MB while Astro climbed to nearly a gigabyte. So this isn’t a knockout in either direction. It’s trade-offs. Astro does far more work per build and still wins the build that matters most for shipping; Eleventy stays lean and snappy on the local save-and-refresh loop. One honest caveat, and it’s the whole point of this post: those numbers are from a 16-core M3 Max with nothing throttled. Cap the cores the way a real CI builder does, and the picture shifts again. So I re-ran the exact same benchmark inside the resource limits of a Cloudflare build container (Free is 2 vCPU, Paid is 4 vCPU, both 8 GB). Here’s the cold build, the one that runs on every deploy, as the mean of five runs: Environment Eleventy Astro Hugo M3 Max — 16 cores, unthrottled 33.9s **27.1s** 30.9s Cloudflare Paid — 4 vCPU / 8 GB 45.4s **35.6s** 53.0s Cloudflare Free — 2 vCPU / 8 GB **58.4s** 66.3s 106.1s And there it is. Hand Astro all 16 cores and it wins outright, because its image pipeline parallelizes beautifully. Squeeze it down to the 2 vCPUs a free CI runner actually gives you, and the advantage flips: Eleventy retakes the cold build (58s vs 66s) because it isn’t relying on parallelism it no longer has. Hugo, the supposed speed king, falls off a cliff once it has to resize real images on two cores. This is exactly why a benchmark on 4,000 empty files tells you almost nothing about your actual deploy. The hardware budget changes the winner. Warm rebuilds tell a calmer story. This is the local save-and-refresh loop, and here the lighter runtimes stay ahead no matter how many cores you give them: Environment Eleventy Astro Hugo M3 Max — 16 cores, unthrottled 2.4s 4.4s **1.9s** Cloudflare Paid — 4 vCPU / 8 GB 2.5s 4.3s **1.6s** Cloudflare Free — 2 vCPU / 8 GB 2.6s 4.9s **2.1s** Notice how little these move. Warm rebuilds barely care about core count, because there’s no big image batch to parallelize, so Astro’s Vite layer just carries a bit more constant overhead (5s versus 2s). Incremental rebuilds tracked these almost exactly. Memory was the one axis that never flipped in any environment: Eleventy held around 320–380 MB throughout, while Astro lived close to a gigabyte. Pick your trade-off. ## DIY vs. done Using Eleventy these days feels like running Arch Linux. Here are your ingredients, now go build your own engine. And I mean that with love. I ran Linux as my daily driver until 2017 (btw, I use Arch). But you know the thing about Linux on the desktop. You burn real hours fixing whatever broke after an update, or trying to work out why something that obviously should work just… doesn’t. Astro 6 is the macOS version of that. It just works. You get full control and everything out of the box at the same time. When there’s client work to ship, you don’t have time to debug your own operating system. You need it to get out of the way. ![PageSpeed Insights score for this site running on Astro 6 — all 100s](/_astro/astro-speed.rHwfT3fW_2g3KrX.webp) The Islands architecture on its own basically sold me. I don’t have to sit there thinking about what loads on the frontend versus the backend, because Astro handles it natively. No workarounds, no ceremony. Want a CMS down the line? Bolt on something like [CloudCannon](https://cloudcannon.com/) and you’ve got an actual deliverable to hand a client. I still like working with files directly, but the real thing is this: I just don’t want to spend my life on build tooling anymore. With Astro it’s faster and simpler, and that’s enough. That’s the real reason [FreshJuice](https://freshjuice.dev) moved over. I’d run into a couple of genuine growth and scaling questions, and staying on Eleventy meant piling up technical debt just to answer them. (I’d already [come to 11ty from WordPress](/blog/migrating-from-wordpress-to-11ty-enhancing-website-performance-and-control/) years back, so this wasn’t a decision I took lightly.) Astro was just the cleaner bet. To be clear, I’m not ripping Eleventy out of everything I own. For a lot of my projects it’s still the perfect tool, and I have zero plans to touch them. This isn’t a breakup, it’s one project outgrowing one stack. What I am doing is watching its future with a pretty skeptical eye. And going forward, new projects are Astro by default. I’m done spending evenings hand-wiring a build pipeline and babysitting plugin configs just to land where Astro already starts. The fiddling was fun once. Now I’d rather ship. ## A bet on the future Earlier this year Cloudflare bought Astro, and this is where I get genuinely optimistic. I [already run my stack on Cloudflare](/blog/cloudflare-pages-to-workers-migration/), and they’ve spent years pushing the web to be faster and more open. With them behind it, I think Astro can pull off something I didn’t expect to find myself rooting for. It could actually challenge, or at least seriously rattle, the reigning king of websites: WordPress. Pair Astro with whatever CMS the team is cooking up, and that future feels a lot closer than it has any right to. ![A purple Astro rocket lifting off into the sky as a cartoon Eleventy possum waves goodbye from the ground](/_astro/astro-liftoff.B14B3UTZ_jf2qX.webp) I’m rooting for them. Moving [FreshJuice](https://freshjuice.dev) to Astro was the right call. No regrets. **Benchmark repo:** [github.com/reatlat/ssg-benchmarks](https://github.com/reatlat/ssg-benchmarks) May the 4th be with you, Alex * [Previous HubSpot's Cookie Banner Loads Google Fonts - And Nobody Seems to Care](/blog/hubspot-cookie-banner-google-fonts-gdpr/)