Astro 7 oder Next.js? Welches Framework für einen visuellen Page-Builder mit Sanity

Was wir eigentlich bauen wollen

Die Idee ist ein Page-Builder, der sich für den Kunden wie ein Baukasten anfühlt. Er wählt Blöcke aus (Heading, Paragraph, Button, Bild, Grid, Slider), setzt Paddings über Schieberegler, wechselt das Farbthema einer Section und ordnet Elemente per Drag-and-drop neu an. Links im Preview sieht er dabei in Echtzeit, was passiert.

Sanity liefert dafür drei Bausteine. Das Presentation Tool stellt Studio und Website nebeneinander dar. Click-to-edit Overlays lassen per Klick auf ein Element direkt zum passenden Feld springen. Und Custom Inputs im Studio ermöglichen eigene Slider, Dropdowns und Responsive-Controls.

Wichtig zu verstehen: Die rechte Seite, also das Studio mit all seinen Reglern, ist immer React. Das ist unabhängig vom Frontend. Die Framework-Entscheidung betrifft ausschliesslich die linke Seite: Wie reagiert das Preview, wenn sich rechts etwas ändert?

Wer den Weg von Webflow zu einem solchen Setup überhaupt erst abwägt, findet den Kontext in unserem Guide zur Migration von Webflow zu Sanity.

Der Knackpunkt: Live-Updates ohne Reload

Next.js bekommt von Sanity mit dem Paket next-sanity eine Live Content API. Konkret heisst das: defineLive und die Komponente SanityLive streamen Änderungen direkt in die Seite. Zieht der Kunde einen Slider von 40 auf 120 Pixel Padding, rendert sich die betroffene Section neu, ohne dass die Seite neu lädt. Dazu kommt der Hook useOptimistic, der die Änderung im Browser sofort anzeigt, noch bevor der Server geantwortet hat. Drag-and-drop fühlt sich dadurch an wie in einem nativen Tool.

Astro hat dieses Äquivalent nicht. Gemeint ist hier die Live Content API von Sanity, also das Streaming von Studio-Änderungen ins Preview. Das ist etwas anderes als Astros eigene Live Content Collections, die zur Laufzeit Daten aus Remote-Quellen laden. Sanity schreibt in der Dokumentation ganz offen: Für Astro gibt es keine Live Content API. Wenn ein Editor ein Feld ändert, löst die Visual-Editing-Komponente standardmässig einen vollständigen Reload der Seite aus, um frische Inhalte vom Server zu holen.

Für einen Blog oder eine klassische Content-Seite ist das völlig in Ordnung. Der Editor tippt einen Text, die Seite lädt einmal neu, fertig. Für einen Page-Builder mit Schiebereglern ist es ein Problem. Jeder Slider-Tick würde einen Reload bedeuten. Scrollposition weg, Animationen starten von vorne, das Preview flackert. Genau das will niemand, der von Webflow kommt.

Was Astro 7 am Visual Editing ändert (und was nicht)

Astro 7 ist im Juni 2026 erschienen und dreht sich vor allem um Geschwindigkeit. Der Compiler für .astro-Dateien läuft jetzt in Rust, Markdown und MDX durch eine neue Rust-Pipeline, und mit Vite 8 kommt der Rolldown-Bundler. In den Benchmarks des Astro-Teams sind Builds zwischen 15 und 61 Prozent schneller als mit Astro 6. Advanced Routing mit zentralem Entrypoint macht Draft-Cookies und Perspective-Handling für Sanity-Setups etwas sauberer.

Das ist ein starkes Infrastruktur-Release. Am Reload-Verhalten im Visual Editing ändert es nichts. Sanity hat den Astro-Guide bereits auf Astro 7 aktualisiert, und der Hinweis auf den Full Reload steht weiterhin drin. Wer Astro wegen Build-Zeiten und Produktions-Performance wählt, trifft eine gute Entscheidung. Wer es wegen eines Live-Builders wählt, wählt es aus dem falschen Grund.

Mehr zum Framework selbst steht im Glossar unter Astro. Den Gegenpart erklärt der Eintrag zu Next.js.

Astro oder Next.js: Was für den Page-Builder zählt

Beim Realtime-Preview ist der Abstand klar. Next.js bringt die Live Content API fertig mit. In Astro ginge der Workaround nur über eine grosse React-Island mit dem Sanity React Loader. Dann rendert Astro im Preview praktisch nichts mehr selbst. Man hat eine React-App in Astro verpackt und die Island-Vorteile im Editing-Modus verspielt.

Click-to-edit funktioniert in beiden Welten über Stega-Encoding und data-sanity-Attribute. Bei Next.js steckt das in next-sanity, bei Astro braucht es die React-Integration dazu. Für den Redakteur fühlt sich das ähnlich an. Der Unterschied bleibt das Live-Verhalten dahinter.

Im Live-Betrieb gewinnt Astro bei der Payload: statische Blöcke ohne JavaScript, interaktive Inseln nur dort, wo sie nötig sind. Das ist für Marketing-Seiten mit GSAP-Animationen ideal. Next.js schickt mit React Server Components ebenfalls wenig JavaScript, aber die React-Runtime ist immer dabei. In unseren Setups liegt der Abstand oft im niedrigen zweistelligen Kilobyte-Bereich. Für eine Unternehmenswebsite mit sauberem Setup spürbar in Lighthouse, selten spürbar für den Besucher.

