DOM (Document Object Model) to interfejs programistyczny dla dokumentów HTML i XML oraz nazwa nadana strukturze dokumentu HTML, składającej się z gałęzi i węzłów zawierających obiekty.
Historia Document Object Model sięga tak zwanych"wojen przeglądarek" z końca lat 90. między Netscape Navigator i Microsoft Internet Explorer, a także JavaScript i JScript, pierwszych języków skryptowych, które zostały szeroko zaimplementowane w silnikach JavaScript przeglądarek internetowych.
Struktura DOM w WordPress: drzewo, gałęzie i węzły
DOM w WordPress nie różni się zbytnio od każdej innej strony internetowej.
<html> <-- Árbol (nodo raíz)
│
├── <head> <-- Rama
│ ├── <title> <-- Nodo (hoja)
│ └── <meta> <-- Nodo (hoja)
│
└── <body> <-- Rama
├── <header> <-- Rama
│ └── <h1> <-- Nodo (hoja)
│
├── <div> <-- Rama
│ ├── <p> <-- Nodo (interno)
│ └── <img> <-- Nodo (hoja)
│
└── <footer> <-- Rama
└── <a> <-- Nodo (hoja)
- Drzewo: Cała strona jest reprezentowana jako drzewo z węzłem głównym
(<html>)i jego elementami podrzędnymi. - Gałęzie: Każdy element w
<div>,<header>,<footer>itp. reprezentuje gałąź drzewa. - Węzły: Wszystkie elementy HTML, takie jak
<p>,<img>lub<a>,są węzłami, które zwisają z gałęzi. Węzły te mogą być wewnętrzne (zawierające inne węzły) lub zewnętrzne ("liście" drzewa, które nie mają innych dzieci).
Tak więc gęstość gałęzi będzie zależeć od rodzaju i liczby elementów, które ją tworzą. Na przykład, złożone menu nawigacyjne w WordPress może generować kilka poziomów gałęzi i dziesiątki węzłów ze względu na liczbę linków i podmenu.
Węzły można traktować jako wszystkie elementy HTML na stronie. Im więcej elementów, tym zazwyczaj dłużej trwa proces, co prowadzi do wyższego całkowitego czasu blokowania(TBT).
Może to być trudne do zoptymalizowania w WordPress, ponieważ nie można po prostu usunąć elementów DOM, które tworzą strukturę strony. Możemy jednak selektywnie wyświetlać te elementy i ładować ciąg obiektów poniżej zagięcia, zmniejszając w ten sposób ogólny rozmiar DOM.
Po co zmniejszać rozmiar DOM?
Obszerne drzewo DOM może spowolnić czas ładowania witryny na kilka sposobów, zwiększając zużycie pamięci poprzez powodowanie dłuższych i wolniejszych obliczeń stylu, a także generując niepotrzebne koszty danych dla użytkowników.
Te różne scenariusze mogą obejmować niepotrzebne ładowanie węzłów, które nie są widoczne, gdy użytkownik po raz pierwszy ładuje stronę, ciągłe powtarzanie obliczeń pozycji i stylu węzłów oraz przechowywanie nadmiernej liczby odniesień do węzłów, które przeciążają pamięć urządzeń użytkowników.
Krótko- i długoterminowe korzyści płynące z optymalizacji szybkości ładowania strony zostały już wyjaśnione w tysiącu artykułów. Krótko mówiąc, w perspektywie krótkoterminowej unikniesz sytuacji, w której ludzie opuszczają Twoją stronę znudzeni czekaniem i najprawdopodobniej spędzą na niej więcej czasu. Szybkość ładowania jest jednym z czynników uznawanych przez Google w pozycjonowaniu SEO i rozumiem, że jest tak również w przypadku pozostałych wyszukiwarek, więc w dłuższej perspektywie cenny ruch organiczny wzrośnie.
Co powoduje wzrost rozmiaru DOM?
Na ostateczny rozmiar DOM ma wpływ wiele czynników, takich jak sam szablon, to, co dodają różne używane wtyczki i rodzaj dodawanej zawartości, takiej jak złożone bloki lub nikczemne "suwaki" obrazów itp. Również kod generowany na przykład przez tak zwane "Buildery".
Na przykład, do 2022 roku, w którym porzuciłem Elementora, ponieważ był odporny na optymalizację i rzadko zdarzało się, że nie zepsuł czegoś w prawie każdej aktualizacji, plus kilka złych doświadczeń z ich wsparciem technicznym, ten kreator zamienił kod internetowy w prawdziwą zupę alfabetyczną i koszmar z tysiącami
W kwietniu tego samego roku Elementor włączył "kontener" Flexbox jako bardzo nową i rewolucyjną nowość, podczas gdy kontener był już podstawą GenerateBlocks od lat.
Jak mierzyć DOM?
Do pomiaru wybrałem post, który nie jest jeszcze bardzo zoptymalizowany, trochę długi i z różnymi typami elementów.
Zacznijmy od najbardziej znanego i popularnego: PageSpeed Insights . Google zaznacza tam jako ostrzeżenie(napomarańczowo), gdy element body ma więcej niż 800 węzłów i jako komunikat o błędzie(na czerwono), gdy element body ma więcej niż 1400 węzłów oraz komunikat z zaleceniem:"Unikaj nadmiernego rozmiaru DOM".
W zależności od zawartości i struktury każdej analizowanej strony, znajdziesz mniej lub więcej wskazówek, które elementy możesz zaatakować. Zaletą jest to, że zazwyczaj pokazuje obraz wskazujący na dany element.
Jeszcze raz chciałbym przypomnieć, że wszystkie te alerty są jedynie zaleceniami i nie należy panikować ani mieć obsesji na punkcie tych wskaźników. Istnieją strony, które oferują dobre wrażenia użytkownika i dobrą postrzeganą szybkość z niskimi wynikami PageSpeed.
Z GTmetrix otrzymamy generalnie te same wyniki na DOM.
Jednak tutaj jego "wodospadowy" wykres żądań jest bardzo przydatny, aby na pierwszy rzut oka sprawdzić wszystkie elementy posortowane według typu i czasu ładowania.
Ale najprostszym i najszybszym sposobem jest skorzystanie z dowolnej przeglądarki. Otwórz stronę do analizy i kliknij prawym przyciskiem myszy / "inspect", a w zakładce "Network" znajdziesz znacznie bardziej szczegółowy wodospad , ponieważ możesz go uzupełnić, przewijając stronę, a wszystkie pliki, które zawiera, zostaną dodane. Następnie można je sortować według wagi, typu, czasu itp.
Poniżej tego okna znajduje się podsumowanie wyników. Po lewej stronie liczba żądań. Po prawej, na niebiesko, czas zdarzenia DOMContentLoaded, a na czerwono czas ładowania strony.
Zmniejsz rozmiar DOM za pomocą "Leniwych elementów" Perfmatters.
Perfmatters, ta niezbędna wtyczka, której nigdy nie znudzi mi się polecanie, dodała w wersji 2.3.3 z 28 sierpnia 2024 r. opcję o nazwie Lazy Elements, która, choć wciąż jest w wersji beta, działa naprawdę dobrze, aby ułatwić zadanie rozjaśniania DOM.
Ta funkcja umożliwia dodanie błędnie nazwanego"Lazy Load" do określonych elementów i ich elementów potomnych (dzieci) poprzez dodanie dowolnej pojedynczej części ciągu atrybutów (class="example") kontenera nadrzędnego.
W dokumentacji dostarczonej przez Perfmatters na temat tej nowej funkcjonalności, jesteśmy ostrzegani, aby nie próbować stosować "Lazy Load" do elementów, które znajdują się powyżej zakładki. To znaczy, co ładuje się na ekranie i pierwszą rzeczą, którą użytkownik widzi bez przewijania w dół.
Ponadto należy zauważyć, że jeśli zauważysz, że coś jest wizualnie uszkodzone, upewnij się, że użyłeś unikalnego ciągu na stronie, który nie jest współdzielony z innymi elementami.
Podobnie jak w przypadku wolno ładujących się obrazów, zawartość jest umieszczana wewnątrz pliku . Oznacza to, że wszystko, co ładuje się leniwie, jest nadal technicznie indeksowalne przez Google. Nie można jednak z całą pewnością stwierdzić, jak Google potraktuje elementy z Lazy Load w łańcuchu. Zalecają więc, pod względem SEO, najpierw przetestować.
Ostrzega również, aby nie próbować stosować Lazy Load do elementów zawierających obrazy, które uruchamiają "lightbox". I tak jest, udało mi się zweryfikować, że natywna funkcja lightbox WordPressa przestaje działać, gdy klasa elementu, który ją implementuje, zostanie dodana do listy.
W przeciwnym razie "Lazy Elements" działa idealnie. Dzięki tej funkcji zaoszczędziłem dużo czasu na przerzedzaniu DOM z dobrymi wynikami. Mam nadzieję, że Perfmatters będzie kontynuować swój rozwój, aby ulepszyć i rozszerzyć swoje opcje.
