Server Side Rendering

Cover Image for Server Side Rendering
Krzysztof
Krzysztof

W dzisiejszym wpisie podejdziemy do renderowania aplikacji z innej strony. Zobaczymy czy da się połączyć SEO wraz z wydajnością i User Experience.

Powrót do przeszłości

W jednym ze wcześniejszych wpisów wspominaliśmy, że dawniej strony napisane w PHP korzystały z server side renderingu.

Miało to szereg konsekwencji i ograniczeń. Technologia, której dzisiaj się przyjrzymy zupełnie inaczej radzi sobie z tymi problemami

W obecnych czasach rzadko można spotkać stronę internetową, która nie wykorzystuje JavaScript i zmusza użytkownika do odświeżenia podczas nawigacji między podstronami. Jednakże coraz bardziej konkurencyjne środowisko wymaga dobrego SEO i pozycjonowania.

W tym celu powracamy do znanej techniki: Server Side Rendering, ale w nieco odświeżonej odsłonie. Podobnie jak wcześniej generowanie HTML’a wraz z pobieraniem treści to odpowiedzialność serwera.

Tym razem jednak otrzymamy także dużą interaktywność oraz unikniemy konieczności odświeżania.

Czy da się zjeść ciastko i mieć ciastko?

Odpowiedzią na to pytanie jest hydracja (hydration)

Hydration

W dużym uproszczeniu hydracja to proces "ożywiania" statycznego HTML’a za pomocą JS’a. Dodawane są event handlery, client side routing itp. Dzięki temu nawet coś, co jest wyrenderowane na serwerze może zachowywać się jak klasyczna aplikacja SPA

Sam proces hydracji może być dość długi i całkiem skomplikowany. Istnieje wiele technik, aby usprawnić cały mechanizm, jednakże są one mocno skomplikowane i wykraczają poza ten artykuł.

Poniżej wrzucamy linki do 3 najbardziej popularnych technik optymalizacji hydration:

Większość technik wymaga samodzielnej konfiguracji całego frameworku, więc jest to temat na osobny wpis. Na potrzeby tego artykułu załóż, że wszędzie korzystamy z klasycznego hydration.

Proces krok po kroku

  1. Użytkownik wysyła żądanie do serwera w celu pobrania strony. Może się to odbyć poprzez kliknięcie w link lub za pośrednictwem wyszukiwarki
  2. Serwer generuje HTML oraz uzupełnia go danymi, które również pobrał po swojej stronie i wynik zwraca użytkownikowi
  3. Klient już widzi zawartość, ale nie jest ona interaktywna. Przeglądarka pobiera więc z serwera dodatkowe assety w tym skrypty JS
  4. Po uruchomieniu pobranego JS'a następuje dodanie do strony obsługi zdarzeń oraz zapewnienie ogólnej interaktywności (proces hydracji)

W wyniku tego użytkownik całkiem szybko mógł zobaczyć treść (First Contentful Paint). Chwilę później strona stała się także interaktywna jak klasyczna aplikacja SPA (dzięki hydracji w 4 kroku)

Najlepiej podsumować to grafiką:

Server Side Rendering Diagram

Wady i Zalety

Na pierwszy rzut oka wszystko wydaje się idealne, gdyż łączymy korzyści związane ze starszymi stronami opartymi na PHP z wysoką interaktywnością JavaScript.

Po głębszym przeanalizowaniu sprawa jednak nie wygląda już tak kolorowo. Przeanalizujmy teraz za i przeciw:

Zalety:

  1. Mniej wymaganego kodu JS to mniejszy bundle i tym samym krótszy czas ładowania co pozytywnie wpływa na First Contentful Paint
  2. Rozwiązanie jest SEO friendy, gdyż boty z łatwością potrafią analizować statyczną zawartość
  3. Zyskujemy więcej swobody w dodawaniu kolejnych bibliotek do naszego kodu. Skoro i tak całość nie jest przesyłana to każdy byte kodu nie jest aż tak krytyczny dla wydajności
  4. W wyniku tego, że ciężar renderowania leży, po stronie serwera witryna z SSR będzie działała sprawnie nawet na słabszych urządzeniach (np. starych telefonach)

Wady:

  1. SSR wymaga mocnego serwera lub kilku wraz z load balancerem, gdyż użytkownicy będą mocno go obciążać
  2. Strona ze statycznym HTML, ale proces hydracji może potrwać długo, w wyniku czego Time to Interaktiv, będzie wolny, podobnie jak w przypadku renderowania po stronie klienta (CSR). Użytkownik zobaczy treść, ale początkowo bez możliwości interakcji z nią
  3. Konfiguracja serwera i całego środowiska jest o wiele bardziej skomplikowana
  4. Trudniej oddzielić świat frontendu od backendu. Wszystko zlewa się w jedną całość

Zastosowanie

Możemy samodzielnie zbudować całą konfigurację, jednakże jest to dosyć trudne. Zalecanym podejściem jest wykorzystanie jednego z popularnych frameworków.

Next.js pozwala na swobodny wybór pomiędzy różnymi typami renderowania. Między innymi dostępny jest SSR za pośrednictwem funkcji getServerSideProps

Odpowiednim wyborem może okazać się także Remix.js. Ten framework obsługuje SSR za pośrednictwem funkcji loader oraz action. Szersze wyjaśnienie znajdziesz tutaj

A kiedy warto pokusić się o takie rozwiązanie?

Przede wszystkim SSR jest odpowiednie dla projektów, które wymagają dobrego SEO i dynamicznych danych jednocześnie. W nowoczesnych frameworkach takich jak Next.js czy Remix.js aplikacja po procesie hydracji praktycznie działa jak SPA.

Unikać gdy:

  • SEO nie jest priorytetem
  • Chcemy utrzymywać jedynie prosty serwer o niskim obciążeniu (SSR wymaga skomplikowanej i wydajnej infrastruktury)

Podsumowanie

W powyższym materiale omówiliśmy w uproszczony sposób, jak działa Server Side Rendering. Całe to zagadnienie może być o wiele bardziej złożone i pełne niuansów. Mamy nadzieję, że ten artykuł będzie dla Ciebie doskonałą bazą do dalszego zgłębiania tematu