Wir haben 90five.com als statische Astro Website neu gebaut. Pro Seite liefert sie rund 35 KB eingebettetes CSS und rund 12 KB JavaScript aus und erreicht im mobilen Lighthouse-Test 96 bis 99 Punkte bei der Performance. Die meisten Kundenprojekte bauen wir weiterhin in Webflow. Dieser Artikel erklärt, warum wir für die eigene Seite Astro gewählt haben und wie die Messwerte aussehen.
Warum haben wir die eigene Website auf Astro umgestellt?
Unsere alte Seite lief in Webflow, und sie war gut. Wir sind zertifizierter Webflow-Partner und empfehlen Webflow den meisten B2B-Teams, mit denen wir sprechen. Der Umbau war also kein Protest gegen Webflow.
Wir wollten herausfinden, wo Code das bessere Werkzeug ist, und die eigene Seite ist dafür der sicherste Testplatz. Eine Agentur, die individuelle Webentwicklung verkauft, sollte so eine Seite auch für sich selbst gebaut haben. Dazu kam der Wunsch, das Markup, das CSS im Browser und die deutsche Version vollständig selbst zu steuern, statt sie nachträglich anzuflanschen.
Ausgangspunkt war der Webflow-Export. Markup und Klassennamen haben wir behalten und die Auslieferung darum herum neu gebaut. Deshalb sieht die Seite aus wie vorher und lädt ganz anders.
Welcher Stack steckt dahinter?
Es sind wenige Bausteine, und jeder hat genau eine Aufgabe.
Die Seite ist ein statischer Astro-Build. Jede Seite wird beim Build zu reinem HTML gerendert. Es sind rund 170 Seiten auf Deutsch und Englisch. Die deutschen Seiten haben eigene URLs unter /de und verweisen per hreflang auf ihre englischen Gegenstücke. Ein kleines Inline-Skript schickt Erstbesucher:innen, deren Browser Deutsch bevorzugt, einmalig auf die deutsche Version und merkt sich eine bewusste Auswahl. Bots leitet es nie um.
Gehostet wird auf Cloudflare Workers mit statischen Assets. Die HTML-Dateien kommen direkt vom Edge. Ein kleiner Worker nimmt Formulare entgegen: Er prüft die Herkunft, setzt auf ein Honeypot-Feld und Turnstile als Spamschutz, validiert die Felder und leitet die Anfrage an Slack oder per E-Mail weiter. Seitenaufrufe laufen nie über diesen Worker.
Der Blog liegt in Sanity. Die Artikel werden beim Build geholt, ein veröffentlichter Beitrag wird also mit dem nächsten Build zur statischen Seite. Das Veröffentlichen in Sanity stößt diesen Build an.
Auf der Client-Seite gibt es kein UI-Framework. Navigation, Akkordeon, Cookie-Banner und die mehrstufigen Formulare sind schlichtes TypeScript, zusammen wenige Kilobyte. Animationen laufen mit CSS und der Web Animations API und berücksichtigen die Einstellung für reduzierte Bewegung.
Wie viel CSS und JavaScript liefert jede Seite aus?
Wir haben den fertigen Build gemessen, statt ein Gefühl zu zitieren. Über die 136 indexierbaren Seiten des Builds hinweg trägt eine Seite im Schnitt rund 35 KB CSS, direkt ins HTML eingebettet, das sind etwa 7 KB komprimiert. JavaScript liegt im Schnitt bei rund 12 KB pro Seite, komprimiert etwa 4 KB, inklusive der kleinen Inline-Skripte.
Beim CSS hat sich am meisten verändert. Das Webflow-Stylesheet, von dem wir ausgingen, war etwa 106 KB groß. Beim Build bereinigen wir es pro Seite, behalten nur die Regeln, die diese Seite braucht, und betten das Ergebnis in den Head ein. Der Browser stellt eine einzige Anfrage für das HTML und muss auf kein Stylesheet warten, bevor er zeichnen kann.
Das Einbetten hat einen Preis. Das CSS steckt in jeder HTML-Datei, wiederkehrende Besucher:innen können es nicht separat cachen. Bei etwa 7 KB komprimiert pro Seite nehmen wir das in Kauf. Eine Seite mit einem deutlich größeren gemeinsamen Stylesheet sollte anders abwägen.
Was sagen Lighthouse und die Core Web Vitals?
Wir haben Lighthouse im mobilen Modus gegen die ausgelieferte Seite laufen lassen. Die Ergebnisse schwanken von Lauf zu Lauf leicht, deshalb nennen wir Bereiche statt eines Einzelwerts:
- Performance: 96 bis 99
- Barrierefreiheit: 97 bis 100
- Best Practices: 100
- SEO: 100
- Largest Contentful Paint: etwa 2,1 bis 2,6 Sekunden bei simulierter mobiler Drosselung
- Cumulative Layout Shift: 0
- Total Blocking Time: 0 bis 10 ms
Lighthouse ist ein Labortest mit gedrosseltem Smartphone und langsamer Verbindung. Er bildet nicht ab, was jede:r Besucher:in erlebt, ist aber wiederholbar und eignet sich deshalb, um Builds miteinander zu vergleichen. Googles Schwelle für einen guten LCP liegt bei 2,5 Sekunden, und unsere langsameren Läufe liegen genau an dieser Linie. Der LCP ist also die Zahl, an der wir als Nächstes arbeiten würden.
TBT und CLS profitieren am stärksten von einem statischen Build. Mit fast keinem JavaScript gibt es wenig, das den Hauptthread blockiert, und mit festen Bildmaßen springt nichts.
Wie ist das Hosting aufgebaut, und warum so?
Statische Dateien brauchen keinen Server, der bei jedem Aufruf rechnet. Deshalb liegen die Seiten auf Cloudflare als statische Assets und werden von dort ausgeliefert. Das spart Betriebsaufwand und hält die Antwortzeiten niedrig, weil nichts erst zusammengebaut werden muss.
Die einzige dynamische Stelle ist der Formular-Worker. Er läuft nur bei einer Formularabsendung und nie bei einem normalen Seitenaufruf. Fällt er aus, bleibt die Seite erreichbar, nur die Formulare melden einen Fehler, statt eine Anfrage stillschweigend zu verschlucken.
Hilft Astro bei SEO?
Astro rankt keine Seiten. Das leisten Inhalte, Links und Nachfrage. Ein statischer Astro-Build liefert aber eine saubere Ausgangslage für technisches SEO. Ohne Zusatzaufwand haben wir bekommen:
- Vollständiges HTML für jede Seite, sodass Crawler den Inhalt ohne Skriptausführung sehen.
- Volle Kontrolle über Titel, Beschreibungen, Canonicals, hreflang und JSON-LD, an einer Stelle im Layout.
- Eine Sitemap, die aus den tatsächlich vorhandenen Seiten erzeugt wird, ohne die noindex-Seiten.
- Schnelle Seiten, die die Core Web Vitals bestehen, ohne dass wir jede einzeln nachbessern.
Dazu haben wir ein QA-Skript geschrieben, das den Build durchläuft und defekte Links, fehlende Assets, Titel, H1-Tags, hreflang-Gegenseitigkeit und die Lesbarkeit des JSON-LD prüft. Wir lassen es laufen, bevor Änderungen live gehen. Dieses Skript nützt dem SEO ebenso sehr wie das Framework. Dieselben Prüfungen lassen sich für jedes Werkzeug schreiben, und was zu prüfen ist, steht in unserer Webflow SEO Checkliste für B2B-Websites.
Was hat uns Astro im Vergleich zu Webflow gekostet?
Vor allem Zeit, und ein Stück Unabhängigkeit des Marketingteams.
In Webflow kann jede:r im Team in Minuten eine Überschrift ändern oder einen CMS-Eintrag veröffentlichen, mit einem visuellen Editor und ohne Deployment. In unserem Astro-Aufbau laufen Textänderungen über die Codebasis, sofern die Inhalte nicht in Sanity liegen. Für uns ist das in Ordnung, weil die Menschen, die die Seite pflegen, auch Code schreiben. Für ein vierköpfiges Marketingteam ohne Entwickler:in wäre es ein schlechter Tausch.
Außerdem haben wir nachgebaut, was Webflow mitbringt: Formularverarbeitung, Sitemap, Weiterleitungen, die Anbindung des Consent-Banners und die Bildverarbeitung. Jedes Stück ist klein, zusammen sind es echte Arbeitsstunden.
Wann ist Code das bessere Werkzeug?
Unsere Faustregel nach diesem Projekt: Wählen Sie Webflow, wenn Marketing die Seite selbst verantworten soll und das Design die wichtigste Variable ist. Wählen Sie Astro oder einen anderen Code-Ansatz, wenn Sie Kontrolle brauchen, die Webflow nicht bietet, etwa Hunderte aus strukturierten Daten erzeugte Seiten, Kontrolle über jedes Byte der Ausgabe oder eine Seite nah am Produktcode.
Für die Entscheidung haben wir einen längeren Leitfaden geschrieben: Webflow oder Astro oder Next.js: Was passt zu Ihrer Website?. Wenn Sie Webflow gegen ein klassisches CMS abwägen, lesen Sie Webflow vs. WordPress 2026.
Wenn für Sie schon feststeht, dass es Code sein soll: Unser Angebot individuelle Webentwicklung baut Astro- und Next.js-Websites für B2B-Teams. Projekte beginnen bei 20.000 €, genau wie unsere Webflow-Websites.
FAQ
Ist Astro gut für SEO?
Astro erzeugt statisches HTML und gibt Ihnen direkte Kontrolle über Titel, Canonicals, hreflang und strukturierte Daten. Das macht technisches SEO unkompliziert. Das Ranking verbessert Astro nicht von allein: Inhalte, Links und Suchnachfrage entscheiden weiterhin.
Ist Astro schneller als Webflow?
Eine sorgfältig gebaute statische Astro-Seite kann schlanker sein als eine typische Webflow-Seite, weil Sie genau bestimmen, was ausgeliefert wird. Eine gut gebaute Webflow-Seite kann aber ebenfalls gute Werte erreichen. Der Unterschied liegt darin, wer optimiert: Astro macht kleine Seiten zum Normalfall, Webflow macht sie möglich.
Können Marketer:innen eine Astro-Website selbst pflegen?
Ja, wenn die Inhalte in einem Headless-CMS wie Sanity liegen und die Seite bei jeder Veröffentlichung neu gebaut wird. Layout- und Designänderungen brauchen weiterhin eine Entwickler:in. Wenn Ihr Team Seiten selbst umbauen will, passt Webflow besser.
Bauen Sie weiterhin Websites in Webflow?
Ja. Webflow ist unsere Standardempfehlung für die meisten B2B-Marketingseiten, und wir sind zertifizierter Webflow-Partner. Zu Astro oder Next.js greifen wir, wenn ein Projekt Kontrolle, Skalierung oder Produktanbindung braucht, die Webflow nicht liefert. Mehr zu dieser Seite unserer Arbeit steht auf der Seite Webflow-Agentur.
Was kostet eine individuelle Astro-Website?
Individuelle Astro- und Next.js-Websites beginnen bei 90five bei 20.000 €. Der Endpreis hängt von der Zahl der Templates, dem CMS-Aufbau, Integrationen und einer eventuellen Migration ab. Der Artikel Was kostet eine Webflow Website? erklärt diese Kostentreiber, und sie gelten auch für Code-Projekte.