Pomiar wydajności: Lighthouse i Core Web Vitals

Lighthouse jest standardowym narzędziem do pomiaru wydajności stron internetowych. Można uruchomić go w Chrome DevTools (na karcie Lighthouse) lub za pomocą interfejsu wiersza poleceń (npx lighthouse https://yoursite.com). Podczas oceniania Islands Architecture należy uruchomić Lighthouse na reprezentatywnych stronach przed migracją i po niej, aby obiektywnie zmierzyć uzyskane korzyści.

LCP mierzy moment, w którym największy widoczny element treści kończy renderowanie. Islands Architecture poprawia LCP, ponieważ serwer od razu wysyła w pełni wyrenderowany kod HTML — przeglądarka nie musi czekać na JavaScript, aby wyrenderować treść. Obraz główny lub nagłówek, który byłby elementem LCP, jest renderowany na podstawie początkowej odpowiedzi HTML.

W aplikacji React typu SPA LCP często jest opóźniany, ponieważ przeglądarka musi pobrać i wykonać JavaScript, zanim React wyrenderuje element LCP. W przypadku Islands Architecture treść LCP znajduje się w początkowym kodzie HTML, więc wykonywanie JavaScriptu nie blokuje LCP. Jest to jedna z najważniejszych mierzalnych korzyści.

Łączny czas blokowania mierzy, jak długo główny wątek jest blokowany przez zadania JavaScript trwające dłużej niż 50 ms. Hydratacja dużej aplikacji React SPA może generować setki milisekund TBT. Architektura wysp znacznie zmniejsza TBT, ponieważ ilość wykonywanego JavaScriptu jest proporcjonalna do liczby wysp, a nie do rozmiaru strony.

Skumulowane przesunięcie układu mierzy stabilność wizualną — przemieszczanie się elementów podczas ładowania strony. Treści renderowane za pomocą JavaScriptu mogą powodować przesunięcia układu, gdy React renderuje elementy i zmienia ich wymiary. HTML renderowany po stronie serwera przez architekturę wysp zapobiega przesunięciom układu związanym z hydratacją, ponieważ początkowy układ pochodzi ze statycznego HTML, który nie zmienia się podczas hydratacji.

Opóźnienie pierwszego wejścia (First Input Delay, obecnie zastąpione przez Interaction to Next Paint, INP) mierzy, jak szybko strona reaguje na interakcje użytkownika. Architektura wysp poprawia INP, ponieważ każda wyspa ma mały, skoncentrowany pakiet JavaScriptu. Interakcje wewnątrz wyspy są wykonywane szybko, ponieważ nie trzeba planować pracy w dużym drzewie React.

Typowe porównanie dla strony bloga wygląda następująco: pełna aplikacja React SPA może uzyskać w mobilnym Lighthouse wynik 45–65 (TBT: 800 ms, LCP: 3,2 s). Ta sama treść jako witryna Astro z jedną wyspą React może uzyskać wynik 90–98 (TBT: 80 ms, LCP: 1,1 s). Zyski są najbardziej widoczne na stronach zawierających dużo treści i oferujących niewiele interakcji.

Architektura wysp nie jest właściwym wyborem dla wysoce interaktywnych aplikacji, takich jak pulpity nawigacyjne, edytory kodu czy narzędzia do współpracy. W tych aplikacjach komponenty stale współdzielą stan i są wspólnie renderowane ponownie — narzut komunikacji między wyspami zniwelowałby zyski wydajnościowe i zwiększył złożoność architektury.

Architektura wysp doskonale sprawdza się w witrynach zawierających dużo treści i oferujących rozproszoną interaktywność: blogach (czytanie treści, sporadyczne polubienie lub komentarz), dokumentacji (czytanie dokumentacji, sporadyczne wyszukiwanie lub przycisk kopiowania kodu), stronach docelowych (głównie statycznych, z wyspą formularza newslettera) oraz stronach produktów w sklepach internetowych (statyczne obrazy i opis, wyspa dodawania do koszyka).

Google wykorzystuje Core Web Vitals (LCP, INP, CLS) jako sygnały rankingowe. Poprawa tych wskaźników za pomocą architektury wysp bezpośrednio wpływa na pozycję w wynikach wyszukiwania. Witryna, która dzięki zastosowaniu architektury wysp poprawia swój mobilny wynik Lighthouse z 55 do 92, jednocześnie zyskuje zarówno lepsze doświadczenia użytkowników, jak i korzyści SEO.

Zespoły migrujące z Next.js React SPA do Astro w przypadku witryn marketingowych i dokumentacji zgłaszają powtarzalne rezultaty: rozmiar pakietów JavaScriptu zmniejsza się o 70–90%, wyniki wydajności mobilnej rosną o 20–40 punktów, a koszty hostingu serwera spadają, ponieważ pliki statyczne są udostępniane z CDN bez narzutu renderowania po stronie serwera przy każdym żądaniu.

Architektura wysp poprawia wszystkie wskaźniki Core Web Vitals: LCP korzysta z HTML renderowanego po stronie serwera, TBT spada, ponieważ ilość JavaScriptu jest proporcjonalna do poziomu interaktywności, CLS ulega zmniejszeniu dzięki stabilnym układom renderowanym po stronie serwera, a INP się poprawia dzięki małym, skoncentrowanym pakietom wysp. Wyniki Lighthouse dla stron zawierających dużo treści poprawiają się znacząco. Ten wzorzec nie sprawdza się w przypadku wysoce interaktywnych aplikacji, ale doskonale nadaje się do blogów, dokumentacji, stron docelowych i sklepów internetowych.