Wie isoliert hydratisierte Inseln die client-seitige JavaScript-Menge drastisch reduzieren
Die <NuxtIsland>-Komponente rendert einen Seitenbereich serverseitig als reines HTML und hydratisiert ihn danach vollkommen isoliert vom Rest der Seite. Alles außerhalb der Insel bleibt statisch und lädt keinerlei Client-JavaScript, was besonders auf inhaltslastigen Seiten die Ladezeit spürbar verbessert.
Inhaltsverzeichnis
- 1. Was sind Nuxt Islands und Partial Hydration?
- 2. Die
-Komponente im Detail - 3. Praxisbeispiel: Ein Kommentarbereich als Insel
- 4. Server-Rendering ohne Client-Hydration
- 5. Unterschied zu klassischem SSR mit Full Hydration
- 6. Wann lohnt sich der Einsatz von Islands?
- 7. Interaktivität innerhalb einer Insel
- 8. Grenzen und Fallstricke von Islands
- 9. Fazit: Weniger JavaScript, gezielte Interaktivität
- 10. Zusammenfassung
- 11. FAQ
1. Was sind Nuxt Islands und Partial Hydration?
Bei klassischem Server-Side Rendering wird eine komplette Seite serverseitig zu HTML gerendert und danach im Browser vollständig erneut hydratisiert, also mit dem gesamten JavaScript der Anwendung ausgestattet. Das gilt selbst dann, wenn ein Großteil der Seite gar keine Interaktivität besitzt, etwa ein Blogartikel-Text, eine Produktbeschreibung oder eine statische Fusszeile. Der Browser muss trotzdem das komplette Bundle laden, parsen und ausführen, nur um am Ende Event-Listener an Elemente zu hängen, die sich nie verändern.
Partial Hydration dreht dieses Prinzip um: Nur die Bereiche, die tatsächlich Interaktivität benötigen, werden als eigenständige Inseln markiert und ausschließlich für diese Inseln wird Client-JavaScript ausgeliefert. Der Rest der Seite bleibt reines, unverändertes HTML ohne jede Hydration. In Nuxt 3 wird dieses Konzept über die experimentelle <NuxtIsland>-Komponente beziehungsweise über Server-Components mit dem Suffix .island.vue umgesetzt.
2. Die -Komponente im Detail
Eine Komponente wird zur Insel, indem die Datei mit .island.vue endet, etwa CommentSection.island.vue. Nuxt erkennt diese Namenskonvention automatisch und rendert die Komponente serverseitig als isoliertes HTML-Fragment, das über einen eigenen internen Endpunkt nachgeladen werden kann. Die Insel bringt ihr eigenes, minimales JavaScript für die Hydration mit, während die umgebende Seite komplett unberührt bleibt.
Innerhalb einer Insel funktionieren normale Vue-Features wie ref, computed oder Lifecycle-Hooks weiterhin wie gewohnt, allerdings mit dem wichtigen Unterschied, dass Props von außen nur serialisierbar sein dürfen, da sie beim Rendern der Insel effektiv über die Serverantwort transportiert werden. Funktionen oder komplexe Klasseninstanzen als Props funktionieren deshalb nicht, einfache Objekte, Strings und Zahlen dagegen problemlos.
3. Praxisbeispiel: Ein Kommentarbereich als Insel
Eine klassische Artikelseite besteht überwiegend aus statischem Text, Bildern und Überschriften, die sich nach dem initialen Rendern nie mehr ändern. Der Kommentarbereich am Ende der Seite ist dagegen hochgradig interaktiv: Nutzer tippen Text ein, klicken auf Like-Buttons und sehen neue Kommentare live einlaufen. Genau diese Kombination eignet sich ideal für eine Insel, weil der teure Hydration-Aufwand ausschließlich auf den kleinen interaktiven Bereich beschränkt bleibt.
Im folgenden Beispiel wird der komplette Artikeltext ganz normal ohne Hydration gerendert, während nur der Kommentarbereich als eigenständige Insel eingebunden wird. Die Seite lädt dadurch für den großen statischen Bereich kein einziges Byte an Client-JavaScript, während der Kommentarbereich vollständig funktionsfähig bleibt.