Reaguj na strategie SEO i najlepsze praktyki

React został opracowany w celu tworzenia interaktywnych interfejsów użytkownika, które są deklaratywne , modułowe i wieloplatformowe . Obecnie jest to jeden z bardziej popularnych — jeśli nie najpopularniejszych — frameworków JavaScript do pisania wydajnych aplikacji typu front-end. Opracowany początkowo do pisania aplikacji jednostronicowych (SPA), React jest teraz używany do tworzenia pełnoprawnych stron internetowych i aplikacji mobilnych.

Jeśli masz duże doświadczenie w konwencjonalnym tworzeniu stron internetowych i przejdziesz do Reacta, zauważysz, że coraz więcej kodu HTML i CSS przechodzi do JavaScript. Dzieje się tak, ponieważ React nie zaleca bezpośredniego tworzenia ani aktualizowania elementów interfejsu użytkownika, ale zamiast tego opisuje „stan” interfejsu użytkownika. React następnie zaktualizuje DOM, aby dopasować go do stanu w najbardziej efektywny sposób.

W rezultacie wszystkie zmiany w interfejsie użytkownika lub DOM muszą być dokonywane za pomocą silnika Reacta. Chociaż jest to wygodne dla programistów, może to oznaczać dłuższy czas ładowania dla użytkowników i więcej pracy dla wyszukiwarek w celu znalezienia i zindeksowania treści.

W tym artykule zajmiemy się wyzwaniami, przed jakimi stajesz podczas tworzenia skutecznych w SEO aplikacji i stron internetowych React, a także przedstawimy kilka strategii wykorzystywanych do ich pokonania.

Jak Google indeksuje i indeksuje strony internetowe

Google otrzymuje ponad 90% wszystkich wyszukiwań online. Przyjrzyjmy się bliżej procesowi pobierania i indeksowania.

Ta migawka zaczerpnięta z dokumentacji Google może nam pomóc. Proszę zauważyć, że jest to uproszczony schemat blokowy. Rzeczywisty Googlebot jest znacznie bardziej wyrafinowany.

Punkty do odnotowania:

1. Googlebot utrzymuje kolejkę indeksowania zawierającą wszystkie adresy URL potrzebne do przeszukiwania i indeksowania w przyszłości.
2. Gdy robot jest bezczynny, pobiera następny URL z kolejki, wysyła żądanie i pobiera kod HTML.
3. Po przeanalizowaniu kodu HTML Googlebot określa, czy musi pobrać i wykonać JavaScript w celu renderowania treści. Jeśli tak, adres URL zostanie dodany do kolejki renderowania.
4. W późniejszym momencie moduł renderujący pobiera i wykonuje kod JavaScript w celu renderowania strony. Wysyła wyrenderowany kod HTML z powrotem do jednostki przetwarzającej.
5. Jednostka przetwarzania wyodrębnia wszystkie <a> tags wymienione na stronie internetowej i dodaje je z powrotem do kolejki indeksowania.
6. Treść zostanie dodana do indeksu Google.

Zauważ, że istnieje wyraźne rozróżnienie między etapem przetwarzania , który analizuje kod HTML, a etapem renderowania , który wykonuje JavaScript.

To rozróżnienie istnieje, ponieważ wykonywanie JavaScriptu jest drogie , biorąc pod uwagę, że Googleboty muszą przeglądać ponad 130 bilionów stron internetowych. Dlatego gdy Googlebot indeksuje stronę internetową, natychmiast analizuje kod HTML, a następnie umieszcza kod JavaScript w kolejce , aby uruchomić go później. Dokumentacja Google wspomina, że ​​strona pozostaje w kolejce renderowania przez kilka sekund, chociaż może to trwać dłużej.

Warto również wspomnieć o koncepcji crawl budget. Indeksowanie przez Google jest ograniczone przepustowością, czasem i dostępnością instancji Googlebota. Przydziela określony budżet lub zasoby na indeksowanie każdej witryny. Jeśli budujesz dużą witrynę internetową z tysiącami stron (np. witrynę handlu elektronicznego) i strony te wykorzystują dużo kodu JavaScript do renderowania treści, Google może być w stanie odczytać mniej treści z Twojej witryny.

