Astro vs Next.js: the stack we're betting on for immersive websites (with Sanity)

Most marketing websites don't need custom code, that's why we build on Framer. But some projects hit a ceiling: shader-level creative control, WebGPU rendering, complex data visualization, performance budgets that leave no room for compromise. For those, our stack of choice is Astro for the site, Sanity for the content, Three.js for the experience. Here's why, and, just as honestly, when we'd still talk you out of it.

What Astro actually does differently

Astro inverts the default of modern JavaScript frameworks. Instead of shipping your entire site as a JavaScript application that the browser must download, parse and execute before anything works, Astro ships plain HTML by default, zero JavaScript, and hydrates only the components that genuinely need interactivity.

This is called the islands architecture: your page is a static, instantly-renderable document, with isolated "islands" of interactivity, a 3D scene, a configurator, a form, that load independently, when needed. Each island even controls its own loading strategy: hydrate immediately, when the browser is idle, or only when the component scrolls into view. A visitor reads your content immediately; the JavaScript arrives only where it earns its place, exactly when it earns it.

The practical consequence: on an Astro site, adding a spectacular 3D section to your homepage doesn't slow down your pricing page, your blog, or even the rest of the homepage. On an SPA-style architecture, everything shares the same JavaScript budget. That isolation is the single most important idea in this article.

Astro vs Next.js: the honest comparison

Next.js is an excellent framework, for applications. Dashboards, authenticated products, heavily stateful interfaces: that's its territory, and we wouldn't use Astro there. But Next.js makes React the foundation of every page, which means hydration costs everywhere, even on pages that are 95% static content.

The numbers make the trade-off concrete:

• Real-world Core Web Vitals: Astro sites pass CWV at roughly 66% in HTTP Archive production data — among the highest aggregate rates of any framework. Marketing sites built as SPAs sit far below.

• JavaScript payload: a 2026 side-by-side test measured ~9 KB of JavaScript for an Astro page against ~463 KB for the Next.js equivalent, a 50× difference the visitor's phone has to process.

• Even Vercel, the company behind Next.js, acknowledges in its own comparison that content-driven sites are where Astro's model shines.

Criterion by criterion

• Rendering model: Astro is server-first and static-first, HTML is the default, JavaScript the exception. Next.js is React-first, even with Server Components, the framework assumes an application shell.

• JavaScript on a typical page: Astro ships kilobytes; Next.js ships a React runtime plus your components. On content pages, most of that runtime does nothing the visitor can perceive.

• Framework flexibility: Astro islands can be written in React, Vue, Svelte or vanilla Three.js, per component. Next.js is React, everywhere, forever.

• Hosting: an Astro site exports to static files deployable anywhere (and cheaply), Cloudflare, Netlify, a plain CDN. Next.js increasingly assumes Vercel's infrastructure for its full feature set.

• Learning curve and maintenance: an Astro codebase for a marketing site stays small and legible; there is simply less machinery to maintain, upgrade and debug.

• Where Next.js wins: authenticated apps, complex client state, real-time interfaces, product dashboards. If the product is the interface, use Next.js. No contest.

Our rule of thumb: if the product is the interface (an app), Next.js. If the site's job is to present, convince and convert, a marketing site, however immersive, Astro wins on physics alone.

Core Web Vitals, metric by metric

"Astro is fast" is an abstraction. Here is what the architecture does to each of Google's three Core Web Vitals, the metrics that feed both your rankings and your bounce rate:

• LCP (Largest Contentful Paint): your hero, headline, image, poster, is in the initial HTML, styled and visible before any JavaScript runs. No hydration gate between the visitor and your first impression. This is the exact failure mode we see most often when auditing JavaScript-heavy sites: content that exists but waits for a script to reveal it.

• INP (Interaction to Next Paint): INP degrades when the main thread is busy running JavaScript. With islands, the main thread is mostly idle, there's almost nothing to run. Clicks, scrolls and menu taps respond instantly because nothing is competing for the CPU.

