Dlaczego renderowanie dynamiczne nie jest rozwiązaniem długoterminowym

Na wypadek, gdybyś to przegapił, Google ostatnio określiło, że:

• Renderowanie dynamiczne to obejście, a nie długoterminowe rozwiązanie problemów z JavaScriptem, a
• Google zaleca zamiast tego używanie renderowania po stronie serwera, renderowania statycznego lub uwodnienia.

Chociaż oficjalna dokumentacja Google rzuca światło na to, jak powinniśmy teraz traktować renderowanie dynamiczne, wiele osób nurtuje pytanie: dlaczego właściwie powinniśmy uważać renderowanie dynamiczne za rozwiązanie tymczasowe?

Jeśli to pytanie skłania Cię do szukania odpowiedzi tak jak ja, zajmijmy się!

Dlaczego ta aktualizacja jest ważna?

Aby zrozumieć, dlaczego uważamy tę aktualizację za niezbędną, cofnijmy się i zobaczmy, jak Google wcześniej traktowało renderowanie (dynamiczne).

Oś czasu renderowania dynamicznego

Wszystko zaczęło się w 2009 roku, kiedy Google zdał sobie sprawę, że prawie 70% wszystkich stron internetowych, o których Google wiedziało, że używa już JavaScriptu. Ale problem polegał na tym, że w tamtym czasie nie byli w stanie w ogóle renderować JavaScript.

Aby zapewnić przeszukiwanie i indeksowanie kodu JavaScript, firma Google zasugerowała udostępnianie botom statycznej wersji HTML witryny podczas udostępniania użytkownikom w pełni funkcjonalnej witryny opartej na języku JavaScript. Był to początek dzisiejszego dynamicznego renderowania jako obejście w przypadkach, gdy Google nie mógł poradzić sobie z witryną renderowaną po stronie klienta.

W 2014 roku Google oficjalnie przyznało, że zaczęło renderować strony internetowe oparte na JavaScript , aby w 2015 roku zaktualizować, że ogólnie są w stanie renderować JavaScript . Jednak wiele stron internetowych wciąż ma problemy z prawidłowym renderowaniem i indeksowaniem treści JavaScript.

Dlatego Bartosz Góralewicz, dyrektor generalny Onely, zaczął badać temat i eksperymentować, aby dowiedzieć się, czy Google potrafi poprawnie indeksować i indeksować frameworki JavaScript .

Natomiast ze strony Google dokładniejsze informacje dotyczące renderowania dynamicznego pojawiły się w 2018 roku. Podczas konferencji Google I/O pracownicy Google przyznali, że stosują dwie fale indeksowania. Wskazał, że generalnie renderowanie witryn opartych na języku JavaScript jest odroczone, o ile Google nie ma zasobów do przetworzenia tej treści. Ponadto wkrótce po konferencji Google opublikował oficjalną dokumentację (teraz zaktualizowaną), zalecając dynamiczne renderowanie, aby szybciej indeksować zawartość JavaScipt.

Następnie w 2019 roku Bartosz Góralewicz rozwinął temat dynamicznego renderowania podczas swojej prezentacji na SMX WEST . Jego celem było wyjaśnienie, dlaczego to rozwiązanie nie jest srebrną kulą we wszystkich problemach z renderowaniem.

I chociaż my w Onely już wtedy wiedzieliśmy, że dynamiczne renderowanie nie jest najlepszym rozwiązaniem, Google nadal poleca je jako obejście przetwarzania JavaScript przez roboty, aby webmasterzy nadal go używali. Niestety, często nie zdawali sobie sprawy, jak drogie jest goszczenie.

Co to jest renderowanie dynamiczne?

Renderowanie dynamiczne (nazywane również renderowaniem wstępnym) polega na udostępnianiu użytkownikom w pełni funkcjonalnej wersji JavaScript witryny oraz statycznej wersji HTML robotom indeksującym w celu zaprezentowania treści JavaScript. Działa poprzez wykrywanie i rozróżnianie różnych agentów użytkownika oraz udostępnianie użytkownikom i botom odpowiednich wersji witryny.

Nie musi to jednak oznaczać, że użytkownicy muszą otrzymywać wyłącznie treści renderowane po stronie klienta; po prostu nie są obsługiwane przez te same pliki statyczne, co boty. Ogólnie rzecz biorąc, całe środowisko JavaScript jest udostępniane użytkownikom, a pliki HTML ‒ robotom.

