Renderowanie po stronie klienta (CSR) a renderowanie po stronie serwera (SSR) – co wybrać, dlaczego i kiedy?
Gdy użytkownik wpisuje adres URL witryny w pasku wyszukiwania przeglądarki, do serwera witryny wysyłane jest żądanie, a aplikacja internetowa dostarcza żądaną stronę z serwera do przeglądarki. Stamtąd kolejne podstrony są dostarczane bezpośrednio z serwera (renderowanie po stronie serwera) lub JavaScript jest wykonywany w przeglądarce na Twoim komputerze, dzięki czemu zawartość witryny jest dostarczana bezpośrednio z przeglądarki (renderowanie po stronie klienta). Większość użytkowników Internetu tak naprawdę nie zauważa dużej różnicy między renderowaniem po stronie serwera (ang. Server Side Rendering – SSR) a renderowaniem po stronie klienta (and. Client Side Rendering – CSR) jednak dla programistów decyzja, czy skonfigurować aplikację internetową pod kątem CSR lub SSR, często stanowi dylemat.
Od czasu wynalezienia wyszukiwarek standardowa metoda wyświetlania HTML na ekranie odbywała się poprzez renderowanie po stronie serwera (SSR). W tamtych czasach był to jedyny sposób obsługi stron internetowych, które wyświetlały głównie statyczne obrazy i tekst.
Czasy się zmieniły i obecnie strony internetowe są o wiele bardziej złożone. Nie spotkamy już tak często jak kiedyś stron statycznych. Strony internetowe wykorzystywane są do komunikacji, dokonywania transakcji, oglądania video. Dlatego też obecnie większość nowoczesnych stron internetowych opiera się na elastyczniejszych od SSR technikach renderowania po stronie klienta, ponieważ CSR umożliwia tworzenie bardziej dynamicznych, skalowalnych aplikacji internetowych jak SPA (Single Page Application).
Pojawienie się frameworków JavaScript umożliwiło renderowanie dynamicznych treści bezpośrednio z przeglądarki. Poskutkowało to szybszym ładowaniem stron internetowych, co przekłada się na bezproblemowe doświadczenie użytkownika. Użytkownicy mogą teraz łatwo uzyskać dostęp do swoich ulubionych stron internetowych bez większych trudności lub opóźnień.
Zmiana podejścia do renderowania stron internetowych z serwerowego (SSR) na klienckie (CSR) to trend, jednak nie znając indywidualnych założeń trudno określić, co będzie lepsze dla Twojego projektu. Zwłaszcza nie wiedząc, ile mocy obliczeniowej wymaga każda z opcji lub czy wspierają one specyficzne funkcje, takie jak WebGL.
Podobnie jak inne aspekty tworzenia oprogramowania, wszystko zależy od tego, co planujesz zrobić ze swoją witryną. W tym artykule przyjrzymy się bliżej SSR i CSR, abyś mógł zdecydować się na najlepszą drogę rozwoju strony.
O JavaScript(JS) było wspomniane na początku, ale możesz zapytać, jak odnosi się on do technologii stron i SEO? Wszystko sprowadza się do tego, w jaki sposób Google przemierza i indeksuje witrynę.
Google boty – czyli roboty wyszukiwarek nie działają jak pełnoprawne przeglądarki internetowe, ponieważ muszą poruszać się po ogromnej sieci treści. Oznacza to, że niektóre z tych botów nie obsługują JS ani nie obsługują CSR. Dlatego SSR był kiedyś uznawany za najlepszą metodę renderowania treści zapewniającą prawidłowe indeksowanie treści HTML przez boty wyszukiwarek.
SSR to najczęstsza metoda wyświetlania treści na ekranie. Działa poprzez konwersję plików HTML na serwerze na przydatne informacje dla przeglądarki.
Oto jak to działa. Kiedy odwiedzasz stronę internetową, twoja przeglądarka wysyła zapytanie do serwera. Po przetworzeniu tego żądania przeglądarka interpretuje treść i wyświetla stronę. Cały proces pobierania danych z bazy, tworzenia strony HTML i odsyłania jej z powrotem do przeglądarki trwa zaledwie kilka milisekund.
Jeśli zdecydujesz się odwiedzić inną stronę internetową, proces po prostu się powtarza. Pamiętaj jednak, że może to zwiększyć obciążenie serwera i zużyć niepotrzebną przepustowość Internetu.
Z drugiej strony CSR to stosunkowo nowe podejście do renderowania stron internetowych. Zyskał na popularności, gdy biblioteki JS zaczęły się rozrastać i dominować.
Korzystanie z CSR pozwala deweloperom tworzyć strony internetowe renderowane w całości w przeglądarce przy użyciu JS. Oznacza to, że zamiast mieć inną stronę HTML na trasie, witryny CSR tworzą każdą trasę dynamicznie w przeglądarce. Możesz zauważyć, że początkowe ładowanie strony dla CSR może być nieco powolne, ale zwiększa się wraz z szybszymi czasami ładowania kolejnych stron.
W przeciwieństwie do SSR komunikacja z serwerem odbywa się tylko podczas pozyskiwania danych. Co więcej, CSR eliminuje potrzebę ponownego ładowania całego interfejsu użytkownika po każdym wywołaniu serwera.
Trywializując porównanie SSR do CSR to CSR jest jak zatankowanie przez kuriera samochodu paliwem do pełna w celu zgromadzenia potrzebnego surowca na cały dzień pracy, a SSR to konieczność tankowania za każdym razem, gdy na nowo odpalimy samochód.
Istnieją trzy główne różnice pomiędzy renderowaniem po stronie klienta i po stronie serwera, które szczegółowo omówimy.
Czas ładowania to czas, w którym przeglądarka żąda strony z serwera i wyświetla ją w przeglądarce. Pamiętaj, że dłuższe czasy ładowania mogą mieć negatywny wpływ na funkcjonalność Twojej strony, ponieważ spowodują, że strony będą ładować się wolniej niż przewidywano.
Początkowy czas ładowania to średni czas potrzebny użytkownikowi na załadowanie Twojej strony po raz pierwszy. Podczas używania CSR, przeglądarka ładuje podstawowy HTML i CSS przed załadowaniem jakichkolwiek funkcji JavaScript, aby poprawić problemy z opóźnieniami. W przypadku SSR, zawartość jest pobierana z serwera podczas początkowego ładowania strony, a oczekiwanie do czasu po renderowaniu strony zostaje zminimalizowane. W rezultacie możesz oczekiwać, że SSR załaduje pierwszą stronę znacznie szybciej.
Kolejny czas wczytywania opisuje czas potrzebny na przejście z jednej strony na drugą. CSR skraca średni czas ładowania strony, ponieważ automatycznie ładuje wszelkie skrypty pomocnicze, których potrzebuje strona.
Z drugiej strony, SSR nie ma szybszej reakcji w kolejnych załadowaniach stron internetowych. CSR reaguje szybciej podczas ładowania kolejnych stron internetowych oraz jesteśmy w CSR wdrożyć statyczną sieć dostarczania treści (CDN), a przy SSR już nie.
Buforowanie jest techniką, która polega na przechowywaniu kopii plików w tymczasowych lokalizacjach pamięci masowej, aby można było uzyskać do nich szybszy dostęp. Możesz oczekiwać poprawy czasów ładowania SSR i CSR, jeśli buforowanie jest prawidłowo stosowane.
Chociaż aplikacje internetowe CSR i SSR mają wiele podobieństw, pozostaje jedna kluczowa różnica. Podczas ładowania strony, w aplikacjach opartych na CSR nie jest potrzebny moduł lazy loading, aby mogły one działać bez połączenia z Internetem. Po załadowaniu strony nie ma już potrzeby wysyłania żądań do serwera.
Z SSR, każde żądanie do serwera wysyła odpowiedź niezależnie od tego czy jest to nowy, czy zbuforowany plik. W związku z tym, musimy spodziewać się wyższych czasów ładowania, jak również zwiększonych opóźnień dla odpowiedzi, które nie są wstępnie zbuforowane.
W przeciwieństwie do tego, CSR oznacza, że przeglądarka buforuje skrypty i może renderować statyczne strony ze znacznie większą szybkością, ale zawsze zostaje pytanie, czy równie skutecznie renderować będą boty wyszukiwarek?
Optymalizacja witryny pod kątem SEO powinna być priorytetem. Dzieje się tak, ponieważ pierwszą rzeczą, na którą patrzą wyszukiwarki są metadane – tytuły, adresy URL, kategoryzacje i słowa kluczowe Twojej strony.
Podczas korzystania z CSR zawartość Twojej witryny jest automatycznie generowana przez JS. Oznacza to, że zmiana metadanych z jednej strony na drugą zależy od wykonania JS. Z kolei wymaga użycia wtyczek lub modułów bibliotecznych do ustawienia metadanych dla każdej strony, tak aby były one renderowane po stronie klienta.
Tymczasem dzięki SSR kompletne strony są kompilowane z odpowiednimi metadanymi. Po otrzymaniu ostatecznej zawartości HTML są wysyłane do interfejsu użytkownika. Ta metoda gwarantuje, że metadane strony pozostaną dokładne, niezależnie od tego, czy boty wyszukiwarek posiadają zezwolenia na używanie JS, czy nie.
Można więc powiedzieć, że zaletą stron SSR jest to, że są one bardziej przyjazne dla SEO, chodź wyszukiwarki coraz lepiej radzą sobie z renderowaniem po swojej stronie. Zalety SSR to też fakt, że Google faworyzuje strony z szybkim czasem ładowania.
Wcześniej, twórcy stron internetowych mieli tylko jedną opcję renderowania: po stronie serwera. Ale odkąd renderowanie po stronie klienta zostało wprowadzone, możesz się zastanawiać, które podejście jest najlepsze dla Twojej strony lub aplikacji.
Ponownie, wybór między tymi dwoma zależy od sytuacji:
Serwery często znajdują się na maszynach o dużej mocy obliczeniowej i szybszych połączeniach sieciowych. Dlatego można liczyć na serwery, jeśli chodzi o dodatkową moc potrzebną do przetworzenia dużych żądań. Długi czas renderowania w normalnych warunkach (nie obciążony serwer dużą ilością zapytań) raczej im nie grozi. Kiedy posiadasz budżety na mocniejszy serwer to ma to sens, dlaczego pobieranie treści po stronie serwera jest znacznie szybsze. Pamiętać należy również, że i od tego warunku mogą być wyjątki. SSR może przyczynić się do poprawy wydajności, jeśli aplikacja jest dobrze napisana lub po prostu mała. Jednocześnie, jeśli posiada błędy w konstrukcji (jest ciężka) może również obniżyć wydajność. Po części, dlatego, że w SSR wykonuje się więcej wywołań API do serwera, ponieważ są za każdym razem wykonywane na żądanie.
Maszyny po stronie klienta mają jednak ograniczoną moc obliczeniową. Przekłada się to na więcej czasu potrzebnego na ukończenie renderowania treści. Poza tym nie wiemy i nie mamy dostępu do informacji czym jeszcze jest obciążony komputer klienta. Dlatego jeśli Twoja witryna wymaga wielokrotnego dynamicznego renderowania treści, SSR jest lepszym wyborem.
Aplikacje i witryny internetowe to dwa różne formaty treści internetowych. Aplikacje internetowe wymagają większej interakcji, ponieważ użytkownicy muszą wykonywać takie zadania, jak wprowadzanie danych i generowanie raportów. Często również posiadają i udostępniają zewnętrzne API. Z drugiej strony strona internetowa to po prostu strona, która oferuje informacje o firmie.
Mając to na uwadze, CSR działa najlepiej w przypadku aplikacji internetowych, ponieważ może zapewnić, że każde kliknięcie nie zajmie zbyt wiele czasu. Jednak jeśli chodzi o strony internetowe, SSR wypada lepiej niż CSR, ponieważ zapewnia odpowiednie metadane dla botów wyszukiwarek. Ponadto mechanizmy buforowania mogą przyspieszyć renderowanie, gdy użytkownicy przechodzą z jednej strony internetowej na drugą.
Znając wady i zalety oraz różnicę między SSR a CSR i kiedy wiemy należy zastosować każdą metodę, możesz się zastanawiać, czy istnieje sposób na połączenie szybkiego ładowania początkowej strony SSR z wydajnością CSR – tak dla optymalnego SEO.
Odpowiedź brzmi tak. Niektóre nowoczesne frameworki działają w ramach podejścia hybrydowego takie jak np. React JS, Next.js czy GatsbyJS. Te struktury ładują początkowe strony za pomocą SSR, a następnie używają CSR do ponownego ładowania kolejnych stron, czy części treści. W ten sposób uzyskasz to, co najlepsze z obu sposobów. Tego typu aplikacje nazywane są też aplikacjami izomorficznymi. Do tego typu stron można zaliczyć strony, których pierwotnie PHP/C#/Java/Ruby jest renderowany na kod HTML na serwerze, a następnie JavaScript na kliencie. Upraszczając – praca odbywa się zarówno na serwerze jak i na kliencie.
Nawet jeśli nie chcesz użyć nowoczesnych frameworków, właściwe podejście do renderowania będzie zależało od tego, na czym Ci bardziej zależy. Zwróć uwagę i rozważ użycie SSR i CSR z funkcjonalnego i praktycznego punktu widzenia. Wykonanie niewłaściwego połączenia może kosztować Cię w postaci przebudowy funkcjonalności witryny lub przepisania kodu.
Grzegorz
Maliszewski
HEAD OF BUSINESS DEVELOPMENT
tel. +48 577 997 701
e-mail g.maliszewski@promotraffic.pl
PromoTraffic to przede wszystkim wysoki standard obsługi. Jest to agencja, która podchodzi do zagadnienia marketingu w sposób kompleksowy.
Adam Grybalow
4FIZJO
Przeprowadzane przez PromoTraffic kampanie są kluczowe dla naszego biznesu. Razem skutecznie realizujemy je na ponad 20 rynkach.
Łukasz Gwóźdź
Picodi
Ponad 11 lat doświadczenia, nieustanny #PROgress i sukcesy naszych Klientów.
