Het DOM (Document Object Model) is een programmeerinterface voor HTML- en XML-documenten en de naam die gegeven is aan de structuur van een HTML-document, bestaande uit takken en knooppunten die objecten bevatten.
De geschiedenis van het Document Object Model gaat terug tot de zogenaamde"browseroorlogen" van de late jaren 1990 tussen Netscape Navigator en Microsoft Internet Explorer, evenals JavaScript en JScript, de eerste scripttalen die op grote schaal werden geïmplementeerd in de JavaScript-engines van webbrowsers.
DOM-structuur in WordPress: boom, takken en knooppunten
De DOM in WordPress verschilt niet veel van andere websites.
<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)
- Boom: de hele pagina wordt weergegeven als een boom met een wortelknooppunt
(<html>)en zijn kindelementen. - Takken: Elk element binnen een
<div>,<header>,<footer>,enz. vertegenwoordigt een tak van de boom. - Knooppunten: Alle HTML-elementen, zoals
<p>,<img>of<a>,zijn knooppunten die aan takken hangen. Deze knooppunten kunnen intern zijn (andere knooppunten bevatten) of extern (de "bladeren" van de boom die geen andere kinderen hebben).
De dichtheid van de takken hangt dus af van het type en het aantal elementen waaruit het bestaat. Een complex navigatiemenu in WordPress kan bijvoorbeeld meerdere vertakkingsniveaus en tientallen knooppunten genereren vanwege het aantal links en submenu's.
Je kunt knooppunten zien als alle HTML-elementen op een pagina. Hoe meer elementen je hebt, hoe langer het meestal duurt, wat leidt tot een hogere Total Block Time(TBT).
Dit kan lastig zijn om te optimaliseren in WordPress, omdat je de DOM-elementen die de structuur van een pagina vormen niet zomaar kunt verwijderen. We kunnen deze elementen echter wel selectief weergeven en een reeks objecten onder de vouw laden, waardoor de totale grootte van het DOM wordt verkleind.
Waarom de grootte van de DOM verkleinen?
Een omvangrijke DOM-boom kan de laadtijd van je site op verschillende manieren vertragen, het geheugengebruik verhogen door langere en langzamere stijlberekeningen te veroorzaken en onnodige gegevenskosten voor gebruikers veroorzaken.
Deze verschillende scenario's kunnen bestaan uit het onnodig laden van knooppunten die niet zichtbaar zijn wanneer de gebruiker de pagina voor het eerst laadt, het voortdurend herhalen van berekeningen van knooppuntposities en -stijlen en het opslaan van een buitensporig aantal verwijzingen naar knooppunten die het geheugen van de apparaten van gebruikers overbelasten.
De korte- en langetermijnvoordelen van het optimaliseren van de laadsnelheid van pagina's zijn al in duizend-en-één artikelen uitgelegd. In het kort: op de korte termijn voorkom je dat mensen verveeld van het wachten je site verlaten en waarschijnlijk zullen ze er meer tijd op doorbrengen. De laadsnelheid is een van de factoren die door Google wordt erkend in de SEO-positionering en ik begrijp dat dit ook geldt voor de rest van de zoekmachines, dus op de lange termijn zal het kostbare organische verkeer toenemen.
Waardoor wordt de DOM groter?
De uiteindelijke grootte van de DOM wordt beïnvloed door veel factoren, zoals het sjabloon zelf, wat de verschillende plugins die u gebruikt toevoegen en het type inhoud dat u toevoegt, zoals complexe blokken of de snode "sliders" van afbeeldingen, enz. Ook de code die bijvoorbeeld wordt gegenereerd door de zogenaamde "Builders".
Bijvoorbeeld, tot 2022, het jaar waarin ik Elementor verliet omdat het zich verzette tegen optimalisatie en het zeldzaam was dat het niet iets brak in bijna elke update, plus een paar slechte ervaringen met hun technische ondersteuning, veranderde deze bouwer de webcode in een echte alfabetsoep en een nachtmerrie met duizenden
In april van datzelfde jaar verwerkte Elementor de Flexbox "Container" als een zeer nieuwe en revolutionaire nieuwigheid, terwijl de container al jaren de basis was van GenerateBlocks.
Hoe meet je DOM?
Voor de meting heb ik een post gekozen die nog niet erg geoptimaliseerd is, een beetje lang en met verschillende soorten elementen.
Laten we beginnen met de bekendste en populairste: PageSpeed Insights . Google markeert daar als een waarschuwing(in oranje) wanneer het body-element meer dan 800 nodes heeft en als een foutmelding(in rood) wanneer het body-element meer dan 1400 nodes heeft en een bericht met deze aanbeveling:"Vermijd overmatige DOM-grootte".
Afhankelijk van de inhoud en structuur van elke pagina die je analyseert, vind je meer of minder aanwijzingen over welke elementen je kunt aanvallen. Het voordeel is dat er meestal een afbeelding wordt getoond die naar het element in kwestie wijst.
Ik wil je er nogmaals aan herinneren dat al deze waarschuwingen slechts aanbevelingen zijn en dat je niet in paniek moet raken of geobsedeerd moet raken door deze statistieken. Er zijn pagina's die een goede gebruikerservaring en een goede waargenomen snelheid bieden met een lage PageSpeed-score.
Met GTmetrix krijgen we over het algemeen dezelfde resultaten op de DOM.
Hier is zijn "waterval"-grafiek van aanvragen echter erg handig om in één oogopslag alle items te inspecteren, gesorteerd op type en op de tijd die ze nodig hebben om te laden.
Maar de makkelijkste en snelste manier is via een browser. Open de pagina die je wilt analyseren en klik met de rechtermuisknop / "inspecteren" en in het tabblad "Netwerk" vind je een veel gedetailleerdere waterval omdat je deze kunt aanvullen door de pagina te scrollen en alle bestanden die deze bevat worden toegevoegd. Je kunt ze dan sorteren op gewicht, type, tijd, enz.
Onder dit venster vind je een samenvatting van de resultaten. Links het aantal aanvragen. Rechts, in het blauw, de tijd van de DOMContentLoaded gebeurtenis en in het rood de laadtijd van die pagina.
Verklein de DOM-grootte met de "Lazy Elements" van Perfmatters.
Perfmatters, die essentiële plugin die ik nooit moe word om aan te bevelen, heeft in zijn versie 2.3.3 van 28 augustus 2024 een optie genaamd Lazy Elements toegevoegd die, hoewel het nog in bèta is, heel goed werkt om de taak van het verlichten van het DOM te vergemakkelijken.
Deze functie maakt het mogelijk om de verkeerde naam"Lazy Load" toe te voegen aan specifieke elementen en hun afstammelingen (kinderen) door een willekeurig deel van een attribuutstring (class="voorbeeld") van een oudercontainer toe te voegen.
In de documentatie van Perfmatters over deze nieuwe functionaliteit worden we gewaarschuwd om "Lazy Load" niet toe te passen op elementen die zich boven de vouw bevinden. Dat wil zeggen, wat op het scherm wordt geladen en het eerste is wat de gebruiker ziet zonder naar beneden te scrollen.
Verder wordt opgemerkt dat als je ziet dat iets visueel kapot is, je ervoor moet zorgen dat je een unieke string op de pagina hebt gebruikt die niet wordt gedeeld met andere elementen.
Net als bij de langzaam ladende afbeeldingen wordt de inhoud in een . Dit betekent dat alles wat traag laadt technisch nog steeds crawlablebaar en indexeerbaar is door Google. Ze kunnen echter niet met zekerheid zeggen hoe Google elementen met Lazy Load in een string zal behandelen. Daarom raden ze aan om, met het oog op SEO, eerst te testen.
Het waarschuwt ook om Lazy Load niet toe te passen op elementen die afbeeldingen bevatten die een "lightbox" starten. En zo is het, ik heb kunnen verifiëren dat de native WordPress lightbox functie stopt met werken wanneer de klasse van een element dat het implementeert wordt toegevoegd aan de lijst.
Anders werkt "Lazy Elements" perfect. Dankzij deze functie heb ik veel tijd bespaard op het uitdunnen van de DOM met goede resultaten. Ik hoop dat Perfmatters doorgaat met de ontwikkeling om de opties te verbeteren en uit te breiden.
