Astro: Warum statische Seiten so schnell sind und wann es sich lohnt

Astro liefert fertiges HTML und lässt JavaScript weg, wo es keins braucht. Das macht Seiten schnell und robust. Wann sich Astro lohnt, wann WordPress oder Statamic allein reichen und wie die Redaktion arbeitet.

3 Min. Lesezeit · Stand

Fertiges HTML statt Baustelle im Browser

Viele moderne Websites schicken dem Browser vor allem JavaScript, und der Browser baut die Seite daraus erst zusammen. Auf einem schnellen Rechner merkt man das kaum, auf einem älteren Telefon schon. Eine typische Startseite lädt auf dem Smartphone rund 558 KB JavaScript, gemessen als Median über Millionen Seiten [2].

Astro dreht das um. Jede Komponente wird beim Bau zu reinem HTML und CSS, das JavaScript dafür fällt automatisch weg [1]. Was interaktiv sein muss, ein Rechner, eine Karte, ein Formular, wird als „Insel“ markiert und bekommt genau das JavaScript, das es braucht, auf Wunsch erst, wenn es ins Bild kommt [1]. Der Rest der Seite bleibt schlankes HTML.

Was das in Zahlen bedeutet

558 KBJavaScript auf einer typischen mobilen Startseite (Median 2024). [2]
900 KBBilder auf einer typischen mobilen Startseite, der größte Brocken. [2]
≤ 0,8 sAntwortzeit des Servers bis zum ersten Byte gelten als gut. Fertige Dateien schaffen das leicht. [3]

WordPress oder Statamic bleibt das Redaktionssystem

Astro ist kein Ersatz für ein CMS, sondern ein Frontend. Die Redaktion pflegt Texte und Bilder weiter in Statamic oder WordPress; Astro holt die Inhalte und baut daraus die fertigen Seiten. Diesen Schritt nennt man Build. Er läuft automatisch, zum Beispiel direkt nach dem Speichern, nach Zeitplan oder per Knopf „Veröffentlichen“, und dauert meist nur wenige Minuten. Für die Redaktion ändert sich nichts, für die Besucher wird die Seite schneller. Wie das mit Statamic zusammenspielt, steht in Statamic mit Astro.

Diese Website ist selbst so gebaut: Statamic als Redaktionssystem, Astro als Frontend. JavaScript läuft hier nur dort, wo etwas passiert, beim Paketrechner, bei den Formularen, beim Kopieren der Mailadresse und bei den Animationen.

Wann sich Astro lohnt

KriteriumAstro als FrontendWordPress oder Statamic allein
Kampagnen und Landingpagesideal: jede Millisekunde zählt, wenig Interaktiongeht auch, mit mehr Aufwand für Tempo
Unternehmensseite, mehrsprachigsehr gut, wenn Tempo ein Verkaufsargument istStatamic allein ist oft schon schnell genug
Shop mit Warenkorbnur mit zusätzlicher TechnikWooCommerce ist meist der einfachere Weg
Viele Plugins, Logins, Portaleeher nichtWordPress oder Statamic auf Laravel

Eine Orientierung aus unseren Projekten; die richtige Wahl hängt vom Einzelfall ab.

Was es kostet und was es spart

Ein Astro-Frontend ist ein zusätzlicher Baustein und damit etwas mehr Aufwand beim Bau. Dafür entfällt im Betrieb viel von dem, was andere Seiten langsam macht: keine Datenbankabfrage pro Besuch, kein Plugin, das Skripte nachlädt, fertige Dateien, die jeder Hoster schnell ausliefert [3]. Ob es sich lohnt, klären wir vor dem Angebot. Bei den meisten Unternehmensseiten empfehlen wir Statamic allein, bei Kampagnen und besonders schnellen Auftritten Statamic mit Astro.

Fragen zu Astro

Wird eine Website durch Astro automatisch schneller?

Meistens, weil Astro ohne Interaktion kein JavaScript mitschickt und die Seiten fertig auf dem Server liegen. Automatisch ist es aber nicht: Riesige Bilder, viele Schriftschnitte oder fremde Skripte bremsen auch eine Astro-Seite. Die Regeln für Bilder, Schriften und Skripte gelten genauso.

Können wir Astro auch mit WordPress als Redaktionssystem nutzen?

Ja. WordPress liefert die Inhalte über seine Schnittstelle, Astro baut daraus die Seiten. Dann entfällt allerdings der Seitenbau mit Bricks, und Plugins, die vorne etwas anzeigen, etwa Formular- oder Slider-Plugins, wirken nicht mehr. Das lohnt sich vor allem, wenn die Redaktion WordPress kennt und das Frontend besonders schnell sein soll.

Was passiert, wenn ein Build fehlschlägt?

Dann bleibt die bisherige Version online, und es wird nichts Halbfertiges veröffentlicht. In unserem Aufbau prüft der Build jeden Inhalt gegen feste Regeln und nennt bei einem Fehler Abschnitt und Feld. Wir bekommen die Meldung und kümmern uns darum.

Alle Fragen 

Für Agenturen

Lassen Sie die Website Ihres Kunden white-label messen. Sie bekommen die drei Werte, die größten Bremsen und einen Fixpreis für die Behebung, in Ihrem Branding.

Weiterlesen

  1. Bilder, Schriften, Skripte: die drei größten Bremsen und was hilftBilder machen den größten Teil einer Seite aus, Schriften verzögern den Text, fremde Skripte blockieren die Bedienung. Was wir beim Bau dagegen tun und was Agenturen im Briefing gleich mitgeben können.
  2. Core Web Vitals verständlich: LCP, INP und CLS ohne FachchinesischDrei Messwerte entscheiden, ob Google eine Seite für schnell hält: Laden, Reagieren, Stillhalten. Was sie bedeuten, wo die Grenzen liegen und warum ein Lighthouse-Wert allein nichts beweist.
  3. Hosting und Tempo: was wir beim Hoster Ihres Kunden prüfenWir hosten nicht selbst, aber wir schauen genau hin. Die Antwortzeit des Servers, die Softwareversionen und das Caching entscheiden mit, wie schnell eine Seite sein kann. Was wir prüfen und wann ein Wechsel sinnvoll ist.

Quellen

  1. Astro Docs, Islands architecture · abgerufen am 29.10.2026
  2. HTTP Archive, Web Almanac 2024: Page Weight (30.12.2024) · abgerufen am 29.10.2026
  3. web.dev, Time to First Byte (TTFB) (aktualisiert 18.11.2025) · abgerufen am 29.10.2026
  4. web.dev, Web Vitals · abgerufen am 29.10.2026

Recherchiert mit KI-Unterstützung, mit Quellen belegt und inhaltlich geprüft von Mike Joerihsen am .

Diese Inhalte sind eine Orientierung und keine Rechtsberatung. Bei konkreten Fragen zu Ihrer Situation wenden Sie sich an eine Rechtsberatung oder die zuständige Behörde.

Lieber direkt? mike@mjoe.me · +43 680 22 12 987