Uwaga: tutaj możesz przeczytać wytyczne Google dotyczące zarządzania budżetem indeksowania.

Dlaczego optymalizacja React pod kątem SEO jest wyzwaniem

Nasz krótki opis Googlebota, przeszukiwania i indeksowania tylko zarysowuje powierzchnię. Jednak inżynierowie oprogramowania powinni identyfikować potencjalne problemy, z jakimi borykają się wyszukiwarki próbujące przeszukiwać i indeksować strony React. Teraz możemy przyjrzeć się bliżej, co sprawia, że ​​React SEO stanowi wyzwanie i co programiści mogą zrobić, aby rozwiązać niektóre z tych wyzwań.

Opróżnij zawartość pierwszego przejścia

Wiemy, że aplikacje React w dużym stopniu opierają się na JavaScript i często napotykają problemy z wyszukiwarkami. Dzieje się tak, ponieważ React domyślnie wykorzystuje model powłoki aplikacji. Początkowy kod HTML nie zawiera żadnej znaczącej treści, a użytkownik lub bot musi wykonać JavaScript, aby zobaczyć rzeczywistą zawartość strony.

Takie podejście oznacza, że ​​Googlebot wykrywa pustą stronę podczas pierwszego przebiegu. Treść jest widoczna dla Google tylko wtedy, gdy strona jest renderowana. Opóźni to indeksowanie treści w przypadku tysięcy stron.

Czas ładowania i wrażenia użytkownika

Pobieranie, analizowanie i wykonywanie JavaScriptu wymaga czasu. Ponadto JavaScript może wymagać wykonania połączeń sieciowych w celu pobrania treści, a użytkownik może potrzebować trochę czasu, zanim będzie mógł wyświetlić żądane informacje.

Google określił zestaw wskaźników internetowych związanych z doświadczeniem użytkownika, wykorzystywanych w kryteriach rankingu. Dłuższy czas wczytywania może wpłynąć na ocenę komfortu użytkownika, skłaniając Google do obniżenia rankingu witryny.

W następnej sekcji szczegółowo sprawdzamy wydajność witryny.

Metadane strony

Metatagi <meta> są przydatne, ponieważ umożliwiają Google i innym serwisom społecznościowym wyświetlanie odpowiednich tytułów, miniatur i opisów stron. Jednak te witryny polegają na tagu <head> pobranej strony internetowej, aby uzyskać te informacje. Te strony internetowe nie wykonują JavaScript dla strony docelowej.

React renderuje całą zawartość, w tym metatagi, na kliencie. Ponieważ powłoka aplikacji jest taka sama dla całej witryny/aplikacji, dostosowanie metadanych dla poszczególnych stron może być trudne.

Mapa strony

Mapa witryny to plik, w którym podajesz informacje o stronach, filmach i innych plikach w Twojej witrynie oraz relacjach między nimi. Wyszukiwarki takie jak Google czytają ten plik, aby inteligentniej indeksować Twoją witrynę.

React nie ma wbudowanego sposobu generowania map witryn. Jeśli używasz czegoś takiego jak React Router do obsługi routingu, możesz znaleźć narzędzia, które mogą wygenerować mapę witryny, chociaż może to wymagać trochę wysiłku.

Inne kwestie dotyczące SEO

Rozważania te są związane z ogólnym ustaleniem dobrych praktyk SEO.

1. Miej optymalną strukturę adresów URL, aby dać ludziom i wyszukiwarkom dobre wyobrażenie o tym, czego mogą się spodziewać na stronie.
2. Optymalizacja pliku robots.txt może pomóc botom wyszukiwania zrozumieć, jak indeksować strony w Twojej witrynie.
3. Użyj sieci CDN do obsługi wszystkich zasobów statycznych, takich jak CSS, JS, czcionki itp., a także użyj responsywnych obrazów, aby skrócić czas ładowania.