Beim Rest entscheidet der Alltag mehr als der Benchmark. Astro 7 baut mit Rust-Compiler und Rolldown aktuell schneller als Next.js mit Turbopack. Astro deployt über Adapter auf Node, Cloudflare, Netlify oder Vercel mit ähnlich wenig Reibung. Next.js läuft auf Vercel am glattesten, besonders mit Live API und Draft Mode. Self-Hosting geht, kostet aber mehr Setup und mehr laufende Aufmerksamkeit. Dafür teilen Studio und Frontend bei Next.js dieselbe React-Welt: Block-Previews im Studio können die echten Frontend-Komponenten rendern. Bei Astro bleiben Studio und Frontend zwei Welten, und Upgrades fühlen sich bei Astro oft entspannter an als zwischen Next.js-Majors.

Unsere Einschätzung

Wenn das Kernfeature lautet "Kunde zieht Slider, Seite reagiert sofort", nehmen wir Next.js. Dann arbeiten wir mit dem Framework statt dagegen. Den Performance-Nachteil gegenüber Astro nehmen wir für diesen Use-Case bewusst in Kauf, weil das Editing-Erlebnis sonst zur Dauerbaustelle wird. Ein Builder, der bei jedem Regler-Tick flackert, wird im Alltag nicht benutzt. Dann landen Layout-Änderungen wieder beim Dev-Team, und der ganze Sinn des Page-Builders verpufft.

Astro bleibt unser Default, sobald der Kunde selten editiert und ein Reload nach der Änderung akzeptabel ist. Klassisches Content-Editing, Blog, Marketing-Seiten mit festen Sektionen: dort bekommen wir die bessere Produktions-Performance und das einfachere Deployment ohne Trade-off am Editor. Genau deshalb starten die meisten unserer Sanity-Projekte weiterhin mit Astro und wechseln nur den Frontend-Teil, wenn Live-Editing wirklich Teil des Angebots an den Kunden wird.

Ein Hybrid lohnt sich nur bei klarer Trennung. Header, Footer und statische Seiten in Astro, den Page-Builder als React-Island nur auf den Landing Pages, die ihn wirklich brauchen. Das kostet Verdrahtung und Monitoring. Im Preview-Modus fällt der Astro-Vorteil ohnehin weg. Wir setzen das nur, wenn rund 90 Prozent der Seiten statisch bleiben und der Builder die Ausnahme ist, nicht die Regel.

Die Live Content API selbst an Astro anzubinden ist möglich, aber Eigenbau. Server-Sent Events der Sanity Live API im Browser abonnieren, bei einem Event die Seite über den Client Router partiell nachladen, dazu einen eigenen refresh-Handler statt window.location.reload(). Das fühlt sich besser an als ein harter Full Reload. Den Komfort von next-sanity und optimistische Updates beim Slider-Ziehen bekommt man damit trotzdem nicht.

Häufige Fragen zu Astro, Next.js und Sanity Page-Buildern

Braucht ein Sanity-Page-Builder zwingend Next.js?

Nein. Das Presentation Tool, Click-to-edit und Custom Inputs funktionieren auch mit Astro. Der Unterschied liegt im Live-Verhalten des Previews. Wer Blöcke nur gelegentlich pflegt und einen Reload akzeptiert, kommt mit Astro gut zurecht. Wer Slider, Drag-and-drop und sofortige visuelle Rückmeldung will, baut mit Next.js gegen deutlich weniger Widerstand.

Kann man später von Next.js auf Astro wechseln?

Ja. Sanity-Schemas, Custom Inputs und die Content-Struktur sind framework-unabhängig. Das Frontend lässt sich austauschen, ohne dass Redakteure das Studio neu lernen müssen. Was man neu bauen muss, ist die Rendering-Schicht und die Anbindung an Visual Editing. Bei designtakt planen wir solche Setups deshalb bewusst so, dass Content-Modell und Frontend entkoppelt bleiben.

Reicht Astro Visual Editing für Marketing-Teams?

Für klassisches Content-Editing ja: Texte ändern, Bilder tauschen, neue Blogposts anlegen. Für ein Webflow-ähnliches Page-Builder-Erlebnis mit feingranularen Layout-Reglern eher nein. Marketing-Teams erwarten, dass das Preview beim Ziehen eines Sliders sofort reagiert. Genau das liefert Astro ohne Eigenbau oder React-Island nicht.

Fazit

Astro 7 bleibt für die meisten Content-Websites die schnellere und robustere Wahl. Ein visueller Page-Builder ist ein anderer Use-Case. Er lebt davon, dass Studio und Preview in Echtzeit miteinander sprechen, und dafür hat Sanity aktuell nur für Next.js eine fertige Antwort. Bei designtakt heisst das: Astro als Default, Next.js sobald Live-Editing zum Produktversprechen wird.

Du überlegst, ob ein Headless-Setup mit visuellem Editor für dein Projekt Sinn macht? Wir helfen gerne bei der Einschätzung.