Google uzupełnia tę definicję, określając:

Nazywamy to dynamicznym, ponieważ Twoja witryna dynamicznie wykrywa, czy żądanie pochodzi od robota indeksującego, takiego jak Googlebot, i dopiero wtedy wysyła treść renderowaną po stronie serwera bezpośrednio do klienta. Możesz tu również dołączyć inne usługi sieciowe, które nie radzą sobie z renderowaniem. Na przykład usługi mediów społecznościowych, usługi czatu lub wszystko, co próbuje wyodrębnić uporządkowane informacje z Twoich stron. A dla wszystkich innych requesterów, czyli zwykłych użytkowników, możesz obsługiwać normalny kod renderowany po stronie klienta lub hybrydowy.

źródło: John Muller

Ponieważ etap renderowania jest ogólnie kosztowny do przetworzenia przez roboty, renderowanie dynamiczne udostępnia Googlebotowi łatwą do zrozumienia, lekką, statyczną wersję HTML, która przyspiesza przygotowanie treści do ewentualnego indeksowania.

Dlatego Google sugeruje, że dynamiczne renderowanie może być kompromisem głównie w przypadku stron internetowych:

• często zmieniając swoją zawartość, np. serwisy informacyjne ‒ muszą jak najszybciej zaindeksować świeżą zawartość, aby nie mogli odroczyć wykonania renderowania JavaScript,
• za pomocą nowoczesnych funkcji JavaScript, które nie są obsługiwane przez roboty indeksujące oraz
• polegając na udostępnianiu swoich treści za pośrednictwem mediów społecznościowych lub aplikacji czatu.

Czym różni się renderowanie dynamiczne od innych popularnych sposobów obsługi JavaScript?

Renderowanie jest kluczowym etapem procesu indeksowania — sposób renderowania witryny wpływa na to, jak wyszukiwarki widzą Twoje treści. Aby zaspokoić potrzeby zarówno botów, jak i użytkowników, musisz poznać dwa różne podejścia: renderowanie po stronie serwera i renderowanie po stronie klienta.  

Zrozumienie ich jest kluczowe, ponieważ te koncepcje powtarzają się również na różne sposoby obsługi JavaScript, które możesz wybrać, takie jak renderowanie dynamiczne.

Renderowanie po stronie klienta

Renderowanie po stronie klienta opiera się na przetwarzaniu treści bezpośrednio w przeglądarce za pomocą JavaScript. Na początku przeglądarki i roboty indeksujące otrzymują początkowy kod HTML (który zwykle reprezentuje puste strony z niewielką zawartością lub bez zawartości). Następnie JavaScript jest asynchronicznie pobierany i uruchamiany z serwera, wyświetlając Twoją dynamiczną zawartość użytkownikom.

Jednak stosując to podejście, ryzykujesz, że Twoje treści nie zostaną wyrenderowane przez Google, ponieważ może mieć trudności z samodzielnym przetworzeniem wersji witryny opartej na JavaScript z powodu jej ograniczonych zasobów. Należy pamiętać, że samo renderowanie po stronie klienta nie stanowi problemu i Google może sobie z tym poradzić, ale jeśli nie jest dobrze zoptymalizowane, jego indeksowanie, renderowanie i indeksowanie jest bardzo kosztowne.

Renderowanie po stronie serwera

Dzięki renderowaniu po stronie serwera boty i użytkownicy otrzymują wersję HTML Twojej witryny w pełni wyrenderowaną na serwerze natychmiast, w momencie żądania. Fakt, że renderowanie HTML jest obsługiwane na serwerze, przyspiesza cały proces dla przeglądarek i ogólnie ułatwia wyszukiwarkom pobieranie treści.

Ponadto, chociaż renderowanie po stronie serwera jest zalecanym rozwiązaniem, Google podkreśla, że ​​jego wybór nie ma wpływu na rankingi – różni się od renderowania dynamicznego jedynie pod względem konfiguracji i konserwacji:

Nie ma żadnych premii rankingowych SEO za wdrożenie go w taki czy inny sposób – są to po prostu różne sposoby indeksowania treści (podobnie jak renderowanie po stronie klienta). Różnice między renderowaniem dynamicznym a renderowaniem po stronie serwera z mojego POV są bardziej pod względem praktycznej konfiguracji i konserwacji infrastruktury (może to również wpływać na szybkość, w zależności od tego, jak masz wszystko skonfigurowane).

