DOM (Document Object Model) er en programmeringsgrænseflade til HTML- og XML-dokumenter og navnet på strukturen i et HTML-dokument, der består af grene og knudepunkter, som indeholder objekter.
Dokumentobjektmodellens historie går tilbage til de såkaldte"browserkrige" i slutningen af 1990'erne mellem Netscape Navigator og Microsoft Internet Explorer samt JavaScript og JScript, de første scriptingsprog, der blev bredt implementeret i JavaScript-motorerne i webbrowsere.
DOM-struktur i WordPress: træ, grene og noder
DOM'en i WordPress er ikke meget anderledes end på andre hjemmesider.
<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)
- Træ: Hele siden er repræsenteret som et træ med en rodknude
(<html>)og dens underordnede elementer. - Grene: Hvert element i en
<div>,<header>,<footer>osv. repræsenterer en gren i træet. - Knudepunkter: Alle HTML-elementer
,såsom<p>,<img>eller<a>,er knudepunkter, der hænger fra grene. Disse noder kan være interne (indeholde andre noder) eller eksterne (træets "blade", som ikke har andre børn).
Forgreningernes tæthed vil således afhænge af typen og antallet af elementer, der indgår i den. For eksempel kan en kompleks navigationsmenu i WordPress generere flere niveauer af forgreninger og dusinvis af noder på grund af antallet af links og undermenuer.
Du kan tænke på noder som alle HTML-elementerne på en side. Jo flere elementer du har, jo længere tid tager det normalt, hvilket fører til en højere Total Block Time(TBT).
Det kan være en vanskelig ting at optimere i WordPress, da man ikke bare kan fjerne de DOM-elementer, der udgør strukturen på en side. Men vi kan selektivt vise disse elementer og indlæse en række objekter under folden og dermed reducere den samlede størrelse af DOM'en.
Hvorfor reducere størrelsen på DOM'en?
Et omfangsrigt DOM-træ kan sænke din hjemmesides indlæsningstid på flere måder, øge hukommelsesforbruget ved at forårsage længere og langsommere stilberegninger samt påføre brugerne unødvendige dataomkostninger.
Disse forskellige scenarier kan omfatte unødvendig indlæsning af noder, der ikke er synlige, når brugeren først indlæser siden, gentagelse af nodeposition og stilberegninger på en konstant basis og lagring af et for stort antal referencer til noder, der overbelaster hukommelsen på brugernes enheder.
De kort- og langsigtede fordele ved at optimere sidens indlæsningshastighed er allerede blevet forklaret i tusind og én artikel. Kort sagt undgår du på kort sigt, at folk forlader dit websted, fordi de er trætte af at vente, og de vil sandsynligvis bruge mere tid på det. Indlæsningshastigheden er en af de faktorer, som Google anerkender i forbindelse med SEO-positionering, og jeg kan forstå, at det også gælder for resten af søgemaskinerne, så på lang sigt vil den dyrebare organiske trafik stige.
Hvad får DOM'en til at vokse i størrelse?
Den endelige størrelse på DOM'en påvirkes af mange faktorer som f.eks. selve skabelonen, hvad de forskellige plugins, du bruger, tilføjer, og hvilken type indhold du tilføjer som f.eks. komplekse blokke eller de forbryderiske "sliders" med billeder osv. Også den kode, der genereres af f.eks. de såkaldte "Builders".
For eksempel, indtil 2022, året hvor jeg opgav Elementor, fordi det modstod optimering, og det var sjældent, at det ikke ødelagde noget i næsten hver opdatering, plus et par dårlige oplevelser med deres tekniske support, gjorde denne builder webkoden til en ægte alfabetisk suppe og et mareridt med tusindvis af
I april samme år indarbejdede Elementor Flexbox-" containeren " som en meget ny og revolutionerende nyhed, da containeren allerede havde været grundlaget for GenerateBlocks i årevis.
Hvordan måler man DOM?
Til målingen har jeg valgt et indlæg, der ikke er særlig optimeret endnu, lidt langt og med forskellige typer af elementer.
Lad os starte med den mest kendte og populære: PageSpeed Insights . Google markerer der som en advarsel(i orange), når body-elementet har mere end 800 noder, og som en fejlmeddelelse(i rødt), når body-elementet har mere end 1.400 noder og en meddelelse med denne anbefaling:"Undgå overdreven DOM-størrelse".
Afhængigt af indholdet og strukturen på hver side, du analyserer, vil du finde flere eller færre ledetråde til, hvilke elementer du kan angribe. Fordelen er, at den som regel viser et billede, der peger på det pågældende element.
Endnu en gang vil jeg gerne minde dig om, at alle disse advarsler kun er anbefalinger, og at du ikke skal gå i panik eller blive besat af disse målinger. Der er sider, som giver en god brugeroplevelse og en god opfattet hastighed, men som har en lav PageSpeed-score.
Med GTmetrix vil vi generelt få de samme resultater på DOM'en.
Men her er hans "vandfalds"-graf over anmodninger meget nyttig til at få et overblik over alle elementer sorteret efter type og efter den tid, det tager at indlæse dem.
Men den nemmeste og hurtigste måde er gennem en hvilken som helst browser. Åbn den side, der skal analyseres, og højreklik / "inspicer", og i fanen "Netværk" finder du et meget mere detaljeret vandfald , fordi du kan udfylde det ved at rulle på siden, og alle de filer, den indeholder, bliver tilføjet. Du kan derefter sortere dem efter vægt, type, tid osv.
Under dette vindue finder du en oversigt over resultaterne. Til venstre ses antallet af anmodninger. Til højre, i blåt, DOMContentLoaded-begivenhedstiden og i rødt indlæsningstiden for den pågældende side.
Reducer DOM-størrelsen med Perfmatters' "Lazy Elements".
Perfmatters, det vigtige plugin, som jeg aldrig bliver træt af at anbefale, tilføjede i sin version 2.3.3 af 28. august 2024 en mulighed kaldet Lazy Elements, der, selvom den stadig er i Beta, fungerer rigtig godt til at lette opgaven med at lette DOM'en.
Denne funktion gør det muligt at tilføje det fejlagtige navn"Lazy Load" til specifikke elementer og deres efterkommere (børn) ved at tilføje en enkelt del af en attributstreng (class="example") i en overordnet container.
I dokumentationen fra Perfmatters om denne nye funktionalitet advares vi om ikke at forsøge at anvende "Lazy Load" på elementer, der ligger over folden. Det vil sige det, der indlæses på skærmen, og som er det første, brugeren ser uden at scrolle ned.
Det bemærkes desuden, at hvis du ser, at noget er visuelt ødelagt, skal du sørge for, at du har brugt en unik streng på siden, som ikke deles med andre elementer.
Som med billeder, der indlæses langsomt, er indholdet placeret i en . Det betyder, at alt , hvad der indlæses langsomt, stadig teknisk set kan crawles og indekseres af Google. De kan dog ikke med sikkerhed sige, hvordan Google vil behandle elementer med Lazy Load i en streng. Så de anbefaler, hvad angår SEO, at man tester først.
Den advarer også om ikke at forsøge at anvende Lazy Load på elementer, der indeholder billeder, der starter en "lightbox". Og sådan er det, jeg har været i stand til at verificere, at den oprindelige WordPress lightbox-funktion holder op med at virke, når klassen for et element, der implementerer den, føjes til listen.
Ellers fungerer "Lazy Elements" perfekt. Takket være denne funktion har jeg sparet en masse tid på at tynde ud i DOM'en med gode resultater. Jeg håber, at Perfmatters vil fortsætte sin udvikling for at forbedre og udvide sine muligheder.
