DOM (Document Object Model) er et programmeringsgrensesnitt for HTML- og XML-dokumenter og navnet på strukturen i et HTML-dokument, som består av grener og noder som inneholder objekter.
Document Object Model har en historie som går tilbake til den såkalte"nettleserkrigen" på slutten av 1990-tallet mellom Netscape Navigator og Microsoft Internet Explorer, samt JavaScript og JScript, de første skriptspråkene som ble implementert i JavaScript-motorene i nettlesere.
DOM-struktur i WordPress: tre, grener og noder
DOM i WordPress er ikke veldig forskjellig fra andre nettsteder.
<html> <--Tre (rotnode)
│
├── <head> <-- Gren
│ ├── <title> <-- Knutepunkt (blad)
│ └── <meta> <-- Knutepunkt (blad)
│
└── <body> <-- Gren
├── <header> <-- Gren
│ └── <h1> <-- Knutepunkt (blad)
│
├── <div> <-- Gren
│ ├── <p> <-- Knutepunkt (internt)
│ └── <img> <-- Knutepunkt (blad)
│
└── <footer> <-- Gren
└── <a> <-- Knutepunkt (blad)
- Tre: Hele siden er representert som et tre med en rotnode
(<html>)og underordnede elementer. - Grener: Hvert element i en
<div>, <header>, <footer>osv. representerer en gren av treet. - Noder: Alle HTML-elementer, for eksempel
<p>,<img>eller<a>, er noder som henger fra grener. Disse nodene kan være interne (inneholde andre noder) eller eksterne (treets "blader" som ikke har noen andre barn).
Tettheten av forgreningene vil dermed avhenge av typen og antallet elementer som inngår i den. For eksempel kan en kompleks navigasjonsmeny i WordPress generere flere nivåer av forgreninger og dusinvis av noder på grunn av antall lenker og undermenyer.
Du kan tenke på noder som alle HTML-elementene på en side. Jo flere elementer du har, jo lengre tid tar det vanligvis, noe som fører til en høyere Total Block Time(TBT).
Dette kan være vanskelig å optimalisere i WordPress, ettersom du ikke bare kan fjerne DOM-elementene som utgjør strukturen på en side. Vi kan imidlertid selektivt vise disse elementene og laste inn en rekke objekter under folden, og dermed redusere den totale størrelsen på DOM-en.
Hvorfor redusere størrelsen på DOM?
Et stort DOM-tre kan redusere nettstedets innlastingstid på flere måter, øke minneforbruket ved å forårsake lengre og tregere stilberegninger, samt påføre brukerne unødvendige datakostnader.
Disse ulike scenariene kan omfatte unødvendig innlasting av noder som ikke er synlige når brukeren først laster inn siden, repetisjon av nodeposisjon og stilberegninger på konstant basis, og lagring av et for stort antall referanser til noder som overbelaster minnet på brukernes enheter.
De kortsiktige og langsiktige fordelene ved å optimalisere innlastingshastigheten har allerede blitt forklart i tusen og én artikkel. Kort sagt, på kort sikt unngår du at folk forlater siden din fordi de er lei av å vente, og mest sannsynlig vil de bruke mer tid på den og besøke flere sider, noe som reduserer avvisningsfrekvensen. Innlastingshastigheten er en av faktorene som er anerkjent av Google i SEO-posisjonering, og jeg forstår at det også er for resten av søkemotorene, så på lang sikt vil den dyrebare organiske trafikken øke.
Hva får DOM til å øke i størrelse?
Den endelige størrelsen på DOM-en påvirkes av mange faktorer, for eksempel selve malen, hva de forskjellige pluginene du bruker legger til og hvilken type innhold du legger til, for eksempel komplekse blokker eller de skumle "glidebryterne" med bilder osv. Også koden som genereres av visse "byggere".
For eksempel, frem til 2022, året da jeg forlot Elementor fordi det motsto optimalisering og det var sjelden at det ikke ødela noe i nesten hver oppdatering, pluss et par dårlige erfaringer med deres tekniske support, gjorde denne byggherren nettkoden til en ekte alfabet suppe og et mareritt med tusenvis av
I april samme år innlemmet Elementor Flexbox "Container" som en helt ny og revolusjonerende nyhet, mens containeren allerede hadde vært grunnlaget for GenerateBlocks i årevis.
Hvordan måler man DOM?
Til målingen har jeg valgt et innlegg som ikke er veldig optimalisert ennå, litt langt og med forskjellige typer elementer.
La oss begynne med den mest kjente og mest populære: PageSpeed Insights . Google markerer det som en advarsel (i oransje) når body-elementet har mer enn 800 noder og som en feilmelding (i rødt) når body-elementet har mer enn 1400 noder og en melding med denne anbefalingen:"Unngå overdreven DOM-størrelse".
Avhengig av innholdet og strukturen på hver side du analyserer, vil du finne mer eller mindre ledetråder til hvilke elementer du kan angripe. Fordelen er at det vanligvis vises et bilde som peker på det aktuelle elementet.
Nok en gang vil jeg minne deg på at alle disse varslene bare er anbefalinger, og at du ikke bør få panikk eller bli besatt av disse beregningene. Det finnes sider som gir en god brukeropplevelse og en god opplevd hastighet med lave PageSpeed-poengsummer.
Med GTmetrix vil vi generelt få de samme resultatene på DOM.
Her er imidlertid "fossefall"-grafen hans over forespørsler svært nyttig for å få et overblikk over alle elementer sortert etter type og etter hvor lang tid det tar å laste dem inn.
Andre lignende alternativer er Pingdom eller isitwp.
Men den enkleste og raskeste måten er gjennom hvilken som helst nettleser. Åpne siden som skal analyseres og høyreklikk / "inspiser", og i fanen "Nettverk" finner du et mye mer detaljert vannfall fordi du kan fullføre det ved å bla på siden, og alle forespørslene blir lagt til i listen. Du kan deretter sortere dem etter vekt, type, tid osv.
Under dette vinduet finner du en oppsummering av resultatene. Til venstre, antall forespørsler. Til høyre, i blått, DOMContentLoaded-hendelsestidspunktet og i rødt lastetiden for den aktuelle siden.
Reduser DOM-størrelsen med Perfmatters' "Lazy Elements".
Perfmatters, det essensielle pluginet som jeg aldri blir lei av å anbefale, la i sin versjon 2.3.3 av 28. august 2024 til et alternativ som heter Lazy Elements som, selv om det fremdeles er i Beta, fungerer veldig bra for å lette oppgaven med å lette DOM.
Denne funksjonen gjør det mulig å legge til den feilaktige "LazyLoad" til spesifikke elementer og deres etterkommere (barn) ved å legge til en hvilken som helst del av en attributtstreng (class="example") i en overordnet container.
Du kan også legge til perfmatters-lazy-element-klassen i en bestemt container i malen eller sidebyggeren du bruker.
I dokumentasjonen fra Perfmatters om denne nye funksjonaliteten advares vi mot å prøve å bruke "Lazy Load" på elementer som ligger over folden. Det vil si det som lastes inn på skjermen og det første brukeren ser uten å rulle ned.
Det påpekes videre at hvis du ser at noe er visuelt ødelagt, må du sørge for at du har brukt en unik streng på siden som ikke deles med andre elementer.
Som med bilder som laster sakte, er innholdet plassert inne i en . Dette betyr at alt som lastes inn tregt, fortsatt teknisk sett kan gjennomsøkes og indekseres av Google. De kan imidlertid ikke si med sikkerhet hvordan Google vil behandle elementer med Lazy Load i en streng. Så de anbefaler, når det gjelder SEO, å teste først.
Den advarer også mot å prøve å bruke Lazy Load på elementer som inneholder bilder som starter en "lightbox". Og slik er det, jeg har vært i stand til å verifisere at den opprinnelige WordPress lightbox-funksjonen slutter å fungere når klassen til et element som implementerer den, legges til i listen.
Ellers fungerer "Lazy Elements" perfekt. Takket være denne funksjonen har jeg spart mye tid på å tynne ut DOM-en med gode resultater. Jeg håper Perfmatters vil fortsette utviklingen for å forbedre og utvide alternativene.
