Renderowanie po stronie serwera za pomocą React

Opublikowany: 2021-05-27

Trochę o React

React to frontendowa biblioteka JavaScript o otwartym kodzie źródłowym, tworzona i utrzymywana przez społeczność programistów Facebooka. Służy do budowania interfejsów użytkownika lub komponentów interfejsu użytkownika.

Jednak ta definicja może nie być w pełni zrozumiała dla nowicjuszy. Mamy idealny post na blogu, który przeprowadzi Cię przez krótkie wyjaśnienie Reacta, aż do bardzo szczegółowego opisu technicznego, który możesz znaleźć tutaj.

Podróż strony internetowej | Z serwera do przeglądarki

Aby zrozumieć, czym jest renderowanie po stronie serwera, najpierw należy zapoznać się z tym, jak strona internetowa wygląda na ekranie, co wyjaśnia poniższy diagram:

ssr-z-react-strona-serwer-do-przegladarki
  1. Za każdym razem, gdy wpisujesz adres URL witryny lub klikasz link do witryny, Twoja przeglądarka wysyła żądanie niektórych plików do odpowiedniego serwera, identyfikowanego przez adres URL.
  2. Serwer wysyła niektóre pliki, takie jak między innymi pliki HTML i JavaScript, do Twojej przeglądarki.
  3. Twoja przeglądarka pobiera i „renderuje” lub przetwarza te pliki, a Ty możesz przeglądać i wchodzić w interakcję z żądaną stroną internetową.

Jest to bardzo duże uproszczenie podróży po stronie internetowej, ale jest wystarczająco dobrym wstępem do wyjaśnienia różnych podetapów i różnych sposobów (w tym renderowania po stronie serwera) do wykonania tego zadania.

Podróż po „normalnej” stronie renderującej po stronie klienta

Zagłębiając się głębiej w proces, o którym mowa w poprzedniej sekcji, mamy do czynienia z stosowaną od dawna techniką zwaną Client Side Rendering lub CSR, wyświetlającą stronę internetową na ekranach użytkowników. Wyjaśniono to na poniższym schemacie:

ssr-z-react-csr-rendering-strony-w-internecie
  1. Po wpisaniu adresu URL strony internetowej lub kliknięciu odnośnika do strony, Twoja przeglądarka wysyła żądanie niektórych plików do odpowiedniego serwera, identyfikowanego przez adres URL.
  2. Serwer przesyła plik HTML, który zawiera odniesienia do innych zasobów, takich jak pliki obrazów, pliki CSS i pliki JavaScript.
  3. Przeglądarka ponownie wysyła żądanie do serwera i pobiera wszystkie pliki, w tym pliki CSS i JavaScript, do których odwołuje się plik HTML.
    1. Może to przyczynić się do wydłużenia czasu ładowania witryny, jeśli użytkownicy mają słabe połączenie, a plik JavaScript ma duży rozmiar.
  4. Po pobraniu tych plików przez przeglądarkę, przeglądarka uruchamia framework lub bibliotekę (na przykład React) i analizuje pliki JavaScript, które są odpowiedzialne za interaktywność strony internetowej.
    1. Z punktu widzenia optymalizacji szybkości ten punkt jest zależny od komputera klienckiego i jeśli klient jest sprzętem o niskim poborze mocy, może to zająć dużo czasu.
    2. Podczas wykonywania tych czynności użytkownik nadal widzi ekran ładowania
  5. Strona internetowa jest w końcu całkowicie załadowana, a użytkownik może zobaczyć i wchodzić w interakcję ze stroną internetową.

Jak wynika z powyższych kroków, z punktu widzenia użytkownika, może on zobaczyć i wchodzić w interakcję ze stroną internetową tylko na ostatnim etapie, po pobraniu i wyrenderowaniu wszystkich niezbędnych plików przez maszynę kliencką.

Może to zająć dużo czasu, ponieważ zależy od wydajności komputera klienckiego podczas wykonywania frameworka i analizowania plików JavaScript.

Droga do renderowania strony internetowej po stronie serwera

Wyjaśniając to w jednym wierszu, renderowanie po stronie serwera lub SSR to proces polegający na przejściu strony internetowej frameworku JavaScript po stronie klienta i renderowaniu jej do statycznego kodu HTML i CSS na serwerze zamiast na kliencie, jak miało to miejsce w przypadku CSR.

Poniżej znajduje się obrazkowa reprezentacja podróży, jaką odbywa się strona internetowa dzięki renderowaniu po stronie serwera z React:

ssr-z-reakcją-ssr-strona-renderowanie-z-reakcją
  1. Po wpisaniu adresu URL strony internetowej lub kliknięciu odnośnika do strony, Twoja przeglądarka wysyła żądanie niektórych plików do odpowiedniego serwera, identyfikowanego przez adres URL.
  2. Serwer, zamiast po prostu wysyłać waniliowe pliki HTML, takie jak w CSR, renderuje aplikację w ciąg znaków za pomocą funkcji renderToString zaimportowanej z reakcji-dom/serwera
    1. Jest on następnie wstrzykiwany do pliku index.html i wysyłany do przeglądarki.
    2. To tutaj leży sedno SSR, mówiąc funkcjonalnie, ponieważ to tam renderuje stronę serwer, a nie komputer klienta.
  3. Przeglądarka renderuje ten plik HTML, co powoduje wypełnienie widoku w przeglądarce.
    1. Nie jest to jednak jeszcze interaktywne, ale użytkownik może zobaczyć końcowy widok strony internetowej.
  4. Przeglądarka ponownie wysyła żądanie do serwera i pobiera wszystkie pliki, do których odwołuje się plik HTML, w tym pliki JavaScript.
  5. Po pobraniu wszystkich skryptów komponent React jest ponownie renderowany na kliencie. Tym razem jednak uwadnia istniejący pogląd, zamiast go zastępować.
    1. „Uwodnienie” widoku oznacza, że ​​dołącza on wszystkie programy obsługi zdarzeń do renderowanych elementów DOM (Document Object Model), ale zachowuje renderowane elementy DOM w stanie nienaruszonym. W ten sposób zachowany jest stan elementów DOM i nie następuje resetowanie widoku.
  6. Strona internetowa jest w końcu całkowicie załadowana, a użytkownik może teraz wchodzić w interakcję ze stroną, którą był w stanie zobaczyć z samego kroku 3.

