Problem pełnej hydratacji

Hydratacja to proces, w którym React pobiera kod HTML wyrenderowany przez serwer i dołącza do niego moduły obsługi zdarzeń JavaScriptu. Serwer wysyła początkowy kod HTML (szybko), a następnie przeglądarka pobiera pakiet JavaScriptu i React «nawadnia» statyczny kod HTML, aby nadać mu interaktywność. Do zakończenia hydratacji strona wygląda na interaktywną, ale taka nie jest.

Tradycyjna aplikacja jednostronicowa wysyła do przeglądarki cały pakiet JavaScriptu. React musi go pobrać, przeanalizować, wykonać, a następnie dołączyć moduły obsługi zdarzeń do każdego komponentu w drzewie. W przypadku dużych aplikacji proces ten może trwać kilka sekund na urządzeniach mobilnych ze średniej półki.

Czas do interaktywności określa, jak długo użytkownik musi czekać, zanim będzie mógł wejść w interakcję ze stroną. Hydratacja bezpośrednio opóźnia TTI: strona może wyglądać na gotową (wyrenderowany przez serwer kod HTML jest widoczny), ale przyciski i formularze nie reagują, dopóki React nie zakończy dołączania modułów obsługi zdarzeń. Wysoka wartość TTI oznacza słabe doświadczenie użytkownika.

Rozważmy stronę marketingową: 80% jej zawartości stanowią statyczne teksty, obrazy i nagłówki, które nigdy się nie zmieniają. Tylko 20% obejmuje interaktywne widżety, takie jak formularz newslettera lub odtwarzacz wideo. Tradycyjna hydratacja SPA nadal uruchamia się dla 100% strony, niepotrzebnie przetwarzając statyczne komponenty.

Profilowanie wydajności w Chrome DevTools pokazuje koszt hydratacji. Na wykresie wodospadowym głównego wątku można rozpoznać zadanie «React hydration» jako długi blok wykonywania JavaScriptu po pierwszym renderowaniu. Im dłuższy jest ten blok, tym bardziej zajęty pozostaje główny wątek i tym mniej responsywna jest strona.

Im większe drzewo komponentów Reacta, tym więcej pracy wymaga hydratacja. React musi odwiedzić każdy komponent, porównać wyrenderowany przez serwer kod HTML z tym, który komponent wyrenderowałby samodzielnie, oraz dołączyć moduły obsługi zdarzeń. Złożona strona zawierająca setki komponentów może generować mierzalny narzut hydratacji nawet na szybkich urządzeniach.

React 18 wprowadził współbieżną hydratację, która pozwala Reactowi dzielić hydratację na mniejsze fragmenty i przekazywać przeglądarce kontrolę między nimi. Dzięki temu przeglądarka nie sprawia wrażenia całkowicie zawieszonej podczas hydratacji dużych drzew. Współbieżna hydratacja ogranicza jednak ten problem — nie eliminuje podstawowego kosztu.

Selektywna hydratacja (za pośrednictwem Suspense) pozwala Reactowi przeprowadzać hydratację komponentów zgodnie z priorytetem — interakcje użytkownika wywołują natychmiastową hydratację odpowiedniego komponentu. Poprawia to responsywność, ale nadal odbywa się w obrębie jednego drzewa Reacta: wszystkie komponenty w drzewie ostatecznie zostaną poddane hydratacji.

Podstawowa obserwacja stojąca za Islands Architecture jest taka, że większość typowej strony w ogóle nie potrzebuje JavaScriptu. Paski nawigacji, sekcje główne, linki w stopce, tekst wpisu na blogu i opisy produktów mają wyłącznie charakter prezentacyjny. Wymuszanie ich hydratacji jest z definicji marnotrawstwem.

Badania zespołów zajmujących się wydajnością stron internetowych pokazują, że czas analizy i wykonywania JavaScriptu jest dominującym kosztem na urządzeniach mobilnych. Pakiet JavaScriptu o rozmiarze 300 kB wymaga od przeciętnego telefonu z Androidem 2–3 sekund na analizę. Ograniczenie ilości JavaScriptu wysyłanego do przeglądarki przynosi nieproporcjonalnie duże korzyści wydajnościowe w porównaniu z dowolną optymalizacją wewnątrz Reacta.

Każdy kilobajt JavaScriptu dodany do aplikacji React zwiększa ilość pracy związanej z hydratacją. Nawet jeśli komponent ma wyłącznie charakter dekoracyjny, uczestniczy w hydratacji, jeśli znajduje się w drzewie Reacta. Ten «podatek od hydratacji» rośnie wraz z rozmiarem aplikacji, przez co utrzymanie dobrych wyników TTI staje się coraz trudniejsze w miarę jej rozwoju.

Tradycyjna hydratacja Reacta przetwarza całe drzewo komponentów, także statyczną treść, która nie potrzebuje JavaScriptu. Blokuje to czas do interaktywności i słabo skaluje się wraz z rozmiarem aplikacji. Udoskonalenia współbieżnej i selektywnej hydratacji w React 18 ograniczają ten problem, ale nie eliminują jego podstawowego kosztu. Kluczowa obserwacja: większość treści strony po prostu nie potrzebuje JavaScriptu, dlatego pełna hydratacja jest marnotrawstwem.