Co wybrać? Renderowanie po stronie serwera a renderowanie po stronie klienta

W tym artykule omówimy różnice, wady oraz zalety poszczególnych rozwiązań. Jednak zanim to nastąpi, pokrótce przypomnimy sobie, jak działają strony internetowe oraz jak to się dzieje, że niezależnie od tego z jakiego urządzenia korzystamy do surfowania po sieci, wystarczy nam tylko łącze internetowe oraz dowolne urządzenie z przeglądarką.

Początki HTML-a

Na początku lat 80-tych, kiedy Internet jeszcze raczkował (w formie ARPANET-u) i na długo przed pojawieniem się pierwszych stron WWW, naukowcy pracowali nad stworzeniem systemu, który miał umożliwiać zdalne przeglądanie dokumentów umieszczonych na innym komputerze. System ten musiał być niezawodny i działać na każdym komputerze, niezależnie od systemu operacyjnego i specyfikacji. Okazało się, że najprostsze rozwiązania są najlepsze, i przesyłanie danych za pomocą tekstu zawierającego odpowiednie znaczniki, takie jak header, footer czy strong, będzie najlepszym rozwiązaniem. Tak właśnie powstał HTML, który do dziś jest wykorzystywany w naszych przeglądarkach do wyświetlania stron internetowych.

Co to jest renderowanie po stronie serwera?

Skoro już wiemy co to jest HTML, należy odpowiedzieć sobie na pytanie skąd on się bierze. Jak to jest, że odwiedzając daną stronę internetową, serwer zwraca nam taki a nie inny kod?

W chwili, gdy serwer otrzymuje żądanie od naszej przeglądarki, musi przetworzyć całą masę informacji, między innymi sprawdzić, czy wraz z żądaniem przesłaliśmy jakieś pliki cookie. Jeśli tak, serwer weryfikuje:

• jakie to są pliki,
• czy zawierają informacje o tym, że jesteśmy zalogowanymi użytkownikami,
• czy posiadają informacje o tym, że już kiedyś w przeszłości odwiedziliśmy daną stronę i zapamiętaliśmy na niej jakieś ustawienia.

Następnie serwer zbiera informacje z innych źródeł (np. z bazy danych) o tym, co ma zostać wyświetlone użytkownikowi. W przypadku bloga będą to między innymi treści najnowszych lub polecanych artykułów.

Mając już wszystkie potrzebne informacje, serwer w odpowiedzi wysyła nam kod HTML, który nasza przeglądarka przetwarza z formy tekstowej w formę graficzną.

Źródło: Duomly

Kiedy klikniemy w link, aby otworzyć kolejny artykuł na blogu, wysyłamy kolejne żądanie do serwera i cały proces rozpoczyna się od nowa.

Zalety i wady

Opisany wyżej standard generowania kodu HTML obowiązuje niemalże od 1991 roku, czyli od chwili, kiedy została zaprezentowana światu pierwsza strona WWW. Jest to co prawda stare, ale jednocześnie sprawdzone rozwiązanie. Wybierając renderowanie po stronie serwera, mamy niemal pewność, że nasza strona internetowa zawsze i wszędzie, niezależnie od systemu operacyjnego czy przeglądarki, zostanie wyświetlona prawidłowo.

Jednak uważni czytelnicy już teraz mogli dostrzec jedną bardzo poważną wadę tego rozwiązania. Wróćmy jeszcze raz do przykładu strony z artykułami. Po przeczytaniu wpisu zainteresował nas kolejny tekst, który pojawił się w sekcji Polecane dla Ciebie. Klikamy zatem w link i co się dzieje? Wysyłamy do serwera żądanie o wygenerowanie kodu HTML całej strony, wraz z treścią nowego artykułu. A przecież tak naprawdę potrzebowaliśmy tylko treść nowego artykułu! Reszta kodu HTML została niepotrzebne wygenerowana na nowo. Prowadzi to do zbędnego obciążania serwera, co w przypadku dużego ruchu na stronie może prowadzić do problemów z wydajnością.

Kiedy należy wybrać renderowanie po stronie serwera?

Warto wybrać takie rozwiązanie, kiedy chcemy mieć pewność, że nasza strona zostanie prawidłowo wyświetlona, niezależnie od tego, kto będzie ją przeglądał. Pamiętajmy, że obecnie nie tylko ludzie z krwi i kości przeglądają sieć Internet. Codziennie strony odwiedzane są przez boty Google, które mają za zadanie ustalić, czy treść na nich zawarta jest wartościowa i jak wysoko w wynikach wyszukiwania należy ją umieścić. Jeszcze do niedawna roboty te zupełnie nie radziły sobie ze stronami, które były renderowane po stronie klienta (o czym opowiemy w dalszej części tekstu), a boty Facebooka do tej pory tego nie potrafią.

Co to jest renderowanie po stronie klienta?

