Next.js 14’s Server Components zmniejszają rozmiar paczki o około 60% i skracają czas first-paint do poniżej 200 ms na typowej stronie bloga, co oznacza, że użytkownicy szybciej widzą treść, a wyszukiwarki otrzymują w pełni wyrenderowany kod HTML.

Nowa wersja odwraca domyślny model wykonywania aplikacji React budowanych w Next.js. Tam, gdzie wcześniej każdy komponent był przesyłany do przeglądarki, programiści mogą teraz oznaczyć części interfejsu użytkownika jako „Server Components”, dzięki czemu będą one działać wyłącznie na backendzie. Kod tych komponentów nigdy nie dociera do klienta, pozostawiając przeglądarce jedynie te fragmenty, które wymagają interaktywności.

Dlaczego ta zmiana jest istotna

Deweloperzy React od dawna zmagają się z trzema powiązanymi ze sobą problemami: lawiną żądań sieciowych, przeładowanymi paczkami JavaScript oraz powolnym ładowaniem stron. Problemy te negatywnie wpływają również na SEO, ponieważ początkowy kod HTML wysyłany do robotów wyszukiwarek jest często pusty, co zmusza je do oczekiwania na hydratację po stronie klienta. Next.js 14 rozwiązuje przyczynę problemu, całkowicie przenosząc ciężkie operacje na dane poza klienta.

Czym Server Components różnią się od starego modelu

  • Server Components – Wykonują się na serwerze, pobierają dane, komunikują się z bazami danych i generują czysty HTML. Ich kod JavaScript nigdy nie jest przesyłany przez sieć.
  • Client Components – Pozostają w przeglądarce i obsługują interakcje z interfejsem, takie jak kliknięcia przycisków, przesyłanie formularzy czy dowolne komponenty wykorzystujące stan (state) lub efekty (effects) Reacta.

Framework wymusza ten podział za pomocą prostej dyrektywy. Dodanie use client na górze pliku informuje Next.js, aby traktował dany komponent wyłącznie jako klientowski. Wszystko, co nie posiada tego znacznika, domyślnie staje się Server Componentem.

Liczby z rzeczywistych zastosowań

Krótki eksperyment na stronie osobistego bloga ilustruje ten wpływ. Po przeniesieniu operacji fetch do Server Componentu i pozwoleniu serwerowi na wyrenderowanie listy jako statycznego HTML-a, rozmiar paczki JavaScript zmniejszył się o 60%, a strona wyrenderowała się w czasie poniżej 200 ms.

Praktyczny wzorzec warstwowy

  1. Warstwa dolna (Server) – Pobiera dane z API lub baz danych. Tutaj należy trzymać całą prywatną logikę; nigdy nie opuszcza ona serwera.
  2. Warstwa środkowa (Server) – Przekształca surowe dane w czysty znacznik HTML. Warstwa ta może nadal używać składni JSX Reacta, ale pozostaje wyłącznie po stronie serwera.
  3. Warstwa górna (Client) – Wstawia małe, odizolowane widgety zapewniające interaktywność. Typowymi przykładami są przyciski „lubię to”, formularze komentarzy czy menu rozwijane wymagające stanu.

Przestrzeganie tej hierarchii sprawia, że większość aplikacji pozostaje lekka, zachowując jednocześnie dynamiczne odczucia, których oczekują użytkownicy.

Kroki, które możesz podjąć już dziś

  1. Przeszukaj swój kod w poszukiwaniu komponentów, które używają useEffect wyłącznie do pobierania danych.
  2. Wyodrębnij wywołanie fetch do nowego Server Componentu i pozwól mu zwrócić wyrenderowany znacznik.
  3. Utwórz minimalny komponent klientowy (dodając use client na górze) dla pozostałych elementów interaktywnych.
  4. Uruchom ponownie analizator paczki (bundle analyzer); powinieneś zauważyć wyraźny spadek rozmiaru.

Unikaj rozsiewania use client wszędzie. Jeśli komponent nie polega na stanie Reacta, kontekście (context) ani hookach cyklu życia, pozostaw go jako Server Component. Im więcej kodu zatrzymasz poza klientem, tym mniejsza będzie paczka do pobrania i tym szybciej załaduje się strona.

Podsumowanie: Dzięki przeniesieniu pobierania danych i ciężkiego renderowania na serwer, Next.js 14 pozwala przesyłać znacznie mniej kodu JavaScript, natychmiast dostarczać w pełni wyrenderowany HTML i zachować interaktywność tam, gdzie jest ona naprawdę potrzebna. Rezultatem jest szybsze i lżejsze doświadczenie internetowe, które przynosi korzyści zarówno użytkownikom, jak i wyszukiwarkom.