7 min

19 maja 2023

Porównanie renderowania po stronie serwera SSR i statycznych generatorów witryn SSG i IRS

Omówimy tematykę SSR i SSG oraz poznamy, kiedy warto wykorzystywać te rozwiązania. Rozpoczniemy od wprowadzenia historycznego, a następnie prześledzimy ich zastosowanie w praktyce, przy użyciu technologii jak Next.js i Nuxt.js.

Posłuchaj artykułu w wersji audio.

elevenlabs cover
Loading the Elevenlabs Text to Speech AudioNative Player...

Pojęcia użyte w artykule:

  • Renderowanie -  graficzne przedstawienie treści zapisanej cyfrowo w formie właściwej dla danego środowiska (np. wyświetlenie w oknie przeglądarki, strony WWW zapisanej w kodzie HTM

  • SPA - aplikacja jednostronicowa- aplikacja internetowa lub witryna internetowa, która wykorzystuje pojedynczy dokument HTML jako "opakowanie" dla wszystkich stron internetowych i organizuje interakcję użytkownika za pomocą dynamicznie ładowanego kodu HTML, CSS, JavaScript, zwykle za pośrednictwem AJAX lub podobnej technologii.

  • CSR - renderowanie po stronie klienta. Sposób renderowania aplikacji w przeglądarce przy użyciu modelu DOM.

  • SSR —server Side Rendering to sposób renderowania, budowania aplikacji po stronie serwera.

  • SSG — statyczny generator witryn. Generowanie strony statycznej to generowanie wszystkich stron HTML aplikacji w momencie uruchomienia jej na serwerze.

  • IRS — statyczny generator witryn z regeneracją contentu jaki był edytowany a nie wszystkich stron.

Witryny statyczne na początku sieci

Na początku istnienia Internetu, dostępne były jedynie strony statyczne, nic nie było generowane dynamicznie. Gotowe, zwykłe dokumenty HTML były wysyłane do klienta.

Kiedy użytkownik odwiedzał witrynę internetową, wysyłał proste żądanie HTTP do serwera, który następnie odpowiadał znacznikami wyświetlanymi w przeglądarce.

Później możliwe stało się wykorzystanie dynamicznego renderowania i budowania szablonów znaczników, takich jak w PHP. Te szablony pozwoliły na wypełnianie informacji wysyłanych do klienta HTML.  Każde żądanie HTTP przechodziło przez backend strony i zbierało niezbędne dane. Na przykład dodawanie elementów takich jak nazwy użytkowników, aktualne daty, dane z bazy i inne było dzięki temu możliwe. Tak wyglądało oryginalne renderowanie po stronie serwera (server-side rendering). Klient (przeglądarka) prosił serwer o potrzebny kod HTML do wyświetlenia, który był generowany na serwerze, a następnie wyświetlony w przeglądarce.

AJAX

Wraz z pojawieniem się technologii, takiej jak AJAX , pojawiła się możliwość żądania danych asynchronicznie, bez przeładowywania całej strony.

Z punktu widzenia doświadczenia użytkownika (UX), była to ogromna poprawa - skończyło się irytujące migotanie strony. Zaczęliśmy przechodzić w kierunku renderowania po stronie klienta.

Aby uprościć pracę z frontendem, zaczęły pojawiać się różne biblioteki i frameworki. Jedną z najpopularniejszych bibliotek stała się jQuery , ale nie była jeszcze pełnoprawnym narzędziem CSR (Client Side Rendering).

SPA (Single Page Application) i CSR (Client Side Rendering)

Potem przyszedł czas na React, Angular i Vue, dzięki którym zdecydowana większość deweloperów w końcu zapoznała się z pełnoprawnym renderowaniem po stronie klienta. Te trzy technologie wykorzystują podejście komponentowe i pozwalają rozbić znaczniki na małe części nadające się do wielokrotnego użytku. Teraz całe generowanie HTML odbywa się na interfejsie użytkownika. Backend służy tylko do skomplikowanych obliczeń, pracy z bazami danych, nasycania frontendu danymi itp.

Dzięki możliwości łatwego generowania znaczników po stronie klienta, SPA zyskały ogromną popularność.

Patrząc na to technicznie -  teraz serwer zaczął wysyłać do klienta prawie pusty HTML, który zawiera tylko podstawowe znaczniki, z pustym <div class='root'></div> i pojedynczym plikiem skryptowym <script src='bundle.js'></script>, w którym będzie cały kod do generowania znaczników, stylów i logiki napisane za pomocą JavaScript.

 

Niestety, takie podejście prowadziło również do szeregu potencjalnych problemów:

Najpierw pojawił się problem z optymalizacją pod kątem wyszukiwarek. Ponieważ roboty indeksujące Google czytają i indeksują strony internetowe, konieczne jest podawanie informacji o treści i znacznikach z serwera, a przy takim podejściu wszystko jest generowane na kliencie. Wyszukiwarki nie były wtedy w stanie przetwarzać generowanych w ten sposób informacji. Wszystko, co robot mógł zobaczyć, to pusty główny tag HTML.

Teraz sytuacja nieco się poprawiła, ponieważ wiele robotów wyszukujących nauczyło się wykonywać JavaScript wymagany do renderowania po stronie klienta. Niemniej jednak wynik takiego indeksowania wciąż pozostawia wiele do życzenia.

Drugim potencjalnym problemem jest wydajność. Ponieważ do wyświetlenia strony w przeglądarce wymagana jest duża ilość kodu JavaScript, aplikacja może działać dość wolno. Jest to szczególnie widoczne na starszych urządzeniach mobilnych.

Aby rozwiązać te problemy, programiści ponownie wrócili do pomysłu generowania znaczników na serwerze.

Powrót do renderowania po stronie serwera

W przeciwieństwie do starego podejścia, kiedy znaczniki były generowane na serwerze przy użyciu języków programowania (takich jak PHP) Server Side Rendering będzie teraz korzystać z nowoczesnych bibliotek JavaScript , takich jak React, podobnie jak w CSR.

Jedyną różnicą jest to, że aplikacja będzie generować znaczniki za pomocą React nie po stronie klienta, a po stronie serwera (Server Side Rendering). To rozwiązanie miało na celu naprawienie istniejących problemów z wydajnością i SEO. 

Za każdym razem, gdy robot indeksujący zażąda strony, otrzyma potrzebną zawartość — renderowanie nie wymaga już JavaScriptu do uruchomienia po stronie klienta.

Teraz, gdy wymieniany jest termin Server Side Rendering - odnosi się do tego scenariusza.

Zalety SSR:

  • SEO
    Zoptymalizowany pod kątem SEO: Next.js zapewnia potężne narzędzia do optymalizacji wyszukiwarek, które pozwalają lepiej indeksować strony interfejsu użytkownika.

  • FCP (First Contentful Paint)
    Dzięki renderowaniu po stronie serwera strony Twojej witryny stają się szybciej dostępne do interakcji. Dzięki wydajności SSR może dać ci doskonałą ocenę First Contentful Paint , która poprawia UX i prawdopodobnie także SEO strony.

  • Łatwość użytkowania
    Tworzenie strony internetowej za pomocą Next.js jest bardzo proste dzięki jego modelowi komponentów i routingu, które ułatwiają proces projektowania.

  • Pasuje do dużych projektów

    SSR został stworzony z myślą o potrzebach rozwijania dużych i skomplikowanych projektów. W ten sposób może być dobrze dopasowane do projektów o różnej skali, od małych witryn internetowych po duże systemy zarządzania treścią.

Wady SSR:

  • Czas przejścia między stronami zwalnia. Jasne, że dla początkowego renderowania SSR jest szybsze niż CSR, ale później przy pracy z aplikacją musisz dwukrotnie renderować dane, raz na serwerze i raz na kliencie.

  • Bardziej złożone narzędzie do tworzenia. Napisanie aplikacji tylko w React w połączeniu na przykład z Redux jest znacznie łatwiejsze niż dodanie do tego stosu technologii SSR. W związku z tym wzrasta ilość kodu, zwiększa się trudność rozwoju i pojawiają się dodatkowe biblioteki.

  • Koszt. Potrzebujemy serwera, który jest bardzo wydajny-zwykle kosztuje więcej.

SSG - Static Site Generator

SSG to nowe podejście do tworzenia stron internetowych, które umożliwia tworzenie witryn internetowych, których strony są generowane w plikach statycznych w czasie kompilacji. Tym samym, gdy przeglądarka wysyła żądanie, serwer nie generuje znaczników, jak w przypadku SSR , ale podaje je gotowe. Wygląda na to, że wróciliśmy do miejsca, w którym zaczynaliśmy - serwer ponownie udostępnia nam zwykły HTML i CSS , więc jaka jest różnica?

Różnica polega na tym, że zamiast używać HTML i CSS , używamy nowoczesnych narzędzi, takich jak React , Vue i Angular . Oznacza to, że aplikacja napisana w nowoczesnych narzędziach jest konwertowana do HTML , CSS i JavaScript za pomocą transpilatorów, konstruktorów pakietów itp.

Brzmi świetnie, ale jest haczyk. Problem w tym, że SSG nie oznacza dynamicznej pracy z serwerem, tj. nie możesz na przykład utworzyć koszyka zakupów online za pomocą SSG , ponieważ informacje wyświetlane w koszyku muszą być unikalne dla każdego użytkownika. W takim przypadku możemy zastosować jedynie SSR lub CSR . A statyczne generowanie strony jest wygodne np. dla strony „dostawa” lub dla karty produktu, czyli np. dla informacji, gdzie zawartość strony jest identyczna dla każdego użytkownika.

Zalety SSG:

  • SEO
    Podobnie jak w przypadku SSR , robot otrzymuje wszystkie niezbędne informacje.

  • Wydajność
    SSG ma najwyższą wydajność w porównaniu do SSR i CSR , ponieważ wszystkie dane są już generowane podczas montażu.

  • Bardzo tani
    Korzystając ze statycznego generowania witryn , nie potrzebujesz serwera, wystarczy przesłać kod witryny na github i zbudować go, na przykład za pomocą Netlify. W takim przypadku będziesz musiał zapłacić tylko za nazwę domeny.

  • Łatwość rozwoju
    W porównaniu do CSR, SSG jest nieco bardziej skomplikowane, ale ogólnie obraz niewiele różni się od zwykłego developmentu.

  • Bezpieczeństwo
    Twoja statyczna witryna nie ma serwera, co oznacza, że ​​atakujący nie ma możliwości uzyskania dostępu do Twojej bazy danych lub panelu administracyjnego.

Wady SSG:

  • SSG jest trudniejszy do uruchomienia niż Wordpress czy inny CMS. Podczas początkowej konfiguracji większość CMS zapewnia ogromną liczbę wskazówek dotyczących uruchamiania strony. W przypadku pracy z generatorem stron statycznych będziesz musiał przestudiować dokumentację.

  • Wyświetla tylko dane statyczne. Nie możesz wyświetlać dynamicznych danych za pomocą SSG , więc nie możesz zbudować dość złożonej aplikacji internetowej.

Na szczęście istnieje metoda zwana renderowaniem ogólnym, którą możemy wykorzystać, żeby uzyskać najlepsze rezultaty i funkcjonalności:

  • Szybkie i płynne przejścia między stronami, takie jak CSR

  • brak problemów z SEO

  • Niesamowicie szybki FCP (First Contentful Paint)

  • Praca z danymi dynamicznymi.

  • Zmniejszenie kosztów związanych z utrzymaniem serwera.

Wszystkie te funkcje są zapewniane przez platformę taką jak Next.js i  Nuxt.JS.

IRS - Incremental Static Regeneration (SSG + Regenerowanie danych)

Next.js umożliwia tworzenie lub aktualizowanie statycznych stron po zbudowaniu witryny.  Incremental Static Regeneration umożliwia korzystanie z regenerowania statycznego contentu na stronie, bez konieczności przebudowywania całej witryny. 

Dzięki ISR możesz zachować zalety statycznych stron i tylko regenerować content jaki był edytowany.

Podsumowanie

SSR pozwala na generowanie strony po stronie serwera, co oznacza, że użytkownik otrzymuje gotową do wyświetlenia stronę, a nie musi czekać na pobieranie i przetwarzanie danych po stronie klienta.

Z kolei SSG pozwala na generowanie stron statycznych, co oznacza, że strona jest gotowa do przeglądania przez użytkownika bez potrzeby pobierania i przetwarzania danych przez serwer. To również przyspiesza ładowanie strony i poprawia doświadczenie użytkownika. 

W związku z tym, wybór między CSR, SSR i SSG - to jest ważną decyzją dla biznesu, ponieważ wpływają na wydajność, doświadczenie użytkownika i pozycjonowanie strony w wyszukiwarkach, co ma bezpośredni wpływ na sukces biznesowy prowadzonej działalności online.