Przyspieszanie sklepu poprzez optymalizację DOM (wielkość HTML)

Nacisk na ładowanie strony przyjazne użytkownikowi

Pierwsza istotna aktualizacja algorytmu uwzględniająca czas ładowania strony miała miejsce kilkanaście lat temu. Wtedy można było łatwo ocenić czy strona ma problem czy nie, bo sprawdzaliśmy głównie jeden parametr: czas ładowania.

Google porzuciło ten sposób weryfikacji. Obecnie liczy się wiele czynników, nazywanych zbiorczo Core Web Vitals (Podstawowe Wskaźniki Internetowe).

Można je sprawdzić w narzędziu https://pagespeed.web.dev/, pojawiają się jako pierwsze na karcie wyników:

To szereg różnych wskaźników, które sprawdzają sposób ładowania strony – czy layout nie przesuwa się niespodziewanie podczas ładowania, jak długo użytkownik musi czekać aż pojawi się pierwsza treść ładowanej strony i wiele innych.

Narzędzie przedstawia również szczegółowe sugestie zmian, które mogą poprawić aktualne wyniki. Jest tu wiele podpowiedzi dotyczących rozmiarów zdjęć, stosowania pamięci podręcznej czy optymalizacji wielkości plików stylów czy JavaScript.

Jednak jest jeszcze jeden element diagnostyki, rozmiar DOM, który często jest pomijany przez deweloperów czy wtyczki do optymalizacji. Po części wynika to z tego, że dużo łatwiej jest zoptymalizować rozmiar plików css, js czy zdjęć, a sama modyfikacja DOM wymaga większej ingerencji.

Są przypadki, gdzie zdecydowanie warto poświęcić czas i środki na optymalizację DOM.

Czym jest DOM?

To model, który uporządkowuje elementy HTML. Struktura DOM jest hierarchiczna i przypomina drzewo.

Na szczycie tej hierarchii znajduje się dokument jako obiekt „root”. Ten obiekt ma „dzieci”, które mogą być różnymi elementami HTML takimi jak nagłówki, paragrafy, listy, linki itp.

Dzięki takiemu ułożeniu struktury możliwe jest odniesienie się do tych elementów i np. manipulacja z pomocą kodu JavaScript czy zmiana wyglądu z pomocą kodu CSS.

Mówiąc prościej – każdy element w kodzie strony jak h1, a href, div, p i inne wlicza się w DOM.

Dlaczego wielkość DOM wpływa na ładowanie strony

Kiedy wpisujemy adres strony, przeglądarka wysyłka żądanie do serwera o przesłanie informacji. Podstawą tego żądania jest kod HTML danej podstrony.

Jeśli rozmiar kodu HTML jest duży to wpływa to na pierwszą interakcję ze stroną – serwerowi może zająć nieco dłużej przygotowanie pliku HTML, przeglądarce użytkownika może zająć dłużej pobranie kodu (szczególnie na wolniejszych łączach typu 3G).

To nie wszystko.

Również podczas przeglądania strony wielkość kodu HTML wpływa na ogólną szybkość. Im większy kod, tym więcej kalkulacji stylów CSS, położenia elementów na ekranie musi wykonać przeglądarka.

Google zwraca na to uwagę w poradniku dotyczącym rozmiaru DOM:

(źródło: https://developer.chrome.com/docs/lighthouse/performance/dom-size/)

Jak prawidłowo sprawdzić co widzi robot indeksujący

Aby sprawdzić kod HTML i prawidłowo zidentyfikować potencjalne problemy musimy analizować ten sam kod HTML, który widzi robot Google podczas procesu indeksacji.

Sprawdzenie kodu z pomocą inspektora w przeglądarce nie jest tu zalecanym rozwiązaniem, bo ten podgląd kodu może się różnić.

Na szczęście mamy niezawodne Search Console. Wklejamy adres podstrony, którą chcemy sprawdzić.

Klikamy Wyświetl zindeksowaną stronę, z prawej strony pokaże się podgląd kodu HTML, który widzi robot indeksujący.

Możemy przeglądać kod i wyszukiwać interesujące nas fragmenty bezpośrednio w polu podglądu.

Wygodniejszy sposób to skopiowanie całego kodu i wklejenie do edytora jak Atom czy Sublime. Wystarczy zapisać plik z rozszerzeniem html i cały kod będzie odpowiednio wyróżniony.

Analiza rozmiaru DOM – kiedy wymaga uwagi

Sprawdzamy ogólną liczbę elementów DOM, poziom zagnieżdżenia i elementów podrzędnych.

Według wytycznych Google, Lighthouse diagnozuje DOM w następujący sposób:

• ostrzega, gdy element body ma więcej niż ~800 węzłów,
• pokazuje błędy, gdy element body ma więcej niż ~1400 węzłów.

Może się zdarzyć, że kod sklepu będzie tak rozbudowany, że ograniczenie go do wielkości poniżej 1400 węzłów nie będzie możliwe. W takich przypadkach mimo wszystko warto próbować ograniczyć rozmiar i liczbę elementów.

Nawet jeśli uda się ograniczyć ją z przykładowo 10000 elementów do 6000 elementów, to i tak wpłynie to pozytywnie na czas reakcji strony:

Liczbę pobieranych bajtów:

i inne aspekty związane z szybkością ładowania strony i renderowania poszczególnych elementów wizualnych podczas przewijania.

Komunikat z ostrzeżeniem nadal będzie pojawiał się w Google Search Console (bo liczba elementów będzie przekraczała granicę 1400), ale mimo to inne parametry powinny być zauważalnie lepsze.

Identyfikacja problematycznych obszarów DOM

Jest kilka ścieżek.

Można przejrzeć HTML bez pomocy narzędzi, ale to może być dość kłopotliwe przy mocno rozbudowanym kodzie.

Sugestie w Google Search Console wskazują, gdzie mogą być problematyczne obszary:

Przydatne są narzędzia do analizy rozmiarów DOM. Poniżej pokazujemy przykładowe screeny z narzędzia DOM SIZE ANALYZER, ale można znaleźć wiele narzędzi tego typu.

DOM Size Analyer to wtyczka do przeglądarki Chrome. Po zainstalowaniu dostępna jest w narzędziach dla deweloperów, pozwalających analizować kod:

Pozwala łatwo przeklikać się przez strukturę kodu. Zaczynamy od elementu div (lub innego), który zawiera pozostałe elementy.

Jak widać, te liczniejsze grupy podkreślone są na czerwono:

Można też łatwo przejrzeć poszczególne sekcje kodu jak header, główna część czy stopka (choć to ostatecznie będzie zależało od tego jak zakodowana jest dana strona).

Szukamy elementów, których jest zbyt wiele, lub które w ogóle nie powinny być ładowane na danej podstronie.

Może też się zdarzyć, że niektóre fragmenty kodu można zoptymalizować i osiągnąć takie same efekty z połową dotychczasowego kodu.

Zmiany DOM w praktyce

Zidentyfikowanie problemów i wprowadzenie zmian będzie wymagało pomocy web developera. Na podstawie kodu z Search Console i przejrzenia struktury można dokładniej sprawdzić w edytorze szczegóły:

Przy czym trzeba pamiętać, że nie każde oprogramowanie sklepu pozwoli nam wdrożyć zmiany w kodzie HTML.

Problemów nie powinno być przy otwartych skryptach jak WooCommerce, Magento, Presta czy też tych pisanych customowo na dane zamówienie.

Jeśli jednak korzystasz z rozwiązania abonamentowego to tam pole do zmian będzie mocniej ograniczone.

Dlatego ważny pierwszy krok w analizie problemów z DOM to sprawdzenie czy mamy dostęp do kodu HTML strony i w jakim stopniu jesteśmy w stanie go edytować.

Podsumowując

Optymalizacja DOM to nie działanie, które jest konieczne dla każdego skryptu e-commerce.

W praktyce większość mniejszych i średnich sklepów powinna mieć dobre wyniki Pagespeed pracując nad innymi elementami Core Web Vitals, optymalizując pamięć podręczną czy wielkość zdjęć. Sama optymalizacja DOM może w ich przypadku nie dać mocno zauważalnych efektów i kosztowo nie być uzasadniona.

Sytuacja prezentuje się inaczej w przypadku większych sklepów, szczególnie tych ze sporym ruchem dziennym. Tutaj każde działanie, które wpływa na odchudzenie kodu przekłada się na mniejsze obciążenie serwera, lepsze wyniki Core Web.

W przypadku optymalizacji DOM najlepiej jest skorzystać z pomocy web developera. Pomoże przeprowadzić analizę, wprowadzić zmiany, ale też na początku może zweryfikować możliwe opcje edycji kodu.

sprawdź też