Po stronie klienta a po stronie serwera a wstępne renderowanie dla aplikacji internetowych

Coś się ostatnio dzieje w społeczności front-endowej. Renderowanie po stronie serwera zyskuje coraz większą atrakcyjność dzięki React i wbudowanej funkcji nawadniania po stronie serwera. Ale to nie jedyne rozwiązanie, które zapewnia użytkownikom szybkie wrażenia dzięki superszybkiemu wynikowi czasu do pierwszego bajtu (TTFB): Wstępne renderowanie to również całkiem dobra strategia. Jaka jest różnica między tymi rozwiązaniami a aplikacją w pełni renderowaną przez klienta?

Aplikacja renderowana przez klienta

Ponieważ istnieją frameworki, takie jak Angular, Ember.js i Backbone, programiści front-end zwykle renderują wszystko po stronie klienta. Dzięki Google i jego zdolności do „czytania” JavaScript działa całkiem nieźle, a nawet jest przyjazny dla SEO.

Dzięki rozwiązaniu do renderowania po stronie klienta przekierowujesz żądanie do pojedynczego pliku HTML, a serwer dostarczy je bez żadnej treści (lub z ekranem ładowania), dopóki nie pobierzesz całego kodu JavaScript i pozwolisz przeglądarce skompilować wszystko przed renderowaniem treści.

Przy dobrym i niezawodnym połączeniu internetowym jest dość szybki i działa dobrze. Ale może być o wiele lepiej i nie musi być trudno zrobić to w ten sposób. To właśnie zobaczymy w kolejnych sekcjach.

Renderowanie po stronie serwera (SSR)

Rozwiązanie SSR to coś, co robiliśmy wiele lat temu, ale zapominamy na rzecz rozwiązania renderującego po stronie klienta.

Dzięki starym rozwiązaniom do renderowania po stronie serwera zbudowałeś stronę internetową — na przykład za pomocą PHP — serwer skompilował wszystko, dołączył dane i dostarczył klientowi w pełni wypełnioną stronę HTML. To było szybkie i skuteczne.

Ale… za każdym razem, gdy przechodziłeś do innej trasy, serwer musiał wykonać całą pracę od nowa: pobrać plik PHP, skompilować go i dostarczyć HTML, z całym CSS i JS opóźniającym ładowanie strony do kilkuset ms lub nawet całe sekundy.

Co by było, gdybyś mógł wykonać pierwsze ładowanie strony za pomocą rozwiązania SSR, a następnie użyć frameworka do dynamicznego routingu za pomocą AJAX, pobierając tylko niezbędne dane?

Właśnie dlatego SSR zyskuje coraz większą popularność w społeczności, ponieważ React spopularyzował ten problem za pomocą łatwego w użyciu rozwiązania: metody RenderToString .

Ten nowy rodzaj aplikacji internetowej nazywa się aplikacją uniwersalną lub aplikacją izomorficzną . Nadal istnieją pewne kontrowersje dotyczące dokładnego znaczenia tych terminów i relacji między nimi, ale wiele osób używa ich zamiennie.

W każdym razie zaletą tego rozwiązania jest możliwość tworzenia aplikacji po stronie serwera i klienta za pomocą tego samego kodu i zapewnienia użytkownikowi naprawdę szybkiego doświadczenia z niestandardowymi danymi. Wadą jest to, że musisz uruchomić serwer.

SSR służy do pobierania danych i wstępnego wypełniania strony niestandardową treścią, wykorzystując niezawodne połączenie internetowe serwera. Oznacza to, że własne połączenie internetowe serwera jest lepsze niż połączenie użytkownika z lie-fi), więc jest w stanie wstępnie pobrać i połączyć dane przed dostarczeniem ich użytkownikowi.

Dzięki wstępnie wypełnionym danym korzystanie z aplikacji SSR może również rozwiązać problem, który aplikacje renderowane przez klienta mają z udostępnianiem społecznościowym i systemem OpenGraph. Na przykład, jeśli masz tylko jeden plik index.html do dostarczenia klientowi, będzie on miał tylko jeden typ metadanych — najprawdopodobniej metadane Twojej strony głównej. Nie będzie to kontekstowe, gdy chcesz udostępnić inną trasę, więc żadna z Twoich tras nie będzie wyświetlana w innych witrynach z odpowiednią zawartością użytkownika (opis i obraz podglądu), którą użytkownicy chcieliby udostępnić światu.

Wstępne renderowanie

Obowiązkowy serwer dla uniwersalnej aplikacji może być dla niektórych odstraszający i może być przesadą w przypadku małej aplikacji. Dlatego wstępne renderowanie może być naprawdę dobrą alternatywą.