• CLS (Cumulative Layout Shift): layout shifts happen when scripts inject content after render. A static-first page has its layout fixed in the HTML; islands load into reserved space. Stability is structural, not patched.

The honest caveat: framework choice sets the ceiling, not the score. You can still ruin an Astro site with 8 MB images or an autoplaying 4K video. The point is that Astro makes performance the default state — something you'd have to actively break, instead of a heroic optimization phase at the end of the project.

Where it gets exciting: heavy 3D without a heavy site

Here's the paradox we care about: the most immersive websites, real-time 3D, WebGL scenes, custom shaders — are usually the slowest. The islands architecture resolves it. The Three.js scene is one island: it lazy-loads, renders when visible, and can be tuned independently. The rest of the page stays pure HTML. You get the cinematic experience without dragging the whole site's performance down with it.

In practice, we go further: the scene loads a lightweight placeholder first (a poster or a low-poly preview), initializes WebGL only when the section approaches the viewport, and degrades gracefully on low-end devices, a static render instead of a broken experience. That choreography is exactly the kind of control a visual builder can't give you.

TSL and WebGPU, explained simply

Two acronyms carry most of the excitement here. WebGPU is the successor to WebGL: a modern graphics API that talks to the GPU the way native games do, unlocking compute shaders and significantly more parallel power in the browser. TSL (Three.js Shading Language) is Three.js's new way of writing shaders as composable JavaScript nodes instead of raw GLSL strings, the same shader code targets both WebGL and WebGPU, today.

Concretely, this unlocks effects that are impossible inside any no-code tool: particle systems driven by live data, materials that react to scroll and cursor physics, post-processing pipelines (grain, bloom, distortion) tuned per scene. Our 3D workflow stays the same as on projects like BotBlox, modeled and optimized in Blender, then brought to life in Three.js, but the ceiling moves from "impressive for a website" to "we can build whatever we can imagine".

Anatomy of an immersive Astro page

To make this concrete, here is how a typical immersive homepage is assembled on this stack, section by section, with its loading strategy:

• Hero: headline and value proposition in pure HTML, visible in the first paint. Behind them, a lightweight poster image that the 3D scene will replace, so the page communicates instantly even on a slow connection.