Wiele problemów opisanych powyżej możemy rozwiązać, korzystając z renderowania po stronie serwera (SSR) lub renderowania wstępnego. Omówimy te podejścia poniżej.

Wejdź do reakcji izomorficznej

Słownikowa definicja terminu izomorficznego brzmi „odpowiadająca lub podobna w formie”.

W terminologii React oznacza to, że serwer ma podobną formę do klienta. Innymi słowy, możesz ponownie użyć tych samych komponentów React na serwerze i kliencie.

To izomorficzne podejście umożliwia serwerowi renderowanie aplikacji React i wysyłanie wyrenderowanej wersji do naszych użytkowników i wyszukiwarek, aby mogli natychmiast przeglądać zawartość, podczas gdy JavaScript ładuje się i wykonuje w tle.

Frameworki takie jak Next.js czy Gatsby spopularyzowały to podejście. Powinniśmy zauważyć, że komponenty izomorficzne mogą wyglądać znacząco inaczej niż konwencjonalne komponenty React. Na przykład mogą zawierać kod, który działa na serwerze zamiast na kliencie. Mogą nawet zawierać klucze tajne API (chociaż kod serwera jest usuwany przed wysłaniem do klienta).

Warto zauważyć, że te frameworki abstrahują od dużej złożoności, ale także wprowadzają uparty sposób pisania kodu. W dalszej części tego artykułu omówimy kompromisy w zakresie wydajności.

Przeprowadzimy również analizę macierzową, aby zrozumieć związek między ścieżkami renderowania a wydajnością witryny. Ale zanim to nastąpi, przejrzyjmy kilka podstaw mierzenia wydajności witryny.

Wskaźniki wydajności witryny

Przyjrzyjmy się niektórym czynnikom wykorzystywanym przez wyszukiwarki do pozycjonowania stron internetowych.

Oprócz szybkiej i dokładnej odpowiedzi na zapytanie użytkownika, Google uważa, że ​​dobra witryna powinna mieć następujące atrybuty:

• Powinno się szybko załadować.
• Użytkownicy powinni mieć dostęp do treści bez zbyt długiego oczekiwania.
• Powinien wcześnie stać się interaktywny dla działań użytkownika.
• Nie powinien pobierać niepotrzebnych danych ani wykonywać kosztownego kodu, aby zapobiec wyczerpaniu danych lub baterii użytkownika.

Te funkcje odpowiadają w przybliżeniu następującym wskaźnikom:

• TTFB : Time to First Byte — czas między kliknięciem łącza a pojawieniem się pierwszego fragmentu treści.
• LCP : Największa zawartość treści — czas, w którym żądany artykuł staje się widoczny. Google zaleca utrzymanie tej wartości poniżej 2,5 sekundy.
• TTI : Time To Interactive — czas, w którym strona staje się interaktywna (użytkownik może przewijać, klikać itp.).
• Rozmiar pakietu — łączna liczba pobranych bajtów i wykonanego kodu, zanim strona stała się w pełni widoczna i interaktywna.

Ponownie przyjrzymy się tym metrykom, aby lepiej zrozumieć, jak różne ścieżki renderowania mogą wpływać na każdą z nich.

Następnie przyjrzyjmy się różnym ścieżkom renderowania dostępnym dla programistów React.

Ścieżki renderowania

Możemy renderować aplikację React w przeglądarce lub na serwerze i generować różne wyniki.

Między aplikacjami renderowanymi po stronie klienta i po stronie serwera znacząco zmieniają się dwie funkcje, a mianowicie routing i dzielenie kodu . Poniżej przyjrzymy się im bliżej.

Renderowanie po stronie klienta (CSR)

Renderowanie po stronie klienta jest domyślną ścieżką renderowania dla React SPA. Serwer będzie obsługiwał aplikację powłoki , która nie zawiera żadnej treści. Gdy przeglądarka pobierze, przeanalizuje i wykona dołączone źródła JavaScript, treść HTML zostanie wypełniona lub zrenderowana .