Odkryłem to rozwiązanie dzięki Preact i jego własnemu CLI, które pozwala kompilować wszystkie wstępnie wybrane trasy, dzięki czemu można przechowywać w pełni wypełniony plik HTML na statycznym serwerze. Pozwala to zapewnić użytkownikowi superszybkie wrażenia dzięki funkcji nawadniania Preact/React, bez potrzeby korzystania z Node.js.

Haczyk polega na tym, że ponieważ to nie jest SSR, nie masz w tym momencie danych specyficznych dla użytkownika do wyświetlenia — jest to po prostu statyczny (i nieco ogólny) plik wysyłany bezpośrednio przy pierwszym żądaniu, tak jak jest. Więc jeśli masz dane specyficzne dla użytkownika, tutaj możesz zintegrować pięknie zaprojektowany szkielet, aby pokazać użytkownikowi, że nadchodzą jego dane, aby uniknąć frustracji z jego strony:

Jest jeszcze jeden haczyk: aby ta technika zadziałała, nadal potrzebujesz serwera proxy lub czegoś, co przekieruje użytkownika do właściwego pliku.

Czemu?

W przypadku aplikacji jednostronicowej należy przekierować wszystkie żądania do pliku głównego, a następnie struktura przekierowuje użytkownika za pomocą wbudowanego systemu routingu. Tak więc pierwsze ładowanie strony to zawsze ten sam plik główny.

Aby rozwiązanie do wstępnego renderowania działało, musisz poinformować serwer proxy, że niektóre trasy wymagają określonych plików, a nie zawsze głównego pliku index.html .

Załóżmy na przykład, że masz cztery trasy ( / , /about , /jobs i blog ) i każda z nich ma inny układ. Potrzebujesz czterech różnych plików HTML, aby dostarczyć szkielet użytkownikowi, który następnie pozwoli React/Preact/etc. nawilż go danymi. Jeśli więc przekierujesz wszystkie te trasy do głównego pliku index.html , strona będzie miała nieprzyjemny, głuchy charakter podczas ładowania, przez co użytkownik będzie widział szkielet niewłaściwej strony, dopóki nie zakończy wczytywania i zastąpi układ. Na przykład użytkownik może zobaczyć szkielet strony głównej z tylko jedną kolumną, gdy poprosił o inną stronę z galerią podobną do Pinteresta.

Rozwiązaniem jest poinformowanie serwera proxy, że każda z tych czterech tras wymaga określonego pliku:

• https://my-website.com → Przekieruj do głównego pliku index.html
• https://my-website.com/about → Przekieruj do pliku /about/index.html
• https://my-website.com/jobs → Przekieruj do pliku /jobs/index.html
• https://my-website.com/blog → Przekieruj do pliku /blog/index.html

Dlatego to rozwiązanie może się przydać w małych aplikacjach – widać, jak bolesne byłoby, gdybyś miał kilkaset stron.

Ściśle mówiąc, nie jest to obowiązkowe — możesz po prostu użyć bezpośrednio pliku statycznego. Na przykład https://my-website.com/about/ będzie działać bez żadnego przekierowania, ponieważ automatycznie wyszuka index.html w swoim katalogu. Ale potrzebujesz tego serwera proxy, jeśli masz adresy URL parametrów — https://my-website.com/profile/guillaume będzie musiał przekierować żądanie do /profile/index.html z własnym układem, ponieważ profile/guillaume/index.html nie istnieje i wywoła błąd 404.

Krótko mówiąc, w opisanych powyżej strategiach renderowania działają trzy podstawowe widoki: ekran ładowania, szkielet i cała strona po ostatecznym wyrenderowaniu.

W zależności od strategii czasami korzystamy ze wszystkich trzech widoków, a czasami przeskakujemy od razu do w pełni wyrenderowanej strony. Tylko w jednym przypadku użycia jesteśmy zmuszeni zastosować inne podejście:

Renderowanie tylko dla klienta często nie wystarcza

Aplikacje renderowane przez klienta to coś, czego powinniśmy teraz unikać, ponieważ możemy zrobić to lepiej dla użytkownika. W tym przypadku lepsze działanie jest tak proste, jak rozwiązanie do wstępnego renderowania. Jest to zdecydowanie ulepszenie w stosunku do renderowania tylko dla klienta i łatwiejsze do wdrożenia niż aplikacja w pełni renderowana po stronie serwera.

Aplikacja SSR/uniwersalna może być naprawdę potężna, jeśli masz dużą aplikację z wieloma różnymi stronami. Dzięki temu Twoje treści są skoncentrowane i trafne podczas rozmowy z robotem społecznościowym. Odnosi się to również do robotów wyszukiwarek, które teraz biorą pod uwagę wydajność Twojej witryny podczas jej rankingowania.

Czekajcie na kolejny samouczek, w którym przejdę przez transformację SPA do wersji prerenderowanych i SSR oraz porównam ich działanie.