Why we rebuilt our website with Astro
Field report: migrating from WordPress to Astro. Measured performance, DX, SEO and the i18n traps we hit.
WordPress served its time well. For years it was the obvious choice for a brochure site: mature ecosystem, plugins galore, easy hosting. But in 2026, when your website is meant to prove your technical expertise, running WordPress + Avada + WooCommerce just to serve six pages of text gets hard to justify. Here’s what the migration taught us, with the numbers to back it up.
The problem with our old stack
Our WordPress site posted mediocre mobile performance: a Lighthouse score of 56 on mobile, but above all a brutal LCP north of 12 seconds (measured under Slow 4G throttling), a TTFB around 550ms and more than 2.5MB of resources per page. For a digital studio that sells performance as its core pitch, that was a serious credibility problem.
That TTFB tells the rest of the story. Every WordPress page — even an “About” page that never changes — is rebuilt on demand: PHP spins up, queries MySQL, assembles the theme and its plugins, then returns the HTML. That server work is paid on every single visit. When performance is what you’re selling, shipping half a second of latency before the first byte is simply untenable.
But beyond the score, the day-to-day was painful:
- WordPress and plugin updates to babysit constantly (security)
- The Avada visual editor: an over-engineered mess just to edit a paragraph of text
- No content versioning
- No modern development workflow (no Git-based staging)
Why not Next.js or Nuxt?
The question came up, and it deserved a real answer. Next.js is excellent for React apps with heavy interactivity — a dashboard, a SaaS product, a dynamic checkout flow. But for a mostly static site with a blog, it’s overkill: you ship a client-side React runtime to hydrate pages that, in practice, barely react to anything. The result is JavaScript downloaded and executed on the visitor’s phone just to render text that could have stayed plain HTML.
Astro starts from the opposite premise, and that’s what settled it for us.
Islands Architecture, in practice
Astro’s principle fits in one sentence: zero JavaScript by default. Every .astro component is rendered to HTML at build time and shipped as-is to the browser. No framework runtime on the client, no global hydration.
The handful of genuinely interactive zones — in our case the GSAP animations and the contact form — become “islands”: isolated fragments you hydrate explicitly with a directive (client:load, client:visible, client:idle). The rest of the page stays static. You only pay the cost of JavaScript where it actually earns its keep, and client:visible even lets you defer hydration until the island scrolls into the viewport. That’s exactly the model a site that’s 95% content and 5% interaction needs.
Content Collections + Zod: a typed blog
The other decisive building block is the Content Collections system. You declare a frontmatter schema with Zod, and Astro validates every Markdown file at build time:
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
schema: z.object({
title: z.string(),
description: z.string().max(160),
pubDate: z.date(),
featured: z.boolean().default(false),
}),
});Concretely: an article with no title, a malformed pubDate, or a description too long for SEO fails the build instead of shipping to production. Frontmatter becomes typed in code, autocompletion works, and you eliminate an entire class of bugs that, under WordPress, only surfaced once the page was already live.
What we gained
Before and after, measured with the same protocol (Lighthouse mobile, Slow 4G throttling, median of 3 runs):
| Metric (mobile) | WordPress | Astro |
|---|---|---|
| Lighthouse Performance | 56 | 93 |
| LCP | 12.2s | 2.42s |
| TTFB | 557ms | 32ms |
| Total weight | 2.56MB | 300KB |
That’s a Lighthouse score climbing from 56 to 93, an LCP 5× faster, a TTFB cut by roughly 17×, and nearly 9× less weight transferred. Figures captured on May 30, 2026 on the Astro build (Lighthouse CLI, home page) — no promises without measurement.
The TTFB drop from 557ms to 32ms is no magic trick: it’s the move from on-demand PHP/MySQL rendering to pre-generated HTML files served straight by nginx. No database in the loop, no interpreter to boot — just a static file returned from disk. Most of the LCP and weight gains come from the same root cause: we no longer ship the JavaScript and CSS of half a dozen plugins just to render a page.
The surprises
The good surprise: TailwindCSS 4 with its CSS-native API is a revelation. No more JavaScript config file — design tokens live directly in the CSS via @theme. The Astro integration is native and the build is blazing fast.
The less pleasant surprise: i18n. Astro ships built-in i18n routing, but for cross-language redirects with different slugs (/realisations ↔ /portfolio) you still have to wire the logic yourself. The default routing assumes identical slugs across locales; the moment you want genuinely localized URLs (better for SEO and sharing), you have to build the mapping table and the hreflang tags by hand. Nothing insurmountable, but worth planning for if multilingual is central to your project.
The DX in practice
The day-to-day workflow comes down to a few concrete things. .astro components blend a TypeScript frontmatter with HTML: props are typed, asset imports are typed too, and a type error shows up in the editor before you even trigger a build. Hot-reload is instant — you save, and the browser reflects the change without a full reload. On styling, Tailwind 4 needs no config file at all: you declare your tokens in a @theme block in the CSS and that’s it. And thanks to Content Collections, adding an article is just dropping a Markdown file — the schema validates it, the page generates itself, nothing to wire up by hand.
Should you migrate?
If your site is a heavily interactive app, Next.js or Nuxt are still the right tools. But if you run a brochure site, a blog, or a marketing site — in other words a lot of content and little interaction — Astro is today the most rational choice, and our own numbers back it up.
Want to know what a static stack would do for your current site? Ask us for a performance audit: we measure your Lighthouse, your LCP and your TTFB, and tell you honestly whether a migration is worth it. Curious what that looks like in production? Have a look at our work and our services.