Why we chose Astro for our corporate website

The problem we needed to solve

When we decided to rebuild the abemon corporate site, we had a clear set of requirements. The site needed to be fast, SEO-friendly, bilingual (Spanish and English), easy to maintain by developers who primarily work in React, and cheap to host. It also needed to look professional without requiring a dedicated frontend team to keep it running.

We had been running WordPress for years. WordPress works, but it carries overhead that is hard to justify for a content-focused corporate site: plugin updates, security patches, database management, caching layers, and the constant tension between theme flexibility and performance. We wanted something simpler.

The obvious candidates were Next.js, Gatsby, and Astro. We evaluated all three seriously. We chose Astro, and after six months in production, we are confident it was the right call.

The SPA framework problem for content sites

Next.js is an excellent framework. We use it for foodplan.pro, where server-side rendering, API routes, and dynamic interactivity justify the complexity. But for a corporate site that is 95% static content with a contact form and a few interactive components, Next.js introduces overhead that solves problems we do not have.

The fundamental issue is hydration. When Next.js serves a page, it ships the full React runtime plus the JavaScript for every component on the page. The browser downloads the HTML, renders it, then downloads and executes JavaScript to “hydrate” the page and make it interactive. For a blog post or a services page, this hydration step adds weight and latency for zero user-visible benefit. The page was already readable from the server-rendered HTML.

Gatsby pioneered the static site generation approach but accumulated complexity over time. Its build system, GraphQL data layer, and plugin ecosystem create a learning curve and maintenance burden that is disproportionate for a corporate site. Build times for Gatsby sites with image processing can stretch to minutes, which slows iteration.

Both frameworks optimize for applications that need rich client-side interactivity. A corporate website is not that. It is a content delivery problem with occasional interactivity.

What Astro’s island architecture solves

Astro’s core insight is simple: ship zero JavaScript by default. Every page is rendered to static HTML at build time. JavaScript is only shipped for components that need it, and only when they need it. Astro calls this “islands architecture” because interactive components are islands of JavaScript in a sea of static HTML.

In practice, this means our services pages, insight articles, team bios, and legal pages ship zero kilobytes of JavaScript. The contact form ships a small React component that hydrates on visibility. The cookie consent banner ships a tiny script that loads on interaction. Everything else is pure HTML and CSS.

The performance impact is dramatic. Our homepage ships 0 KB of client JavaScript compared to approximately 180-220 KB that a typical Next.js page would ship for the React runtime alone. First Contentful Paint is under 0.5 seconds on mobile. Largest Contentful Paint sits at 0.8 seconds. Total Blocking Time is effectively zero for static pages. These are not lab numbers. These are field data from Chrome User Experience Report.

Our Core Web Vitals scores are consistently green across all pages. This matters for SEO. Google has been clear that page experience signals, including Core Web Vitals, influence search ranking. For a corporate site competing for visibility on terms like “managed services” or “digital transformation consulting,” every ranking factor counts.

Content collections for bilingual management

Astro’s content collections feature solved our bilingual content challenge elegantly. We define a schema for each content type (insights, services, case studies) using Zod validation. Each content piece is a Markdown file with typed frontmatter. The build system validates every piece of content against the schema at build time.

Our directory structure mirrors our language strategy:

src/content/insights/
  es/
    agentes-ia-produccion.md
    por-que-elegimos-astro.md
  en/
    ai-agents-production-lessons-learned.md
    why-we-chose-astro-corporate-website.md

Each file has a lang field and a slug field. We link translations through matching slugs or explicit references. The build system generates routes for both languages with proper hreflang tags for SEO. Adding a new article in either language is a matter of creating a Markdown file with the correct frontmatter. No CMS login, no database, no deployment pipeline beyond a git push.

The Zod schema validation catches errors before they reach production. If someone forgets a required field or uses an invalid category value, the build fails with a clear error message pointing to the exact file and field. This is a significant improvement over WordPress, where content validation is either nonexistent or requires custom plugin development.

Developer experience wins

Our engineering team works primarily in TypeScript and React. This was a potential concern with Astro because Astro has its own .astro component format. In practice, the transition was seamless for three reasons.

First, Astro components use a syntax that is immediately familiar to anyone who has written JSX. The frontmatter section at the top of an .astro file is standard TypeScript. The template section below is HTML with expression slots. There is almost no learning curve.

Second, Astro supports React components natively through its integration system. We use React for interactive components: forms, modals, dynamic filtering. These components are written in standard React with TypeScript, tested with standard tools, and dropped into Astro pages with a client:visible or client:load directive. We get the React ecosystem (component libraries, hooks, testing patterns) without paying the runtime cost on every page.

Third, the developer experience for content authoring is excellent. Markdown with frontmatter is a format every developer knows. VS Code provides syntax highlighting and validation. The build gives immediate feedback on errors. There is no context switching between a CMS interface and code. It is part of our custom development philosophy applied even to our own web infrastructure.

Build times deserve mention. Our full site builds in under 8 seconds. Incremental builds during development are near-instant. Compare this to Gatsby builds that routinely hit 60-90 seconds for similar content volumes, or Next.js builds that grow linearly with page count. Fast builds mean faster iteration and shorter deployment cycles.

Honest assessment of tradeoffs

Astro is not the right choice for every project, and we should be clear about the tradeoffs.

Dynamic content limitations. Astro is optimized for static and server-rendered content. If you need real-time data, client-side routing, or complex application state, you will either fight the framework or end up shipping React anyway. For those use cases, Next.js or a full SPA is the better tool.

Smaller ecosystem. Astro’s plugin and integration ecosystem is growing but smaller than Next.js or Gatsby. We have not encountered a blocking gap, but teams that depend on specific third-party integrations should verify compatibility before committing.

Server-side rendering maturity. Astro’s SSR mode is functional but younger than Next.js’s. For our use case (static site with build-time rendering), this does not matter. For sites that need request-time rendering, Next.js has a more mature story.

Community size. When you hit an obscure issue with Next.js, there are thousands of Stack Overflow answers and GitHub discussions. Astro’s community is engaged and helpful but smaller. We have had to read source code a few times to resolve edge cases.

Team hiring. “We use Astro” is less recognizable on a job listing than “We use Next.js.” In practice, any competent frontend developer can be productive in Astro within a day, but it is worth acknowledging the perception gap.

The result

Six months in, the abemon.es site runs on Astro deployed to Cloudflare Pages. Hosting cost is effectively zero. Build and deploy takes under 30 seconds end to end. Performance scores are consistently in the 95-100 range on Lighthouse. Content updates are a git commit away. The site serves two languages with proper SEO markup, structured data, and sitemap generation.

For a corporate website that prioritizes performance, SEO, and maintainability, Astro delivers exactly what we needed without the complexity we did not. It is not the right tool for every project. But for this specific problem, it is the best tool we have found. If you are facing a similar framework decision or a broader build vs buy question, the key criterion is the same: choose the tool that best fits the problem, not the most popular one.