źródło: John Muller

Jak działa renderowanie dynamiczne?

Renderowanie dynamiczne może korzystać z zewnętrznego modułu renderującego, aby ułatwić zmianę początkowego kodu HTML i JavaScript na statyczny kod HTML , który mogą przetworzyć roboty indeksujące.

Google zaleca używanie następujących dynamicznych rendererów:

• Prerender.io (oprogramowanie firm trzecich),
• Lalkarz (oprogramowanie open-source), lub
• Rendertron (oprogramowanie open-source).

Po skonfigurowaniu któregokolwiek z zalecanych rozwiązań pamiętaj, aby:

1. Wybierz klienty użytkownika, dla których chcesz wyświetlać statyczną wersję HTML swojej witryny, np. „googlebot” lub „twitterbot”.
2. Skonfiguruj pamięć podręczną, aby Twoja witryna była obsługiwana tak szybko, jak to możliwe i unikaj przekroczeń limitu czasu.
3. Upewnij się, że wstępnie wyrenderowana wersja Twojej witryny obsługuje wersję zorientowaną na urządzenie. Innymi słowy, roboty indeksujące wyszukiwarki mobilne powinny widzieć mobilną wersję Twojej witryny, gdy inne roboty – wersję komputerową.
4. Upewnij się, że serwer może udostępniać statyczny kod HTML wybranym klientom użytkownika.

Jeśli chodzi o implementację renderowania dynamicznego, Google udostępnia oficjalną dokumentację dotyczącą implementacji i weryfikacji konfiguracji renderowania dynamicznego.

Dlaczego i jak zacząć poruszać się po problemach z dynamicznym renderowaniem?

Google nie może w pełni zindeksować witryny opartej na języku JavaScript, dopóki nie zostanie ona w pełni wyrenderowana. Więc jeśli dynamiczne renderowanie się nie powiedzie, Twoja treść nie zostanie uwzględniona w SERP.

Weźmy za przykład popularne amerykańskie witryny handlu elektronicznego: 80% użytkowników używa JavaScript do generowania głównej treści i linków do podobnych produktów . Stanowi poważne zagrożenie dla indeksowalności krytycznych części tych domen. Zastanów się teraz, jak przekłada się to na spadek ich przychodów.

Dlatego kluczowym etapem implementacji renderowania dynamicznego jest nawigacja i weryfikacja potencjalnych problemów.  

Skorzystaj z testu optymalizacji mobilnej

Narzędzie pozwala upewnić się, że Twoja witryna jest przyjazna dla urządzeń mobilnych, a także zobaczyć wyrenderowany kod źródłowy testowanej witryny wraz ze zrzutem ekranu pokazującym, jak Googlebot renderuje Twoją stronę na urządzeniach mobilnych.

Możesz zaobserwować brak niektórych części treści w kodzie źródłowym – jest to sygnał dla Ciebie, że Googlebot nie był w stanie wyrenderować tych zasobów, co może być wynikiem niewłaściwie zaimplementowanego renderowania dynamicznego.

W tym narzędziu możesz zagłębić się w sekcję Szczegóły, aby dowiedzieć się, kiedy i przez jakiego robota indeksującego strona została zindeksowana, a nawet sprawdzić odpowiedź HTTP. Jeśli sprawdzasz swoją domenę, test optymalizacji mobilnej może przenieść Cię do dalszej analizy w Google Search Console.

Jeśli zdarzy Ci się napotkać problemy podczas korzystania z Testu optymalizacji mobilnej, przeczytaj artykuł na naszym blogu , aby dowiedzieć się, jak zoptymalizować swoją witrynę pod kątem urządzeń mobilnych.

Użyj Google Search Console

Jednym z raportów, które musisz sprawdzić, aby upewnić się, że renderowanie dynamiczne zostało prawidłowo zaimplementowane, jest raport Pokrycie indeksu (indeksowanie stron). Pomaga w poruszaniu się po problemach z indeksowaniem i informuje o tym, które strony nie są indeksowane i dlaczego.

Przykładem stanu, który może sugerować problemy z renderowaniem w Twojej witrynie, jest stan Strona zindeksowana bez zawartości ‒ Googlebot nie mógł zobaczyć zawartości, ponieważ nie mógł renderować strony.