W tym przypadku serwer obsługując żądanie wykonuje tylko minimum niezbędnej pracy i w odpowiedzi zamiast kodu HTML, zwraca nam kod JavaScript. Co ważne kod JS nie jest generowany “w locie” przez serwer. Jest to statyczny plik, który został tam wcześniej zapisany.

Zwrócony kod zawiera informacje o tym, jaki kod HTML powinien zostać wygenerowany. Tym razem to nasza przeglądarka lokalnie generuje ten kod i wyświetla nam stronę internetową w formie graficznej.

Źródło: Duomly

Zalety i wady

Jak zapewne możecie się domyślić, pierwszą z zalet jest zmniejszenie obciążenia serwera. Nie musi on już za każdym razem generować całego kodu HTML. Tę pracę wykonuje teraz nasza przeglądarka. Dzięki temu serwer może obsłużyć więcej żądań w tym samym czasie. To pozwala również zredukować koszty związane z infrastrukturą.

Ze względu na to, że wszystkie informacje odnośnie tego, jak powinien zostać wygenerowany kod HTML znajdują się w naszej przeglądarce, przejście do nowej podstrony nie powoduje jej ponownego załadowania. Kod HTML podmieniany jest lokalnie przez naszą przeglądarkę, dzięki czemu użytkownik ma wrażenie, że strona działa dużo szybciej i w działaniu bardziej przypomina aplikację desktopową lub mobilną niż tradycyjny serwis WWW.

Kod JavaScript, który otrzymuje nasza przeglądarka w przypadku renderowania po stronie klienta, jest bardzo zbliżony do kodu w aplikacjach mobilnych czy desktopowych. Dzięki temu w większości przypadków w bardzo prosty sposób oraz niskim kosztem możemy rozszerzyć działanie naszej strony. Stanie się ona jednocześnie serwisem WWW oraz aplikacją mobilną (PWA).

Niestety to rozwiązanie nie jest pozbawione wad. Z racji tego, że w odpowiedzi od serwera otrzymujemy kod JavaScript, musimy mieć włączoną obsługę tego kodu w przeglądarce. Bez tego nie zobaczymy żadnej treści. Co prawda obecnie każda nowsza i starsza przeglądarka obsługuje taki kod, jednak - jak już wspomnieliśmy wcześniej - nie tylko ludzie przeglądają Internet. W przypadku botów obsługa takiego kodu nadal stanowi problem. Jeśli zależy nam na tym, aby strona wyświetlana była możliwie jak najwyżej w wynikach wyszukiwania, a udostępniane linki do naszego serwisu prezentowały się w nowoczesny sposób (wraz z grafiką, tytułem oraz opisem strony), renderowanie po stronie klienta może nie być najlepszym rozwiązaniem.

W jakich przypadkach lepiej wybrać renderowanie po stronie klienta?

Renderowanie po stronie klienta znakomicie sprawdzi się w przypadku reaktywnych stron internetowych, na których użytkownik może wykonać wiele akcji. Dobrym przykładem takiej strony może być Google Calendar lub Gmail. To rozwiązanie dobrze sprawdzi się również, jeśli zależy nam na użytkownikach korzystających z urządzeń mobilnych, którzy będą mieli możliwość zainstalowania strony na smartfonie w formie aplikacji.

Renderowanie po stronie klienta i serwera

Oba przedstawione tutaj rozwiązania mają swoje zalety oraz wady. Nie oznacza to jednak, że wybierając jedno, rezygnujemy z zalet drugiego. Możliwe jest połączenie obu tych metod.

Podczas pierwszego wejścia na stronę internetową, kod HTML jest generowany po stronie serwera w tradycyjny sposób i w takiej formie jest zwracany do klienta. Jednak razem z tym kodem wysyłany jest również JavaScript. Dalsze interakcje na stronie odbywają się za pomocą przesłanego kodu JS, tak jak w przypadku renderowania po stronie klienta.

Dzięki temu jesteśmy w stanie połączyć zalety oraz zniwelować wady obu wyżej przedstawionych rozwiązań. Czy w takim razie jest to idealna opcja? Niestety nie. Hybrydowe rozwiązanie, o którym tutaj mowa, jest znacznie trudniejsze w realizacji, a co za tym idzie, wymaga bardziej wykwalifikowanych pracowników oraz pochłania więcej czasu. To natomiast przekłada się na wyższe koszty wdrożenia.

Renderowanie po stronie serwera a po stronie klienta - podsumowanie

Renderowanie po stronie klienta pozwala nam tworzyć nowoczesne serwisy internetowe, które swoim działaniem bardziej przypominają aplikacje niż tradycyjne strony WWW. Niestety negatywnie odbija się to na wynikach wyszukiwania. Rozwiązanie pośrednie również nie jest pozbawione wad. Dlatego, jeśli planujesz wdrożenie któregoś z tych rozwiązań na swojej stronie, najlepiej skonsultuj się ze specjalistami budującymi serwisy internetowe. Po dokładnej analizie Twoich potrzeb oraz specyfikacji będą oni w stanie dobrać najlepsze dla Ciebie rozwiązanie.