Astro: a content site that ships no JavaScript by default.

What Astro changes, in one sentence

On a React framework, a static page is still a React tree rendered at build time and then rehydrated in the browser, because the runtime has to take over somewhere. So the runtime ships everywhere, including on a text page with no interaction at all.

Astro does the opposite: the page is a template rendered at build time, no JavaScript is shipped by default, and JavaScript only exists inside the islands you explicitly mark as interactive. That is the model described in Astro's official documentation on islands architecture.

On a 40-page site where 38 pages are content, the difference is roughly 166 KB of compressed JavaScript per page. That is a figure we measured in the browser on our own site, not a vendor estimate.

What you get, and what you do not

This is where most Astro pitches go wrong. The gain in bytes is certain. The gain in Core Web Vitals is not, and we would rather say so before selling you a migration.

On our own site, what weighed on mobile LCP was not JavaScript but render delay, 86 to 96% of LCP, meaning CSS and fonts. Both are identical in either framework. An audit before the decision is exactly what prevents that kind of misattribution, and it is what we do in the free site audit.

The trap that cancels the main gain

Almost every site has an interactive header: mega menu, mobile drawer, keyboard focus trap. That component sits on every page. Keep it in React with a hydration directive and React plus its renderer ship on every page again, which takes the Astro gain straight back to zero.

So the condition for the gain is not choosing Astro. It is writing the site shell without a UI framework. Worth knowing before you sign off on a migration: that work is feasible while staying on your current framework, and it then delivers the same gain without rewriting your pages.

Astro or Next.js: the criterion we apply

For a content site, Astro is our default. We move to Next.js only when at least two of the following are true. One is not enough: a contact form, content negotiation for AI agents or three API routes belong perfectly well in Astro endpoints.

• Your conversion tool is a real application: scoring engine, admin area, queue, storage, webhooks. That is no longer a brochure site with a form.
• You reuse React heavily: an existing design system, a component library, shared-state UI across many pages. Porting all of that costs more than the bundle tax you save.
• You need Server Components, streaming or partial prerendering. Astro has no equivalent.
• You serve high-cardinality dynamic content with aggressive revalidation. Doable in Astro, more direct in Next.

If your project looks more like a custom institutional site with heavy integrations than a content site, the answer leans towards Next. If what you mainly want is a credible corporate site that is easy to keep alive, Astro does the job well.

What ports as is, and what has to be rewritten

We checked this table against the official Astro 7 documentation on 30 July 2026. It is the basis we use to price a migration when one is on the table.

Four points drive the pricing. All four are documented by the vendor, and all four are worth reading before you sign anything.

• Content collections: every entry needs a unique id, so data keyed by slug has to be remapped.
• Internationalised routing: the fallback works per route, not per field. A field-by-field merge still has to be written.
• Middleware: it does not run on a prerendered page until an adapter option enables it.
• Server actions: they cannot run on a prerendered page, so forms go through endpoints.

Our own decision, and why it was no

In July 2026 we audited our own site to decide whether it should move to Astro. Verdict: no. Two of the conditions favouring Next were met, our audit tool is a real application with a scoring engine and a token-protected back office, and our pages are already 100% prerendered. Astro would not have changed the rendering model, only the build tool.

We tell that story because it says something useful about how we work: the decision rests on measurements, and it can conclude against the fashionable technology. If you want the detail of the method before trusting us with a project, our approach walks through it step by step.

Moving off WordPress to a prerendered site

This is the most common case. A WordPress install that has piled up plugins, whose back office scares the team, and whose pages take three seconds to appear. Astro solves the technical half, provided the work happens in the right order.

• Inventory of existing URLs and their rankings, before any structural decision
• A 301 redirect plan written and approved before the switch, not discovered after the drop
• Content moved into typed collections, with metadata and internal linking intact
• The shell rebuilt without a UI framework, which is the condition for the real gain
• A no-regression review: titles, descriptions, structured data, sitemap, hreflang

If your team is attached to a familiar back office and performance is not your main problem, a well-run WordPress redesign is often still the better call. We say so when that is the case.