Inną przydatną funkcją w Google Search Console jest narzędzie do sprawdzania adresów URL . Podobnie jak w przypadku testu optymalizacji mobilnej, narzędzie do sprawdzania adresów URL pozwala sprawdzić stan testowanej strony i zobaczyć jej wyrenderowaną wersję.

Użyj ZipTie.dev

Ponieważ problemy z indeksowaniem mogą wynikać z problemów z renderowaniem, warto przeanalizować sposób indeksowania Twojej witryny. Należy przyjrzeć się zarówno liczbie zaindeksowanych stron, jak i tym, czy poszczególne sekcje tych stron są indeksowane.

Aby sprawdzić, czy dany fragment Twojej strony jest zaindeksowany, możesz użyć polecenia site: wraz z fragmentem tekstu w cudzysłowie. Ale jeśli masz dużą witrynę z milionami adresów URL do przeanalizowania, nie będziesz w stanie sprawdzić ich wszystkich ręcznie.

ZipTie.dev analizuje indeksowanie wraz z innymi punktami danych, takimi jak liczba słów, tytuły, nagłówki, opisy meta i inne. Pomoże Ci to zidentyfikować potencjalne przyczyny problemów z indeksowaniem (a więc renderowaniem).

Użyj testu wyników bogatych

Jeśli korzystasz z danych strukturalnych w swojej witrynie i zależy Ci na wynikach z elementami rozszerzonymi, skorzystaj z testu wyników z elementami rozszerzonymi, aby sprawdzić, czy znaczniki są prawidłowo zaimplementowane.

Test pokazuje również wyrenderowaną wersję witryny i pokazuje, w jaki sposób Googlebot rozumie Twoje znaczniki, podając wszelkie błędy, ich typy oraz miejsce ich występowania w kodzie.

Jednak samo zaznaczenie pól na liście „Jak rozwiązywać problemy z renderowaniem dynamicznym” zwykle może nie wystarczyć. Im większa i bardziej złożona strona, tym trudniej na pierwszy rzut oka określić, co dokładnie poszło nie tak.

Na przykład wyniki błędu z testu optymalizacji mobilnej mogą sugerować, że masz problemy z renderowaniem. Ale w tym samym czasie serwer mógł właśnie doświadczyć tymczasowej usterki i nie odpowiadał skutecznie innymi zasobami, takimi jak pliki CSS. W efekcie wpływa to na sposób wyświetlania strony, ale może to być tylko jednorazowa sytuacja.

Rozwiązywanie problemów z renderowaniem (dynamicznym) zawsze będzie wymagało ogólnej wiedzy technicznej na temat SEO i dokładnej analizy.

Dlaczego renderowanie dynamiczne nie jest rozwiązaniem długoterminowym?

Dynamiczne renderowanie wykorzystuje znaczne ilości zasobów serwera

Dynamiczne renderowanie może znacznie spowolnić Twój serwer. Duża liczba żądań wstępnego renderowania może spowodować niepowodzenie renderowania, dlatego Googlebot będzie:

• Otrzymuj pustą stronę ‒ Googlebot widzi tylko początkowy kod HTML, ale ponieważ w kodzie nie ma odwołania JavaScript, reszta witryny jest dla niego niewidoczna. Witryna nie może zostać zindeksowana, ponieważ Googlebot nie widzi treści.
• Otrzymaj wersję strony wyrenderowaną po stronie klienta ‒ Google może technicznie poradzić sobie z JavaScriptem w wielu przypadkach, ale cały sens implementacji dynamicznego renderowania polegał na tym, aby dostarczyć mu statycznej treści. W niektórych przypadkach koszt pobrania treści JavaScript i aktualizacji początkowej wersji HTML witryny za jej pomocą może być zbyt wysoki dla Googlebota.

Dlatego zanim zdecydujesz się na dynamiczne renderowanie, koniecznie podejmij przemyślaną decyzję, czy Twoja strona tego potrzebuje.

Wdrożenie i utrzymanie dynamicznego renderowania może zużywać znaczną ilość zasobów serwera. A jeśli zauważysz, że Googlebot jest w stanie prawidłowo indeksować Twoje strony, to jeśli nie wprowadzasz w witrynie krytycznych, częstych zmian, być może nie musisz wdrażać niczego specjalnego. […]

źródło: John Muller

Dynamiczne renderowanie tworzy dwie oddzielne struktury witryny zamiast jednej