• The 3D scene (island #1): initializes when the browser is idle, swaps in seamlessly over the poster. On low-end devices or with reduced-motion preferences, the poster simply stays, a deliberate fallback, not a failure.

• Content sections: product story, proof, testimonials, static HTML, zero JavaScript, rendered from Sanity content. This is 70% of the page and it costs the visitor nothing.

• Data visualization (island #2): hydrates only when scrolled into view. Until then, it's a static SVG snapshot — legible to search engines and AI crawlers, interactive for humans who reach it.

• Footer and forms (island #3): the contact form hydrates on interaction, the moment the visitor focuses a field. Before that, it's just HTML.

Three islands, one static document, each part loading on its own terms. That's the whole philosophy in one page.

Sanity: your team stays autonomous

A custom stack shouldn't mean calling a developer for every copy change. We pair Astro with Sanity, a headless CMS built around structured content. Here is what the workflow actually looks like for your team:

• Content is structured, not pasted: we model your content types together — case study, product, article, team member — with the exact fields each needs. No more fighting a page builder; editors fill meaningful fields.

• Visual editing with live preview: Sanity's editing interface shows your real site as you type, so non-technical teammates publish with confidence — the autonomy of a no-code tool, on a fully custom site.

• One source of truth, many outputs: the same structured content feeds the website, your schema markup, your llms.txt, even a future app — without duplication.

Structured content has a second benefit we care about deeply: SEO and AI-readability stop being bolted on. When content is typed data, generating valid schema.org markup, static rendering for AI crawlers, and clean metadata is systematic — the discipline we preach in our SEO & GEO guide becomes the default output of the pipeline.

Costs, timelines, and what changes for you

Transparency, because it's the first question anyone sensible asks:

• Budget: a custom Astro + Sanity build sits in the upper half of our range — typically from $12,000, reaching $20,000 and more with extensive 3D, custom shaders and full copywriting. The premium over a Framer build pays for engineering ownership and a creative ceiling that doesn't exist elsewhere.

• Timeline: count 8–12 weeks for a complete site — content modeling, design, development, 3D production and performance tuning included. A Framer equivalent ships in 4–6.

• Migration: moving from WordPress, Webflow or Framer is a content-mapping exercise, not a rewrite of your business: structured content imports cleanly, URLs are preserved or redirected properly (we're obsessive about that), and SEO equity carries over.

• Ownership: you own the code, the content and the infrastructure. No platform lock-in, no monthly builder fee scaling with your traffic.

How we build it: the process, week by week

A custom stack doesn't mean an opaque project. Here is the shape of a typical 10-week engagement:

• Weeks 1–2 — Foundation: positioning workshop, content modeling in Sanity (your content types, defined together), information architecture, and the technical plan for every interactive moment.

• Weeks 3–5 — Design and 3D production: art direction, page design, and Blender work in parallel — modeling, materials, animation tests. You review real motion early, not static mockups of imagined motion.

• Weeks 6–9 — Build: Astro development, Three.js integration, Sanity wiring, and the performance pass baked in as we go — every island justified, every asset budgeted.

• Week 10 — Launch and handover: redirects and SEO checks, Core Web Vitals validation on real devices, and training for your team in Sanity. You leave autonomous, not dependent.

When we still recommend Framer

Honesty matters here: Framer remains our default for most marketing sites. Faster to ship (4–6 weeks), fully editable by your team, and more than capable of premium, animated experiences, our own site runs on it. The Astro + Sanity stack is for projects that outgrow it.

Choose Astro + Sanity when:

• The experience needs shader-level control, TSL, WebGPU, custom render pipelines.

• Performance is a hard requirement, Core Web Vitals targets, large traffic, SEO-critical pages.

• The site combines heavy interactivity and lots of content, docs, blog, programmatic pages on structured data.

• You have (or want) engineering ownership of your web platform, with no platform lock-in.

Stay on Framer when:

• Speed to launch and team autonomy matter more than the last degree of creative control.

• The site is a marketing site with standard interactive needs, which is, honestly, most of them. Our Framer guide covers that path in depth.

Frequently asked questions

Is Astro good for SEO?

Exceptionally. Every page is served as complete, static HTML, exactly what search engines and AI crawlers parse best. Add structured content from Sanity feeding clean schema markup, and you get one of the strongest technical SEO foundations available today. The ~66% real-world Core Web Vitals pass rate directly supports rankings too.

Can Astro really handle heavy WebGL and Three.js scenes?

Yes, arguably better than any other architecture, because the scene is isolated. The 3D island lazy-loads and renders independently while the rest of the page stays static HTML. Your immersive section gets the GPU; your content gets instant rendering. Neither compromises the other.

Is Astro mature enough for a business website?

Yes. Astro powers production sites for companies like Porsche, NordVPN and Firebase's documentation, has years of stable releases behind it, and its content-site focus means fewer moving parts than app frameworks. It is not the risky bet, it's the specialized tool.

Can our marketing team edit the site without developers?

Yes, that's precisely why we pair Astro with Sanity. Copy, images, articles, case studies: your team edits everything through Sanity's visual interface with live preview. Developer time is only needed for new page types or new interactive components.

When is Next.js the better choice?

When you're building an application rather than a site: authenticated areas, dashboards, complex client-side state, real-time features. If users log in and manipulate data, Next.js (or similar) is the right tool, and we'll tell you so.

Same studio, same design standards, same 3D pipeline, two stacks, chosen for the right reasons. If your project needs an immersive experience that stays fast, talk to us, we'll tell you honestly which stack it deserves.