Pomiar wpływu strumieniowania: FCP, TTI i LCP

FCP mierzy czas od rozpoczęcia nawigacji do momentu, gdy pierwszy element treści (tekst, obraz lub tło) zostanie wyrenderowany na ekranie. Strumieniowanie poprawia FCP, ponieważ natychmiast wysyła powłokę HTML — przeglądarka może wyrenderować układ strony, nawigację i dowolny tekst widoczny bez przewijania, gdy tylko dotrą pierwsze fragmenty.

W przypadku synchronicznego SSR (renderToString) przeglądarka nie otrzymuje żadnego kodu HTML, dopóki całe renderowanie się nie zakończy. W przypadku strumieniowania przeglądarka otrzymuje powłokę HTML w ciągu milisekund od otrzymania żądania — układ strony i statyczna treść pojawiają się niemal natychmiast, znacznie skracając FCP.

LCP mierzy czas do wyrenderowania największego widocznego elementu w obszarze widoku — zazwyczaj obrazu hero lub dużego nagłówka. Strumieniowanie poprawia LCP, jeśli element LCP jest częścią powłoki (a nie granicy Suspense), ponieważ powłoka jest strumieniowana przed sekcjami zależnymi od danych.

Kluczowa optymalizacja polega na zaprojektowaniu strony tak, aby element LCP — sekcja hero, główny nagłówek lub wyróżniony obraz — znajdował się poza każdą granicą Suspense. Jeśli element LCP znajduje się w granicy Suspense oczekującej na dane, strumieniowanie nie poprawi LCP do czasu rozwiązania tych danych.

TTI mierzy moment, w którym strona niezawodnie reaguje na dane wejściowe użytkownika — bez długich zadań blokujących główny wątek. Strumieniowanie połączone z selektywną hydratacją skraca TTI, rozkładając pracę związaną z hydratacją w czasie zamiast wykonywania jednego dużego, synchronicznego zadania hydratacji po pobraniu całego kodu JavaScript.

Czas do pierwszego bajtu (TTFB) zależy od opóźnienia sieciowego i czasu przetwarzania po stronie serwera przed wysłaniem pierwszego bajtu. Strumieniowanie nie zmienia TTFB — w tym miejscu pomaga renderowanie na brzegu sieci. Aby strumieniowanie poprawiło FCP, najpierw potrzebna jest niska wartość TTFB; w przeciwnym razie strumieniowanie odbywa się po prostu z wolnego serwera źródłowego.

Widok filmstrip w WebPageTest pokazuje sekwencję zrzutów ekranu wykonywanych co 100 ms podczas ładowania strony. Na stronie wykorzystującej streaming układ pojawia się wcześnie, a następnie kolejne sekcje są stopniowo wypełniane. Strona niewykorzystująca streamingu pokazuje pusty ekran, po którym nagle pojawia się w pełni wyrenderowana strona — to wyraźna różnica wizualna.

Miarodajny benchmark porównuje tę samą stronę renderowaną na dwa sposoby: z włączonym streamingiem Next.js RSC oraz przy użyciu tradycyjnego synchronicznego SSR. Należy użyć WebPageTest ze stałymi warunkami sieciowymi (np. Fast 3G i 4x CPU slowdown) oraz porównać metryki FCP, LCP i TTI w 3 uruchomieniach testu, aby uzyskać wiarygodność statystyczną.

Karta Network w Chrome DevTools zawiera listę rozwijaną "Throttling" z ustawieniami wstępnymi, takimi jak Fast 3G i Slow 4G. Fast 3G (1,6 Mb/s, RTT 150 ms) uwydatnia różnicę między streamingiem a jego brakiem, ponieważ wydłuża czas pobierania całego dokumentu HTML, dzięki czemu korzyści z przesyłania przyrostowego stają się widoczne.

Interaction to Next Paint (INP) mierzy czas od dowolnej interakcji użytkownika do następnego wyrenderowania. W 2024 roku zastąpiła FID jako podstawowa metryka internetowa (Core Web Vital). Streaming zmniejsza INP, nadając priorytet hydracji interaktywnych komponentów, z którymi użytkownik najprawdopodobniej wejdzie w interakcję jako pierwszymi, i skracając czas blokowania przed uzyskaniem przez te komponenty responsywności.

Największy efekt daje konfiguracja łącząca renderowanie na brzegu sieci (niski TTFB dzięki pobliskiemu PoP), streaming (stopniowe dostarczanie HTML) oraz selektywną hydrację (stopniowe przetwarzanie JavaScriptu). Razem te trzy techniki minimalizują wartości wszystkich głównych metryk wydajności w całym cyklu ładowania.

Jaką metrykę wydajności React streaming poprawia najbardziej bezpośrednio w przypadku treści widocznych bez przewijania?

Streaming najbardziej bezpośrednio poprawia FCP, natychmiast dostarczając szkielet HTML, a także poprawia LCP, gdy element LCP znajduje się w szkielecie. TTI poprawia się dzięki selektywnej hydracji, która rozkłada pracę JavaScriptu w czasie. TTFB pozostaje bez zmian — należy zająć się nim za pomocą renderowania na brzegu sieci. Do mierzenia wpływu streamingu należy używać widoku filmstrip w WebPageTest oraz ograniczania przepustowości w Chrome DevTools, a jako główną metrykę interaktywności w Core Web Vitals należy optymalizować INP.