Islands-arkitektur: Selektiv hydration

Islands-arkitektur, som Jason Miller navngav i 2020, betragter en webside som for det meste statisk HTML med isolerede interaktive øer indlejret i den. Det statiske HTML-hav sendes til browseren, som det er. Kun de interaktive øer henter og udfører JavaScript, så mængden af JavaScript står i forhold til den faktiske interaktivitet.

Hver ø er en komponent, der hydreres uafhængigt. Serveren gengiver øens oprindelige HTML sammen med resten af siden. Når øens JavaScript indlæses, hydreres kun dette komponentundertræ. HTML'en omkring øerne berøres aldrig af JavaScript — den er virkelig statisk.

På en blogindlægsside med Islands-arkitektur kan JavaScript-mængden være 5kb til en enkelt ø med en knap til at synes godt om. Den samme side bygget som en React-SPA sender måske mere end 200kb JavaScript for at hydrere hele siden. Islands-tilgangen gør mængden proportional med interaktiviteten, ikke sidens størrelse.

Astro, det førende rammeværk til Islands-arkitektur, understøtter øer bygget med forskellige rammeværker på den samme side. Du kan have en React-ø ved siden af en Vue-ø og en ø med ren JavaScript. Hver ø pakkes separat, så brugerne kun henter koden til de rammeværker, der bruges af de synlige øer.

Direktivet client:load hydreres øjeblikkeligt, når siden indlæses. Brug det til øer, der er synlige og interaktive med det samme, f.eks. en navigationsmenu eller en fremhævet sektion med et søgefelt. Dette er hydreringsstrategien med den højeste prioritet.

Direktivet client:idle venter, indtil browserens hovedtråd er ledig, efter at det kritiske indhold er indlæst, før øen hydreres. Det er ideelt til elementer under det synlige område eller sekundære interaktioner, der ikke er nødvendige med det samme, f.eks. en bjælke til social deling.

Direktivet client:visible bruger en Intersection Observer til kun at hydrere øen, når den rulles ind i visningsområdet. Det er ideelt til øer langt nede på siden — f.eks. en kommentarsektion eller en karrusel med relaterede produkter — som de fleste brugere måske aldrig når frem til. JavaScript indlæses ikke engang, før det er nødvendigt.

Direktivet client:only springer serversiderendering helt over og gengiver kun øen i browseren. Det er nødvendigt for komponenter, der bruger API'er, som kun findes i browseren (window, document), eller som afhænger af klientsidetilstand på monteringstidspunktet. Afvejningen er, at øen ikke har nogen serversiderenderede HTML.

Islands-arkitektur løser problemet med fuld hydrering ved at sikre, at JavaScript kun indlæses og udføres for reelt interaktive komponenter. Et blogindlæg med en knap til at synes godt om hydrerer kun øen med denne knap — teksten i artiklen på 1.200 ord, sidehovedet og sidefoden medfører ingen JavaScript-udførelse på klienten.

Hver ø har sin egen isolerede tilstand. Øer kan ikke dele React-tilstand direkte, fordi de er separate React-træer. Det er tilsigtet: Hvis to komponenter har brug for at dele tilstand, bør de samles i én ø. Kommunikation på tværs af øer bruger URL-parametre, DOM-hændelser eller lette tilstandsbiblioteker.

Websteder, der er flyttet fra React-SPA til Islands-arkitektur, f.eks. Astro-dokumentationswebstedet, rapporterer markante forbedringer: JavaScript-mængden falder med 70-90 %, TTI forbedres med 2-4 sekunder på mobilen, og Lighthouse-resultaterne for ydeevne stiger fra 60'erne til 90'erne eller derover. Gevinsterne er størst på sider med meget indhold.

Ø-arkitekturen holder det meste af siden som statisk HTML og hydrerer kun isolerede interaktive komponenter. Astro har hydreringsdirektiverne client:load (med det samme), client:idle (efter inaktivitet), client:visible (ved rulning) og client:only (gengivelse kun på klienten). Hver ø hydreres uafhængigt, så mængden af JavaScript står i forhold til interaktiviteten i stedet for sidens størrelse.