Headless & Infrastruktur
Islands Architecture – Interaktivität ohne JavaScript-Overhead
Islands Architecture ist das Kernkonzept das Astro von anderen Frameworks unterscheidet. Eine Seite besteht aus statischem HTML — dem ‘Ozean’ — und einzelnen interaktiven Komponenten, den ‘Inseln’. Jede Insel wird unabhängig und nur bei Bedarf hydratisiert. Das Ergebnis: Seiten die fast kein JavaScript laden, aber trotzdem interaktive Elemente enthalten können — Theme-Toggle, Suchfunktion, Formulare, komplexe UI-Komponenten.
Das Problem mit klassischen SPAs
In React, Vue oder Angular ist jede Seite eine JavaScript-Anwendung. Beim Laden muss das gesamte Framework heruntergeladen, geparst und ausgeführt werden — auch für Seiten die kaum Interaktivität brauchen. Bei Astro ist JavaScript die Ausnahme: Nur Komponenten die explizit als interaktiv markiert werden, laden JavaScript. Eine Seite mit einem Theme-Toggle und einem Newsletter-Formular lädt nur das JavaScript für genau diese zwei Komponenten.
client:*-Direktiven — wann wird hydratisiert?
client:load — sofort
Die Komponente wird sofort beim Seitenload hydratisiert. Verwenden für: Elemente die sofort nach dem Laden interaktiv sein müssen. Theme-Toggle, kritische Navigation, Login-Status. Höchste JavaScript-Priorität — sparsam verwenden.
client:idle — wenn der Browser idle ist
Hydratisierung wenn requestIdleCallback feuert — der Browser hat Zeit. Verwenden für: wichtige aber nicht sofort kritische Interaktivität. Newsletter-Formular, Kommentar-Sektion, Social-Share-Buttons. Guter Default für die meisten interaktiven Elemente.
client:visible — wenn im Viewport
Hydratisierung wenn die Komponente im sichtbaren Bereich erscheint (IntersectionObserver). Verwenden für: Komponenten below the fold. Schwere Chart-Bibliotheken, Karten, komplexe Tabellen. Spart JavaScript-Ladezeit für Inhalte die nie gesehen werden.
client:media — bei Media Query
Hydratisierung nur wenn eine CSS Media Query zutrifft. Verwenden für: Komponenten die nur auf bestimmten Geräten aktiv sind. Mobile-Only Navigation, Desktop-Only Sidebar. Verhindert unnötiges JavaScript auf dem jeweils anderen Gerät.
client:only — rein client-seitig
Keine Server-seitige Renderung — die Komponente existiert nur im Browser. Verwenden für: Komponenten die auf Browser-APIs angewiesen sind (localStorage, window, navigator). Wichtig: kein Server-seitiges HTML — Accessibility und SEO berücksichtigen.
client:load sparsam einsetzen
Jedes client:load blockiert den Main Thread beim Seitenload. Zu viele client:load-Direktiven führen zu schlechtem INP (Interaction to Next Paint). Als Faustregel: maximal 1–2 client:load pro Seite, Rest mit client:idle oder client:visible.
React als Island einbinden
Mit der @astrojs/react-Integration können React-Komponenten direkt in .astro-Dateien verwendet werden. Die React-Komponente bleibt eine normale .tsx-Datei — die Island-Direktive wird beim Einbinden in Astro hinzugefügt. Wichtig: React-Hooks (useState, useEffect, useRef) funktionieren nur in client-seitig hydratisierten Komponenten. Ohne client:*-Direktive wird die Komponente nur server-seitig gerendert — Hooks werden ignoriert.
Mehrere Frameworks gleichzeitig
Astro erlaubt mehrere UI-Frameworks gleichzeitig — React, Vue und Svelte können auf derselben Seite als Islands eingebunden werden. Jede Island lädt nur ihre eigene Runtime. In der Praxis ist das selten sinnvoll — man wählt ein Framework und bleibt dabei. Aber bei der Migration von einem Framework zum anderen (zum Beispiel von Vue zu React) ist die Koexistenz ein echter Vorteil: schrittweise Migration ohne Big-Bang-Rewrite.
Astro-Komponenten vs. React-Islands
JavaScript im Browser
Astro-Komponente: 0 KB — React Island: React Runtime + Komponente
Interaktivität
Astro: Keine (HTML only) — React Island: Vollständig (Hooks, Events)
State
Astro: Nur server-seitig — React Island: useState, useReducer, …
Einsatz
Astro: Layout, Content, Templates — React Island: Formulare, Toggle, komplexe UI
Performance
Astro: Maximal — React Island: Abhängig von Direktive
Astro-Komponenten für alles Statische
Die Faustregel: Wenn eine Komponente keinen State und keine Browser-Events braucht, ist sie eine Astro-Komponente. Nur wenn Interaktivität wirklich nötig ist, wird eine React/Vue-Island eingesetzt. Das minimiert JavaScript-Overhead.
Häufig gestellte Fragen zum Thema Astro Islands
Nicht direkt über Props — jede Island ist isoliert. Für Kommunikation zwischen Islands empfiehlt Astro Nano Stores (nanostores) — ein winziges State-Management das framework-agnostisch ist und zwischen mehreren Islands geteilt werden kann.
React Context funktioniert innerhalb einer Island — nicht zwischen Islands. Redux funktioniert ebenfalls innerhalb einer Island. Für geteilten State zwischen mehreren Islands sind Nano Stores die Astro-empfohlene Lösung.
React Islands können mit React Testing Library wie normale React-Komponenten getestet werden — unabhängig von Astro. Für Integration-Tests (Island in der Astro-Seite) eignet sich Playwright oder Cypress.
Nur wenn sie alle client:load verwenden. Mit client:idle und client:visible werden Islands progressiv geladen und beeinträchtigen den initialen Seitenload nicht. Die Anzahl der Islands ist weniger wichtig als die gewählten Direktiven.