Korzystając z dynamicznego renderowania, utrzymujesz dwie wersje swojej witryny. Oznacza to, że musisz osobno zweryfikować, czy Twoja witryna jest dobrze zoptymalizowana pod kątem użytkowników i botów.

Dynamicznie renderowana strona internetowa wymaga doskonałych zespołów SEO i programistów. I nawet jeśli jako właściciel strony masz do dyspozycji takie zespoły, zastanów się, jak lepiej mogliby spędzać czas, nie skupiając się na weryfikacji dynamicznego renderowania.

Dynamiczne renderowanie pogarsza wrażenia użytkownika

Renderowanie dynamiczne oznacza, że ​​Twoi użytkownicy otrzymują wersję renderowaną po stronie klienta, a to może mieć niewielki wpływ na wydajność strony dla użytkowników, ponieważ wymaga, aby ich przeglądarki obsługiwały proces renderowania po ich stronie. A to może być prawdziwą walką, szczególnie dla użytkowników starszych telefonów, którzy będą mieli trudności z przetwarzaniem dużych ilości kodu JavaScript. Chociaż renderowanie po stronie klienta nie jest złe, zalecamy korzystanie z trasy po stronie serwera, gdy tylko jest to możliwe.

Dynamiczne renderowanie dodaje dodatkową warstwę złożoności podczas optymalizacji strony internetowej

W przypadku renderowania dynamicznego trudniej jest dostrzec i rozpoznać generowane przez nie problemy.

Dynamiczne renderowanie często kończy się niepowodzeniem z powodu problemów na serwerze lub brakujących komponentów. W rezultacie Googlebot otrzymuje pustą stronę. Niestety, nie masz o tym pojęcia, gdy patrzysz na stronę jako użytkownik (z w pełni funkcjonalnym JavaScriptem), a nie jako bot. Aby rozwiązać ten problem, przełącz klienta użytkownika na Googlebota w przeglądarce .

Zdiagnozowanie takich problemów i odkrycie agenta użytkownika generującego konkretny problem wymaga znacznej wiedzy z zakresu SEO. Musisz mieć świadomość, że żadna reakcja na problemy z renderowaniem nie może mieć wpływu na indeksowanie Twojej witryny.

Jakie są lepsze alternatywy dla renderowania dynamicznego?

Wszystkie wymienione poniżej rozwiązania , dobrze wdrożone, mogą być równie korzystne dla Twojej witryny z punktu widzenia SEO.

Jednak efekt wdrożenia zależy głównie od używanej technologii i zespołu programistów. Jeśli chodzi o zasoby deweloperskie, koszt wdrożenia każdego rozwiązania może się różnić, ale należy go oceniać indywidualnie w zależności od sytuacji.

Renderowanie po stronie serwera

To jedno z najpopularniejszych rozwiązań, które możesz zastosować zamiast dynamicznego renderowania.

Z punktu widzenia SEO najważniejszą zaletą korzystania z renderowania po stronie serwera jest utrzymywanie tylko jednej wersji witryny. W przeciwieństwie do renderowania dynamicznego nie musisz sprawdzać, czy wersje dla użytkowników i Googlebota są identyczne – wszystkie klienty użytkownika otrzymują tę samą treść.

Co więcej, w przeciwieństwie do renderowania dynamicznego, renderowanie po stronie serwera nie powoduje, że użytkownicy przetwarzają pliki JavaScript po swojej stronie w celu wygenerowania kluczowych elementów strony. Sprawia, że ​​strona ładuje się szybciej; niektóre wskaźniki wydajności sieci wpływają na twoje rankingi i wrażenia użytkownika.

Ale uważaj: w przypadku renderowania po stronie serwera użytkownicy mogą doświadczać nieco gorszych metryk czasu do pierwszego bajtu, jeśli serwer musi wygenerować statyczny kod HTML ad hoc lub serwer buforujący odpowiedzi nie jest wystarczająco wydajny.

I tylko dla wyjaśnienia: nawet jeśli renderowanie po stronie serwera jest poprawnie zaimplementowane, SEO nadal musi weryfikować wszystkie elementy witryny. Ale ogólnie rzecz biorąc, łatwiej jest utrzymać tylko jedną wersję strony internetowej.

Renderowanie statyczne