Funkcja routingu jest obsługiwana przez aplikację kliencką , zarządzając historią przeglądarki. Oznacza to, że ten sam plik HTML jest obsługiwany niezależnie od żądanej trasy, a klient aktualizuje swój stan widoku po jego wyrenderowaniu.

Dzielenie kodu jest stosunkowo proste. Możesz podzielić swój kod za pomocą importów dynamicznych lub React.lazy tak, aby tylko potrzebne zależności były ładowane na podstawie działań trasy lub użytkownika.

Jeśli strona musi pobrać dane z serwera w celu wyrenderowania treści — na przykład tytuł bloga lub opis produktu — może to zrobić tylko wtedy, gdy odpowiednie komponenty są zamontowane i wyrenderowane.

Użytkownik najprawdopodobniej zobaczy znak lub wskaźnik „Wczytywanie danych”, gdy witryna pobiera dodatkowe dane.

Renderowanie po stronie klienta z danymi początkowymi (CSRB)

Rozważ ten sam scenariusz, co CSR, ale zamiast pobierać dane po wyrenderowaniu DOM, powiedzmy, że serwer wysłał odpowiednie dane załadowane wewnątrz obsługiwanego kodu HTML.

Możemy dołączyć węzeł, który wygląda mniej więcej tak:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

I przeanalizuj go, gdy komponent się zamontuje:

 var data = JSON.parse(document.getElementById('data').innerHTML);

Właśnie oszczędziliśmy sobie podróży w obie strony na serwer. Za chwilę zobaczymy kompromisy.

Renderowanie po stronie serwera na zawartość statyczną (SSRS)

Wyobraź sobie scenariusz, w którym musimy generować HTML w locie.

Na przykład, jeśli budujemy kalkulator online, a użytkownik wysyła zapytanie typu /calculate/34+15 (pomijając escaping adresu URL). Musimy przetworzyć zapytanie, ocenić wynik i odpowiedzieć wygenerowanym kodem HTML.

Nasz wygenerowany kod HTML ma dość prostą strukturę i nie potrzebujemy React do zarządzania i manipulowania DOM po udostępnieniu wygenerowanego kodu HTML.

Więc po prostu obsługujemy zawartość HTML i CSS. Aby to osiągnąć, możesz użyć metody renderToStaticMarkup .

Routing będzie w całości obsługiwany przez serwer, ponieważ musi on ponownie obliczyć kod HTML dla każdego wyniku, chociaż buforowanie CDN może służyć do szybszego dostarczania odpowiedzi. Pliki CSS mogą być również buforowane przez przeglądarkę w celu szybszego ładowania kolejnych stron.

Renderowanie po stronie serwera z ponownym nawodnieniem (SSRH)

Wyobraźmy sobie ten sam scenariusz, co opisany powyżej, ale tym razem potrzebujemy w pełni funkcjonalnej aplikacji React na kliencie.

Zamierzamy wykonać pierwsze renderowanie na serwerze i odesłać zawartość HTML wraz z plikami JavaScript. React ponownie uwodni renderowane przez serwer znaczniki i od tego momentu aplikacja będzie zachowywać się jak aplikacja CSR.

React udostępnia wbudowane metody wykonywania tych czynności.

Pierwsze żądanie jest obsługiwane przez serwer, a kolejne renderowania są obsługiwane przez klienta. Dlatego takie aplikacje nazywane są uniwersalnymi aplikacjami React (renderowanymi zarówno na serwerze, jak i na kliencie). Kod do obsługi routingu może być podzielony (lub zduplikowany) na kliencie i serwerze.

Podział kodu jest również nieco trudny, ponieważ ReactDOMServer nie obsługuje Reacta. leniwy, więc być może będziesz musiał użyć czegoś takiego jak Loadable Components.

Należy również zauważyć, że ReactDOMServer wykonuje tylko płytkie renderowanie. Innymi słowy, chociaż zostanie wywołana metoda render dla twoich komponentów, metody cyklu życia, takie jak componentDidMount , nie zostaną wywołane. Będziesz więc musiał dokonać refaktoryzacji kodu, aby dostarczyć dane do komponentów przy użyciu alternatywnej metody.

