DOM (Document Object Model) on HTML- ja XML-dokumenttien ohjelmointirajapinta ja nimi HTML-dokumentin rakenteelle, joka koostuu haaroista ja objekteja sisältävistä solmuista.
Dokumenttiobjektimallin historia juontaa juurensa 1990-luvun lopun niin sanottuun"selainsotaan" Netscape Navigatorin ja Microsoft Internet Explorerin välillä sekä JavaScriptin ja JScriptin, ensimmäisten skriptikielten, jotka toteutettiin laajalti verkkoselaimien JavaScript-moottoreissa.
DOM-rakenne WordPressissä: puu, oksat ja solmut
WordPressin DOM ei eroa kovin paljon muista verkkosivustoista.
<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)
- Puu: Koko sivu esitetään puuna, jossa on juurisolmu
(<html>)ja sen lapsielementit. - Oksat: Jokainen
<div>-,<header>-,<footer>-jne.elementti edustaa puun haaraa. - Solmut: Kaikki HTML-elementit, kuten
<p>,<img>tai<a>,ovat solmuja, jotka riippuvat haaroista. Nämä solmut voivat olla sisäisiä (sisältävät muita solmuja) tai ulkoisia (puun "lehdet", joilla ei ole muita lapsia).
Näin ollen haarojen tiheys riippuu sen muodostavien elementtien tyypistä ja lukumäärästä. Esimerkiksi WordPressin monimutkainen navigointivalikko voi luoda useita tasoja haaroja ja kymmeniä solmuja linkkien ja alivalikoiden määrän vuoksi.
Voit ajatella, että solmut ovat kaikki sivun HTML-elementit. Mitä enemmän elementtejä on, sitä kauemmin se yleensä kestää, mikä johtaa suurempaan kokonaislohkoaikaan(Total Block Time, TBT).
Tämän optimointi WordPressissä voi olla hankalaa, sillä et voi yksinkertaisesti poistaa sivun rakenteen muodostavia DOM-elementtejä. Voimme kuitenkin näyttää nämä elementit valikoivasti ja ladata merkkijonon objekteja taiton alapuolelle, mikä pienentää DOM:n kokonaiskokoa.
Miksi pienentää DOM:n kokoa?
Runsas DOM-puu voi hidastaa sivustosi latausaikaa monin tavoin, lisätä muistin käyttöä aiheuttamalla pidempiä ja hitaampia tyylin laskutoimituksia sekä kuluttaa käyttäjille tarpeettomia datakustannuksia.
Näihin erilaisiin skenaarioihin voi kuulua sellaisten solmujen tarpeeton lataaminen, jotka eivät ole näkyvissä, kun käyttäjä lataa sivun ensimmäisen kerran, solmujen sijainnin ja tyylin laskelmien jatkuva toistaminen ja liian monen solmuviittauksen tallentaminen, mikä kuormittaa käyttäjien laitteiden muistia.
Sivujen latausnopeuden optimoinnin lyhyen ja pitkän aikavälin hyödyt on jo selitetty tuhannessa ja yhdessä artikkelissa. Lyhyesti sanottuna lyhyellä aikavälillä vältät sen, että ihmiset lähtevät sivustoltasi odottamaan kyllästyneinä, ja todennäköisesti he viettävät sivustollasi enemmän aikaa. Latausnopeus on yksi tekijä, jonka Google tunnustaa hakukoneoptimoinnissa, ja käsittääkseni se on sitä myös muiden hakukoneiden kohdalla, joten pitkällä aikavälillä arvokas orgaaninen liikenne lisääntyy.
Mikä aiheuttaa DOM:n koon kasvamisen?
DOM:n lopulliseen kokoon vaikuttavat monet tekijät, kuten itse malli, käyttämäsi eri lisäosat ja lisäämäsi sisällön tyyppi, kuten monimutkaiset lohkot tai kuvien häijyt "liukusäätimet" jne. . Myös esimerkiksi ns. rakentajien tuottama koodi.
Esimerkiksi vuoteen 2022 asti, jolloin hylkäsin Elementorin, koska se vastusti optimointia ja oli harvinaista, että se ei rikkonut jotakin lähes jokaisessa päivityksessä, sekä pari huonoa kokemusta heidän teknisestä tuestaan, tämä rakentaja muutti web-koodin todelliseksi aakkoskeitoksi ja painajaiseksi, jossa oli tuhansittain
Saman vuoden huhtikuussa Elementor sisällytti Flexbox-"kontin" hyvin uutena ja vallankumouksellisena uutuutena, vaikka kontti oli jo vuosia ollut GenerateBlocksin perusta.
Miten DOM mitataan?
Mittausta varten olen valinnut postauksen, jota ei ole vielä optimoitu, joka on hieman pitkä ja jossa on erityyppisiä elementtejä.
Aloitetaan tunnetuimmasta ja suosituimmasta: PageSpeed Insights . Google merkitsee sinne varoituksen(oranssilla), kun body-elementissä on yli 800 solmua, ja virhevaroituksen(punaisella), kun body-elementissä on yli 1 400 solmua, ja viestin, jossa on tämä suositus:"Vältä liiallista DOM-kokoa".
Kunkin analysoimasi sivun sisällöstä ja rakenteesta riippuen löydät enemmän tai vähemmän vihjeitä siitä, mihin elementteihin voit hyökätä. Etuna on, että siinä näkyy yleensä kuva, joka osoittaa kyseiseen elementtiin.
Haluan vielä kerran muistuttaa, että kaikki nämä hälytykset ovat vain suosituksia, eikä sinun pitäisi panikoida tai ryhtyä pakkomielteiseksi näiden mittareiden suhteen. On olemassa sivuja, jotka tarjoavat hyvän käyttökokemuksen ja hyvän nopeuden, mutta joiden PageSpeed-pisteet ovat alhaiset.
GTmetrixin avulla saamme yleensä samat tulokset DOM:ssa.
Tässä yhteydessä hänen pyyntöjen "vesiputous"-kaavionsa on kuitenkin erittäin hyödyllinen, sillä sen avulla voidaan tarkastella yhdellä silmäyksellä kaikkia kohteita lajiteltuna tyypin ja latausaikojen mukaan.
Helpoin ja nopein tapa on kuitenkin käyttää mitä tahansa selainta. Avaa analysoitava sivu ja klikkaa hiiren oikealla painikkeella / "inspect" ja "Network" -välilehdeltä löydät paljon yksityiskohtaisemman vesiputouksen , koska voit täydentää sitä vierittämällä sivua ja kaikki sen sisältämät tiedostot lisätään. Voit sitten lajitella ne painon, tyypin, ajan jne. mukaan.
Tämän ikkunan alla on yhteenveto tuloksista. Vasemmalla on pyyntöjen määrä. Oikealla sinisellä DOMContentLoaded-tapahtuman aika ja punaisella kyseisen sivun latausaika.
Vähennä DOM-kokoa Perfmattersin "Lazy Elements" -ominaisuudella.
Perfmatters, tämä olennainen lisäosa, jota en koskaan kyllästy suosittelemaan, on lisännyt 28. elokuuta 2024 julkaistuun versioon 2.3.3 vaihtoehdon nimeltä Lazy Elements, joka, vaikka se on vielä beta-versiossa, toimii todella hyvin DOM:n keventämisen helpottamiseksi.
Tämä toiminto mahdollistaa väärin nimetyn"Lazy Load" -toiminnon lisäämisen tiettyihin elementteihin ja niiden jälkeläisiin (lapsiin) lisäämällä minkä tahansa yksittäisen osan vanhemman säiliön attribuuttijonosta (class="example").
Perfmattersin toimittamassa tätä uutta toimintoa koskevassa dokumentaatiossa meitä varoitetaan käyttämästä "Lazy Load" -ominaisuutta elementteihin, jotka ovat taiton yläpuolella. Toisin sanoen se, mikä latautuu näytölle ja on ensimmäinen asia, jonka käyttäjä näkee ilman alaspäin vierittämistä.
Lisäksi huomautetaan, että jos näet, että jokin on visuaalisesti rikki, varmista, että olet käyttänyt sivulla yksilöllistä merkkijonoa, jota ei ole jaettu muiden elementtien kanssa.
Kuten hitaasti latautuvien kuvien kohdalla, sisältö on sijoitettu sisälle . Tämä tarkoittaa sitä, että kaikki, mikä latautuu hitaasti, on silti teknisesti Googlen indeksoitavissa ja indeksoitavissa. He eivät kuitenkaan voi sanoa varmasti, miten Google kohtelee elementtejä, joissa on Lazy Load -merkkijono. Joten he suosittelevat SEO:n kannalta testaamaan ensin.
Se varoittaa myös käyttämästä Lazy Load -toimintoa elementteihin, jotka sisältävät kuvia, jotka käynnistävät "valolaatikon". Ja niinhän se on, olen pystynyt todentamaan, että WordPressin natiivi valolaatikkotoiminto lakkaa toimimasta, kun sen toteuttavan elementin luokka lisätään luetteloon.
Muuten "Lazy Elements" toimii täydellisesti. Tämän ominaisuuden ansiosta olen säästänyt paljon aikaa DOM:n harventamisessa hyvillä tuloksilla. Toivon, että Perfmatters jatkaa kehitystyötään parantaakseen ja laajentaakseen sen vaihtoehtoja.
