Why we ship Astro for almost every client website

Most agencies pick a stack and defend it forever. We pick stacks that earn their place every quarter, and Astro has earned its place across our portfolio for a specific reason: it ships.

We use Astro for marketing sites, content-heavy projects, comparison sites, and anywhere the page is more important than the application. Here’s the working theory, the reasons it holds up, and the cases where we still reach for something else.

What Astro is doing differently

Astro renders to static HTML by default and treats interactivity as the exception, not the rule. You write components - including React, Vue, Svelte, or its own .astro syntax - and Astro decides what ships to the browser. If a component never needs to update on the client, Astro emits zero JavaScript for it.

That sounds like a small detail. In production it’s a category change. A typical Next.js marketing site ships a few hundred kilobytes of framework runtime to render content that never changes after the first paint. An equivalent Astro site ships nothing.

The real reasons we keep choosing it

The performance argument writes itself. The reasons we actually pick it for clients are operational.

Build times stay reasonable as content grows. We have one project with several hundred pages of content, and full builds finish in under thirty seconds. That matters because the deploy loop is the real bottleneck on most teams - if your build takes ten minutes, nobody is shipping a quick copy fix at 4 PM on Friday.

The content layer is the actual product. Astro 6’s content collections give us typed Markdown and MDX with a clean schema definition, a single source of truth for frontmatter, and a build-time validation step that catches editor mistakes before they hit production. We have headless CMS plugged in on top of that for non-developer authors, and the content collection schema doubles as the CMS field config.

Cloudflare Pages deploys are essentially free at our scale. Push to main, GitHub Actions builds the static output, Pages serves it from the edge. No servers to manage, no autoscaling to budget. For a marketing site, this is the entire infrastructure conversation.

Where we don’t use it

Astro is not the right call for everything. Heavy authenticated apps, real-time dashboards, and anything where most of the work happens after page load - those still go to Next.js or a Laravel backend with an Inertia/React frontend, depending on the team.

We’ve also found that very interactive product pages - configurators, complex pricing calculators, multi-step builders - sometimes earn their JavaScript runtime fairly. Astro can host these with islands, but if islands grow to be the majority of the page, you’re using the framework against its design.

The pattern we’ve settled on

For a typical client project we ship Astro + Tailwind + Cloudflare Pages + a CMS for non-technical editors. That stack solves the marketing site problem completely, runs on free tiers up to traffic levels most clients will not hit for a year, and produces a Lighthouse score that closes deals on its own.

If we’re adding e-commerce, we plug in Medusa as a separate service and let Astro consume it as data at build time, with islands handling the cart. If we’re adding AI features, those go behind an API the static site calls.

The lesson, honestly, is just that boring infrastructure wins. Astro on Pages is boring infrastructure. It builds, it deploys, it serves. Our clients don’t have to think about it.

When you might want our help

If you’re sitting on a WordPress site that takes seven seconds to load, or a custom React build whose deploy pipeline you no longer trust, this stack is worth a conversation. We do migrations, greenfield builds, and ongoing content engineering for marketing-led businesses.