Tutaj pojawiają się frameworki, takie jak NextJS. Maskują złożoność związaną z routingiem i dzieleniem kodu w SSRH i zapewniają płynniejszą pracę programisty.

Takie podejście daje mieszane wyniki, jeśli chodzi o wydajność strony, jak zauważymy za chwilę.

Wstępne renderowanie do zawartości statycznej (PRS)

Co by było, gdybyśmy mogli wyrenderować stronę internetową, zanim użytkownik o to poprosi? Można to zrobić w czasie kompilacji lub dynamicznie, gdy zmienią się dane.

Następnie możemy buforować powstałą zawartość HTML w sieci CDN i obsługiwać ją znacznie szybciej, gdy użytkownik o to poprosi.

Nazywa się to renderowaniem wstępnym przed wyrenderowaniem treści, żądaniem przed użytkownikiem. Takie podejście można zastosować w przypadku blogów i aplikacji e-commerce, ponieważ ich zawartość zazwyczaj nie zależy od danych dostarczonych przez użytkownika.

Wstępne renderowanie z nawodnieniem (PRH)

Możemy chcieć, aby nasz wstępnie wyrenderowany kod HTML był w pełni funkcjonalną aplikacją React, gdy klient ją wyrenderuje.

Po wysłaniu pierwszego żądania aplikacja będzie się zachowywać jak standardowa aplikacja React. Ten tryb jest podobny do opisanego powyżej SSRH pod względem funkcji routingu i dzielenia kodu.

Macierz wydajności

Nadeszła chwila, na którą czekałeś. Czas na ostateczną rozgrywkę. Przyjrzyjmy się, jak każda z tych ścieżek renderowania wpływa na wskaźniki wydajności sieci i określ zwycięzcę.

W tej macierzy przypisujemy ocenę każdej ścieżce renderowania na podstawie tego, jak dobrze wypada w metryce wydajności.

Wynik waha się od 1 do 5:

• 1 = niezadowalająca
• 2 = słaba
• 3 = Umiarkowane
• 4 = dobry
• 5 = Doskonała

Kluczowe dania na wynos

Wstępne renderowanie do zawartości statycznej (PRS) prowadzi do witryn o najwyższej wydajności , podczas gdy renderowanie po stronie serwera z uwodnieniem (SSRH) lub renderowanie po stronie klienta (CSR) może prowadzić do niezadowalających wyników.

Możliwe jest również zastosowanie wielu podejść do różnych części witryny . Na przykład te wskaźniki wydajności mogą mieć krytyczne znaczenie dla publicznych stron internetowych, dzięki czemu można je indeksować wydajniej, podczas gdy mogą mieć mniejsze znaczenie, gdy użytkownik się zaloguje i zobaczy dane z prywatnego konta.

Każda ścieżka renderowania reprezentuje kompromisy w miejscu i sposobie przetwarzania danych. Ważne jest, aby zespół inżynierów był w stanie wyraźnie zobaczyć i omówić te kompromisy oraz wybrać architekturę, która maksymalizuje zadowolenie użytkowników.

Dalsza lektura i uwagi

Chociaż starałem się omówić obecnie popularne techniki, nie jest to wyczerpująca analiza. Gorąco polecam przeczytanie tego artykułu, w którym programiści z Google omawiają inne zaawansowane techniki, takie jak renderowanie serwera strumieniowego, renderowanie trisomorficzne i renderowanie dynamiczne (serwowanie różnych odpowiedzi robotom i użytkownikom).

Niektóre inne czynniki, które należy wziąć pod uwagę podczas tworzenia witryn internetowych z dużą ilością treści, obejmują potrzebę dobrego systemu zarządzania treścią (CMS) dla autorów oraz możliwość łatwego generowania/modyfikowania podglądów w mediach społecznościowych i optymalizacji obrazów pod kątem różnych rozmiarów ekranu.