Renderowanie statyczne (znane również jako generowanie statyczne) polega na udostępnianiu botom i użytkownikom statycznej wersji HTML wygenerowanej w czasie kompilacji . Oznacza to, że kod Twojej witryny jest gotowy do przetworzenia przez roboty i użytkowników tylko czekających na pobranie na serwerze.

Podobnie jak w przypadku renderowania po stronie serwera, korzystając z tego rozwiązania, musisz zweryfikować tylko jedną wersję swojej witryny dla wszystkich agentów użytkownika.

Ponadto, w przeciwieństwie do renderowania dynamicznego, renderowanie statyczne poprawia wydajność strony, ponieważ szybciej wyświetla wstępnie wyrenderowaną wersję witryny — pliki statyczne mogą być buforowane na urządzeniach użytkowników i ponownie używane.

Rehydratacja

Nawadnianie obsługuje również tylko jedną wersję strony internetowej dla botów i użytkowników, podobnie jak dwa poprzednie rozwiązania. Działa jednak dwuetapowo.

Na pierwszym etapie roboty i użytkownicy otrzymują stronę renderowaną po stronie serwera, która zawiera krytyczne elementy. Na przykład w przypadku witryny eCommerce mogą to być nazwa produktu, opis lub oceny produktu. W drugim etapie JavaScript pobiera wszystkie niekrytyczne zasoby, które są niezbędne z punktu widzenia SEO, ale użytkownicy mogą je otrzymać z opóźnieniem. Są to np. widżety czatu czy sekcje komentarzy.

Podczas audytu strony internetowej za pomocą rehydracji należy sprawdzić, czy wszystkie elementy dodane przez JavaScript są tymi niekrytycznymi.

Czy renderowanie dynamiczne może działać długoterminowo?

Może, ale rzadko tak się dzieje. Zwłaszcza jeśli masz dużą witrynę internetową i nie znasz się na technice SEO, nie stosuj tego samego podejścia.

I pamiętaj, że nawet jeśli nie martwisz się technicznym SEO, dynamiczne renderowanie nadal będzie kosztowne w utrzymaniu.

Oto dwa przykłady sytuacji, w których nasi klienci używali renderowania dynamicznego do:

Udostępnianie linków renderowanych po stronie klienta dla użytkowników w stopce

W takim przypadku, dzięki dynamicznemu renderowaniu, Googlebot mógł znaleźć linki w kodzie źródłowym, ale jednocześnie linki w stopce były generowane dla użytkowników i dodawane do DOM (który reprezentuje stan strony po wyrenderowaniu) zaczął przewijać stronę. Klient zdecydował się na zaimplementowanie dynamicznego renderowania, aby zoptymalizować jego wydajność – nie wszystkie elementy muszą być natychmiast przechowywane w DOM, jeśli użytkownicy nie przewiną do końca strony.

Udostępnianie użytkownikom wyrenderowanej listy wewnętrznych wyników wyszukiwania po stronie klienta

Klient zdecydował się udostępniać botom wersję renderowaną po stronie serwera (lżejsza wersja zestawień) i użytkownikom renderowaną wersję po stronie klienta (gdy lista produktów jest generowana ad hoc i może być spersonalizowana).

Zawijanie

Podczas gdy renderowanie dynamiczne należy traktować tylko jako rozwiązanie tymczasowe, w niektórych przypadkach uznasz je za koło ratunkowe dla Twojej witryny.

Jeśli potrzebujesz zaimplementować renderowanie dynamiczne, pamiętaj, aby wykonać następujące cztery kroki:

1. Zaplanuj aktualizacje i wdrożenia. Upewnij się, że Twoje zespoły programistyczne i SEO mają wystarczające zasoby, aby poradzić sobie z wdrożeniem i utrzymaniem prerenderowanej witryny.
2. Upewnij się, że konfiguracja jest wydajna i wolna od błędów. Opracuj sposób na sprawdzenie, czy konfiguracja działa poprawnie i czy w wersji udostępnianej botom nie brakuje kluczowych elementów strony.
3. Pamiętaj, że musisz być w stanie porównać wersje HTML i JavaScript swojej witryny i wykryć rozbieżności.
4. Pamiętaj, że w większości przypadków renderowanie dynamiczne powinno być tylko obejściem problemu. Poszukaj możliwości przejścia na inne zalecane rozwiązania, biorąc pod uwagę Twoje zasoby programistyczne i możliwości technologiczne.