Tak więc jedną z największych zmian wizualnych z punktu widzenia użytkownika jest to, że strona internetowa staje się „widoczna” dość szybko, ponieważ renderowanie HTML nie wymaga dużych zasobów, mówiąc z perspektywy przeglądarki.

To z natury nie sprawia, że ​​strona ładuje się szybciej niż aplikacja bez SSR, ale daje użytkownikom widok strony internetowej, gdy pliki JavaScript pobierają i analizują w tle, po czym strona internetowa staje się interaktywna. Oznacza to, że TTI, czyli Time To Interactive (jest to czas, w którym strona internetowa jest całkowicie interaktywna od momentu, gdy użytkownik zażąda strony internetowej) jest nieco większy niż czas potrzebny na wyświetlenie strony internetowej w przeglądarce.

Tak więc w scenariuszu SSR, aby przyspieszyć pierwsze renderowanie, kod HTML i CSS musi być zrozumiały dla użytkowników, a JavaScript może być ulepszeniem HTML i CSS, ponieważ jego ładowanie jest odroczone.

Powszechnym błędnym przekonaniem na temat działania SSR w React jest to, że po każdej zmianie, takiej jak żądanie użytkownika o nowe dane, serwer ponownie wykonuje wszystkie kroki i wysyła plik HTML z nowym interfejsem użytkownika do przeglądarki, ale tak nie jest . Przeprowadzana jest tylko częściowa aktualizacja strony. Chociaż renderowanie jest wykonywane przez serwer, sfinalizowane dane wyjściowe są wstawiane do DOM przez „uwodnienie” go, jak wyjaśniono wcześniej.

ssr-z-react-plusy-przeciw-ssr

Renderowanie po stronie serwera | Kiedy i kiedy nie używać

  • Jeśli potrzebujesz silnego SEO, wybierz SSR, ponieważ wyszukiwarkom łatwiej jest się indeksować.
  • W przypadku witryn zorientowanych na treść, a nie na interakcję, takich jak blogi, witryny z wiadomościami, witryny statyczne i witryny z dużą ilością tekstu, SSR może być dobrodziejstwem, ponieważ załaduje sedno Twojej witryny, tj. Szybko załaduje treść.
  • Renderowanie i generowanie plików do przesłania do przeglądarki wymaga czasu i wysiłku po stronie serwera. Więc jeśli masz niski budżet serwera i operacji, lepiej nie wdrażać SSR, ponieważ na serwer będzie wysyłanych wiele żądań.
    • Jednak dzięki dostawcom takim jak Firebase możemy dynamicznie generować treści z funkcjami chmury, a serwer może je przechowywać w pamięci podręcznej CDN
    • Dzięki temu następnym razem, gdy użytkownik zażąda, generowanie plików nie zostanie ponownie wykonane przez serwer. Jest raczej obsługiwany z lokalnego brzegu CDN, co poprawia czasy ładowania z punktu widzenia użytkownika, jednocześnie zużywając mniej zasobów serwera.

Jak React jest dobry dla SSR?

React to doskonały wybór do wdrożenia SSR, ponieważ zawiera koncepcję wirtualnego DOM (Document Object Model).

Dzięki temu programiści mogą tworzyć wirtualną wersję aplikacji React i mieć ją na samym serwerze.

Ułatwia to renderowanie go do kodu HTML za pomocą funkcji renderToString, jak omówiono wcześniej, wyślij to do przeglądarki, aby przeglądarka mogła renderować go dość szybko i utworzyć wersję wirtualną na komputerze klienckim.

Tak więc, biorąc pod uwagę fakt, że ta wirtualna wersja pasuje do HTML, który wysłaliśmy z serwera, React nie wyrenderuje jej ponownie, zmniejszając w ten sposób Time To Interactive (TTI), co skutkuje "szybszym" ładowaniem strony internetowej.

SSR, cały dzień, codziennie!

Szkoda, że ​​nie ma jednego uniwersalnego rozwiązania na wszystko, ale jest to dalekie od przypadku, zwłaszcza w przypadku nowych technologii. Chociaż SSR ma wiele zalet, istnieją pewne przypadki, o których wspomniano wcześniej, dla których SSR może nie być dobrym wyborem; wysoce interaktywne witryny będące w jej awangardzie.

Tu właśnie wkracza Creole Studios. Mamy szereg ekspertów technologicznych, zawsze na bieżąco z prawie każdą nową technologią, która pojawia się w technologicznym świecie. Zrozumiemy Twoje potrzeby biznesowe i dostarczymy Ci dostosowane rozwiązania, niezależnie od tego, czy będzie to aplikacja SSR, czy CSR, i zapewnimy, że nie będziesz się o nic martwić, gdy wykonamy dla Ciebie ciężkie prace. Skontaktuj się z nami i przenieś swoje pomysły z głowy do aplikacji!