Metoda renderowania ma niebagatelny wpływ na całą architekturę projektowanej aplikacji internetowej. W przeszłości jedynym dostępnym w tym zakresie rozwiązaniem było renderowanie po stronie serwera, jednak sposób ten okazywał się w wielu przypadkach niewystarczający. Większość stron miała wówczas charakter statyczny, służyła do wyświetlania prostych grafik i statycznych treści, w związku z czym nie wymagała zbyt dużej liczby interakcji. Dziś renderowanie po stronie serwera jest wykorzystywane głównie za sprawą wysokiej wydajności, nie stanowiąc już jednak jedynej metody przenoszenia kodu HTML na ekran. Programiści mogą obecnie wybierać między renderowaniem po stronie serwera, renderowaniem po stronie klienta czy tzw. wstępnym renderowaniem lub statycznymi generatorami typu Gatsby czy NextJS. Chcesz wiedzieć konkretnie, co to jest renderowanie i na czym polegają różnice pomiędzy renderowaniem po stronie klienta a renderowaniem po stronie serwera? Przeczytaj poniższy artykuł!
Co to jest renderowanie po stronie klienta (CSR)?
Rendering po stronie klienta ma miejsce bezpośrednio w przeglądarce użytkownika i odbywa się za pomocą JavaScript. Jest to jednoznaczne z faktem, że cała logika i routing, a także pobieranie potrzebnych danych i budowanie szablonów to czynności, które są obsługiwane po stronie klienta, a nie na serwerze. Oznacza to tym samym, że połączenie z serwerem dokonuje się tylko w celu pobrania danych wykonawczych. Natomiast użytkownik otrzymuje podstawowy dokument z plikiem JavaScript (zamiast pobierania pełnej zawartości dokumentu HTML), który manipulując elementami DOM, wyrenderuje resztę witryny za pomocą przeglądarki.
Wspomniane elementy DOM to bowiem tzw. żywe drzewo dokumentów – kod HTML jest przekształcany przez przeglądarkę na jego reprezentację w pamięci komputera. Dlatego renderowanie po stronie klienta nie wymusza powtórnego ładowania interfejsu użytkownika po każdym kolejnym wywołaniu serwera. Pozwala to na aktualizowanie interfejsu o zmienione dane i renderowanie tylko wybranego komponentu DOM, bez potrzeby ponownego ładowania całej strony. Ma to korzystny wpływ na szybkość wczytywania serwisu po początkowym ładowaniu. Warto bowiem wiedzieć, że w przypadku renderowania po stronie klienta przeglądarka musi czekać na pobranie i wykonanie całego pakietu JavaScript, co w konsekwencji wydłuża czas początkowego ładowania.
Zalety renderowania po stronie klienta
Rendering po stronie klienta to metoda popularna zwłaszcza za sprawą społeczności frontendowej i bibliotek takich jak np. React.js czy Vue.js. Zaletą CSR jest przede wszystkim fakt, że jest to relatywnie szybkie i responsywne rozwiązanie, ponieważ po początkowym załadowaniu cały kod HTML strony jest generowany po stronie klienta z wykorzystaniem JavaScript.
Kod JS ułatwia pobieranie danych w czasie rzeczywistym, a także obsługiwanie ich po stronie klienta, wykonując w tym celu zewnętrzne wywołania API. To znaczący wyróżnik, który decyduje o pewnej przewadze tej metody nad renderingiem SSR. Najbardziej uwidacznia się on w przypadku bardzo spersonalizowanych aplikacji, które do prawidłowego działania wymagają precyzyjnych informacji o użytkownikach, co wiąże się z kolei z większą liczbą wywołań API i trackingiem. W procesie tworzenia tego rodzaju aplikacji niektóre funkcjonalności mogą okazać się niemożliwe do wykonania po stronie serwera. Witryna renderowana po stronie klienta tworzy każdą trasę bezpośrednio w przeglądarce, dynamicznie zarządza routingiem, nie potrzebując w tym celu odświeżania witryny za każdym razem, gdy użytkownik zażąda innego działania.
To wszystko sprawia, że renderowanie po stronie klienta to dobry wybór, gdy projektowana aplikacja charakteryzuje się złożonym interfejsem użytkownika z mniejszą liczbą funkcji. Rendering tego typu to uzasadniony pomysł również w sytuacji, gdy mamy do czynienia z dużymi i dynamicznymi danymi, a docelowa aplikacja ma obsługiwać dużą liczbę użytkowników.
Wady renderowania po stronie klienta
Wadą renderowania strony metodą CSR może niekiedy okazać się nieco dłuższy czas wstępnego ładowania. Dzieje się tak, ponieważ przeglądarka musi poczekać na pobranie i wykonanie pakietu JS po stronie klienta, zanim przejdzie do wstępnego renderowania. Fakt ten powoduje kolejne ryzyko, że użytkownik wyświetli pustą stronę (jeśli nie ma włączonej obsługi JS w swojej przeglądarce). Z tego powodu aplikacja będzie te trudniej dostępna dla robotów indeksujących, co ma bezpośrednie przełożenie na proces pozycjonowania strony internetowej. Ważną informacją w kontekście renderingu po stronie klienta jest również to, że ilość wymaganego JS rośnie wraz z rozwojem aplikacji, co może być kłopotliwe, gdy trzeba będzie dodać nowe biblioteki lub kod stron trzecich.
Co to jest renderowanie po stronie serwera (SSR)?
Renderowanie po stronie serwera polega na generowaniu kodu HTML dla danej strony po stronie serwera. W praktyce wygląda to tak, że za każdym razem, gdy odwiedzamy daną stronę internetową, nasza przeglądarka wysyła zapytanie do serwera, który obsługuje zawartość tej witryny. Czas potrzebny przeglądarce na otrzymanie pierwszego bajta zawartości serwisu to tzw. time to first byte (TTFB). Przyjmuje się, że żądanie powinno zajmować zaledwie kilka milisekund, jednak w praktyce czas reakcji serwera zależy od kilku czynników. Wśród najistotniejszych z nich warto wymienić:
- szybkość internetu i stabilność połączenia;
- odległość między klientem a serwerem;
- liczba użytkowników korzystających ze strony;
- stopień zoptymalizowania witryny pod kątem szybkości ładowania.
W momencie, gdy zakończy się przetwarzanie takiego żądania, przeglądarka otrzymuje w całości wyrenderowany kod HTML, a następnie wyświetla go na ekranie użytkownika. W sytuacji, gdy użytkownik zechce odwiedzić inną stronę w witrynie, przeglądarka ponownie zażąda nowych informacji – proces ten będzie wykonywany za każdym razem, gdy użytkownik odwiedzi stronę. Nawet jeśli nowa strona zawiera małą liczbę nowych elementów, przeglądarka mimo wszystko poprosi o całą nową stronę i powtórnie wyrenderuje wszystko od podstaw.
Zalety renderowania po stronie serwera
Kluczową zaletą wymienianą w kontekście SSR jest to, że generowanie kodu HTML odbywa się po stronie serwera, co eliminuje ryzyko wyświetlenia pustej strony użytkownikowi. Za faktem tym idzie również szybszy czas początkowego ładowania strony. Jest to możliwe, ponieważ otrzymany z serwera HTML pozwala na natychmiastowe wyświetlenie, nie wymagając przy tym pobierania oddzielnego pakietu JS. Renderowanie po stronie serwera ma też pozytywny wpływ na SEO strony i jej widoczność w wynikach wyszukiwania. Dzięki temu, że kod HTML jest tworzony po stronie serwera, roboty indeksujące mogą bowiem znacznie łatwiej i szybciej indeksować taką witrynę.
Warto dodać ponadto, że SSR zapewnia szybkie FP (ang. first paint, czyli pierwszy moment, w którym dowolny piksel staje się widoczny dla użytkownika). Dodatkowo serwer zarządza kodem szybciej niż skrypty, co sprawia, że może sprawnie uruchamiać żądania tysięcy użytkowników, podczas gdy komputery użytkowników niejednokrotnie zawierają dużo nieużywanej mocy obliczeniowej.
Wady renderowania po stronie serwera
W tym punkcie warto zwrócić uwagę, że rendering po stronie serwera wiąże się z nieco niższą responsywności w przypadku wystąpienia słabego połączenia internetowego lub jego całkowitego braku. Powodowane jest to faktem, że każda nawigacja w obrębie serwisu w celu otrzymania kodu HTML przebiega w obie strony do serwera.
