A DOM (Document Object Model) a HTML- és XML-dokumentumok programozási felülete, és a HTML-dokumentum ágakból és objektumokat tartalmazó csomópontokból álló szerkezetének neve.
A dokumentumobjektum-modell története az 1990-es évek végén a Netscape Navigator és a Microsoft Internet Explorer között zajló úgynevezett"böngészőháborúra", valamint a JavaScriptre és a JScriptre nyúlik vissza, az első olyan szkriptnyelvekre, amelyeket a webböngészők JavaScript-motorjai széles körben implementáltak.
DOM struktúra a WordPressben: fa, ágak és csomópontok
A DOM a WordPressben nem sokban különbözik bármely más webhelytől.
<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)
- Fa: Az egész oldal egy faként jelenik meg, egy gyökércsomóponttal
(<html>)és annak gyermekelemeivel. - Ágak: A
<div>,<header>,<footer>stb.elemek mindegyike a fa egy-egy ágát képviseli. - Csomópontok: Minden HTML-elem, mint például a
<p>,<img>vagy<a>,csomópontok, amelyek ágakról lógnak le. Ezek a csomópontok lehetnek belső (más csomópontokat tartalmazó) vagy külső (a fa "levelei", amelyeknek nincsenek más gyermekei).
Így az ágak sűrűsége az azt alkotó elemek típusától és számától függ. Például egy összetett navigációs menü a WordPressben a linkek és almenük száma miatt több szintű elágazást és több tucat csomópontot generálhat.
A csomópontokra úgy gondolhatsz, mint az oldal összes HTML-elemére. Minél több elem van, általában annál hosszabb ideig tart, ami magasabb teljes blokkidőt(TBT) eredményez.
Ez egy trükkös dolog lehet a WordPressben, mivel nem lehet egyszerűen eltávolítani az oldal szerkezetét alkotó DOM-elemeket. Azonban szelektíven megjeleníthetjük ezeket az elemeket, és betölthetünk egy sor objektumot a fold alatt, így csökkentve a DOM teljes méretét.
Miért kell csökkenteni a DOM méretét?
Egy terjedelmes DOM-fa többféleképpen is lassíthatja webhelye betöltési idejét, növelheti a memóriahasználatot azáltal, hogy hosszabb és lassabb stílusszámításokat okoz, valamint felesleges adatköltségeket okoz a felhasználók számára.
Ezek a különböző forgatókönyvek magukban foglalhatják az olyan csomópontok szükségtelen betöltését, amelyek nem láthatóak, amikor a felhasználó először tölti be az oldalt, a csomópontok pozíciójának és stílusának számításait folyamatosan ismétlődően, valamint a csomópontokra való túlzott számú hivatkozás tárolását, ami túlterheli a felhasználók eszközeinek memóriáját.
Az oldalbetöltési sebesség optimalizálásának rövid és hosszú távú előnyeit már ezer és egy cikkben elmagyarázták. Röviden, rövid távon elkerülheted, hogy az emberek megunva a várakozást elhagyják az oldaladat, és nagy valószínűséggel több időt fognak rajta tölteni. A betöltési sebesség a Google által a SEO pozícionálásban elismert tényezők egyike, és úgy tudom, hogy a többi keresőmotor számára is az, így hosszú távon az értékes szerves forgalom növekedni fog.
Mi okozza a DOM méretének növekedését?
A DOM végleges méretét számos tényező befolyásolja, mint például maga a sablon, a különböző pluginok, amelyeket használsz, és a tartalom típusa, amelyet hozzáadsz, mint például az összetett blokkok vagy a képek aljas "csúszkái" stb. . Továbbá a kód, amelyet például az úgynevezett "építők" generálnak.
Például 2022-ig, az év, amikor elhagytam az Elementort, mert ellenállt az optimalizálásnak, és ritka volt, hogy nem tört el valamit szinte minden frissítésnél, plusz egy pár rossz tapasztalat a technikai támogatásukkal, ez a builder egy igazi ábécé levesbe és egy rémálommá változtatta a webkódot, ezernyi
Ugyanezen év áprilisában az Elementor nagyon új és forradalmi újdonságként beépítette a Flexbox "konténert", miközben a konténer már évek óta a GenerateBlocks alapja volt.
Hogyan mérhető a DOM?
A méréshez egy még nem túl optimalizált, kicsit hosszú és különböző típusú elemeket tartalmazó posztot választottam.
Kezdjük a legismertebbel és legnépszerűbbel: PageSpeed Insights . A Google ott figyelmeztetésként(narancssárga színnel) jelzi, ha a body elemnek több mint 800 csomópontja van, és hibajelzésként(piros színnel), ha a body elemnek több mint 1400 csomópontja van, és egy üzenetet ad a következő ajánlással:"Kerülje a túlzott DOM-méretet".
Az egyes oldalak tartalmától és szerkezetétől függően, amelyeket elemez, több vagy kevesebb támpontot talál arra vonatkozóan, hogy mely elemeket támadhatja meg. Előnye, hogy általában egy képet mutat, amely a kérdéses elemre mutat.
Még egyszer szeretném emlékeztetni Önöket, hogy ezek a figyelmeztetések csak ajánlások, és nem szabad pánikba esni, vagy megszállottá válni ezektől a mérőszámoktól. Vannak olyan oldalak, amelyek jó felhasználói élményt és jó érzékelhető sebességet kínálnak alacsony PageSpeed pontszámok mellett.
A GTmetrix segítségével általában ugyanazokat az eredményeket kapjuk a DOM-on.
Azonban itt a kérések "vízesés" grafikonja nagyon hasznos, hogy egy pillantással megvizsgálja az összes elemet típus és betöltési idő szerint rendezve.
De a legegyszerűbb és leggyorsabb módja bármelyik böngészőn keresztül. Nyisd meg az elemzendő oldalt, majd jobb klikk / "inspect" és a "Network" fülön egy sokkal részletesebb vízesést találsz, mert az oldal görgetésével kiegészítheted, és az összes benne lévő fájl hozzáadódik. Ezután súly, típus, idő stb. szerint rendezheti őket.
Az ablak alatt található az eredmények összefoglalója. Balra a kérések száma. Jobbra kékkel a DOMContentLoaded esemény ideje, pirossal pedig az adott oldal betöltési ideje.
Csökkentse a DOM méretét a Perfmatters "Lazy Elements" segítségével.
A Perfmatters, az a nélkülözhetetlen plugin, amelyet soha nem fáradok bele az ajánlásba, a 2024. augusztus 28-i 2.3.3-as verziójában hozzáadta a Lazy Elements nevű opciót, amely, bár még mindig béta állapotban van, nagyon jól működik a DOM könnyítésének megkönnyítésére.
Ez a funkció lehetővé teszi a rosszul elnevezett"Lazy Load" hozzáadását bizonyos elemekhez és azok leszármazottaihoz (gyermekeihez) a szülő konténer attribútumsorozatának (class="example") bármelyik részének hozzáadásával.
A Perfmatters által erről az új funkcióról biztosított dokumentációban figyelmeztetnek minket, hogy ne próbáljuk meg a "Lazy Load"-ot alkalmazni a hajtás feletti elemekre. Vagyis ami a képernyőn betöltődik, és az első dolog, amit a felhasználó lát, anélkül, hogy lefelé görgetne.
Megjegyezzük továbbá, hogy ha úgy látja, hogy valami vizuálisan törött, győződjön meg róla, hogy az oldalon olyan egyedi karakterláncot használt, amely nem közös más elemekkel.
A lassan betöltődő képekhez hasonlóan a tartalom egy . Ez azt jelenti, hogy bármi, ami lassan töltődik be, technikailag még mindig feltérképezhető és indexelhető a Google által. Azt azonban nem tudják biztosan megmondani, hogy a Google hogyan fogja kezelni a Lazy Load elemeket egy karakterláncban. Ezért SEO szempontból azt javasolják, hogy először teszteljük.
Arra is figyelmeztet, hogy ne próbálja meg alkalmazni a Lazy Load-ot olyan képeket tartalmazó elemekre, amelyek "lightboxot" indítanak. És így is van, sikerült meggyőződnöm arról, hogy a WordPress natív lightbox funkciója leáll, amikor az azt megvalósító elem osztálya hozzáadódik a listához.
Egyébként a "Lazy Elements" tökéletesen működik. Ennek a funkciónak köszönhetően sok időt takarítottam meg a DOM ritkításával, jó eredménnyel. Remélem, hogy a Perfmatters folytatja a fejlesztést, hogy javítsa és bővítse a lehetőségeit.
