Czyli serwer robi wszystko a klient otrzymuje stronę „na gotowo”.
Javascript a SEO
W ciągu ostatnich piętnastu lat strony internetowe ewoluowały od prostego tekstu HTML do interaktywnych multimediów i dynamicznie generowanych treści. Dwa z najbardziej znaczących postępów w tworzeniu stron internetowych w tym okresie to rozpoczęcie stosowania JavaScript oraz powstanie całego sektora rynku opierającego się na optymalizacji stron pod kątem wyszukiwarek.
Jak na ironię, programowanie w JavaScript i SEO są często ze sobą sprzeczne. JavaScript sprawia, że strony internetowe są przyjemne i interesujące w użyciu, podczas gdy SEO sprawia, że są one dostępne dla ludzi w pierwszej kolejności (tj. przed innymi stronami o podobnej tematyce).
Wchodzi on, cały na biało
Renderowanie po stronie serwera (SSR) zostało stworzone, aby pogodzić te dwa żywioły. Server Side Rendering pozwala na generowanie zawartości strony od razu i w całości po stronie serwera. Chodzi o to aby przeglądarka otrzymała kod witryny gotowy do wyświetlenia na monitorze internauty. Podstawową zaletą jest polepszenie „czytelności” strony dla botów czy crawlerów – a bez dobrej współpracy z nimi nie ma mowy o dobrym SEO i korzystnej indeksacji przez wyszukiwarki takie jak chociażby Google. Gdy użytkownicy lub roboty sieciowe wyszukiwarek żądają strony, jej treść jest odczytywana jak by to była zwykła, statyczna strona HTML.
Jak to robi GoogleBot
W przeszłości wyszukiwarki miały trudności z przeszukiwaniem i indeksowaniem witryn internetowych utworzonych przy użyciu języka JavaScript, a nie HTML. Google indeksuje obecnie strony internetowe oparte na języku JavaScript przy użyciu systemu indeksowania dwuetapowego. Gdy Googlebot po raz pierwszy napotyka na daną witrynę, przeszukuje podstrony i wyodrębnia wszystkie ich kody HTML, CSS i linki – a może to trwać nawet kilka godzin.
Następnie Google umieszcza zawartość JavaScript w kolejce i renderuje ją, gdy ma zasoby. Czasami zajmuje to dni lub tygodnie. W tym czasie Twoje strony internetowe nie są indeksowane i w związku z tym nie można ich znaleźć w Google. To oznacza dużo ruchu, który tracisz. Co gorsza, jeśli Twoje strony JavaScript nie mogą być poprawnie zindeksowane, Google odczytuje je jako pusty ekran i odpowiednio klasyfikuje – a to już może mieć katastrofalne skutki dla SEO Twojej witryny.
Google twierdzi, że Googlebot jest w stanie przeszukiwać i indeksować strony internetowe oparte na Javascript, ale publicznie dostępnych dowodów na to brak. Inne wyszukiwarki, takie jak Bing, Yandex czy DuckDuckGo, z całą pewnością nie potrafią indeksować JavaScript.
Obliczamy na swoim serwerze żeby klient nie musiał
Niezależnie od wyszukiwarki JavaScript stanowi więc problem, ponieważ wymaga dodatkowej mocy obliczeniowej do pobierania i indeksowania witryby, pochłaniając tym samym większą część przydzielonego „budżetu” (głównie czasu) na indeksowanie witryny. SSR to odpowiedź na ten problem: renderuje JavaScript na własnych serwerach, zamiast obciążać komputer użytkownika, a dzięki temu zawartość strony jest szybko i łatwo dostępna.
Wady
Jeśli SSR jest o lepiej technicznie zoptymalizowany i przyjazny dla SEO to dlaczego nie wszystkie strony z niego korzystają? Okazuje się, że używanie SSR w witrynie ma kilka istotnych wad. Jest drogi, trudny do wdrożenia i wymaga sporo pracy przy jego konfigurowaniu. Nakładając ciężar renderowania treści JavaScript na własne serwery zwiększa koszty utrzymania serwera.
Co więcej, witryny korzystające ze struktur JavaScript potrzebują uniwersalnych bibliotek, aby umożliwić stosowanie SSR. Na przykład Angular wymaga Angular Universal a React i Vue wymaga Next.JS. Wszystkie mają tą cechę wspólną, że wymagają dodatkowej pracy zespołu.
Wreszcie strony SSR mają większe opóźnienie TTFB i oferują wolniejszą interakcję. Użytkownik Twojej witryny zobaczy zawartość wprawdzie wcześniej, ale jeśli coś kliknie, nic się nie stanie. Zniecierpliwi się i zamknie zakładkę.
Nie należy też mylić SSR z metodami wyświetlania stron przez same przeglądarki czyli na przykład z WebRender od Firefoksa.
