Vältida liigset DOM-i suurust WordPressis

DOM struktuur WordPressis: puu, oksad ja sõlmed

DOM (Document Object Model) on HTML- ja XML-dokumentide programmeerimisliides ning HTML-dokumendi struktuuri nimetus, mis koosneb harudest ja sõlmedest, mis sisaldavad objekte.

Dokumendiobjektimudeli ajalugu ulatub tagasi 1990ndate aastate lõpu nn"brauserisõdadesse" Netscape Navigatori ja Microsoft Internet Exploreri vahel, samuti JavaScript ja JScript, mis olid esimesed skriptimiskeeled, mida rakendati laialdaselt veebibrauserite JavaScript-mootorites.

DOM struktuur WordPressis: puu, oksad ja sõlmed

DOM WordPressis ei erine väga palju teistest veebilehtedest.

<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: Kogu lehekülg kujutatakse puu kujul, millel on juursõlm(<html>) ja selle alamelemendid.
Harud: Iga element <div>, <header>, <footer> jne. sees esindab puu haru.
Sõlmed: Kõik HTML-elemendid, näiteks <p>, <img> või <a>, on sõlmed, mis ripuvad harude küljes. Need sõlmed võivad olla sisemised (sisaldavad teisi sõlmi) või välised (puu "lehed", millel ei ole teisi lapsi).

Seega sõltub harude tihedus selle moodustavate elementide tüübist ja arvust. Näiteks WordPressi keerukas navigatsioonimenüü võib linkide ja alammenüüde arvu tõttu tekitada mitu tasandit harusid ja kümneid sõlmi.

Sa võid mõelda sõlmedest kui kõigist HTML-elementidest lehel. Mida rohkem on elemente, seda kauem võtab see tavaliselt aega, mis viib suurema kogublokeerimisaja(Total Block Time, TBT) saavutamiseni.

See võib olla keeruline asi WordPressi optimeerimisel, sest sa ei saa lihtsalt eemaldada DOM-elemente, mis moodustavad lehe struktuuri. Küll aga saame neid elemente valikuliselt kuvada ja laadida allapoole objekte, vähendades nii DOMi üldist suurust.

Miks vähendada DOM-i suurust?

Mahukas DOM-puu võib aeglustada teie saidi laadimisaega mitmel viisil, suurendades mälukasutust, põhjustades pikemaid ja aeglasemaid stiiliarvutusi, ning kulutades kasutajatele tarbetuid andmekulusid.

Need erinevad stsenaariumid võivad hõlmata selliste sõlmede tarbetut laadimist, mis ei ole nähtavad, kui kasutaja esimest korda lehte laeb, sõlmede asukoha ja stiili arvutuste pidevat kordamist ning liigse hulga viidete salvestamist sõlmedele, mis koormavad kasutajate seadmete mälu üle.

Lühi- ja pikaajalist kasu lehekülje laadimiskiiruse optimeerimisest on juba tuhandes ja ühes artiklis selgitatud. Lühidalt öeldes väldite lühiajaliselt, et inimesed ei jäta teie lehte ootamisest tüdinult maha ja tõenäoliselt veedavad nad seal rohkem aega ning külastavad rohkem lehekülgi, vähendades põrgatuste arvu. Laadimiskiirus on üks Google'i poolt tunnustatud teguritest SEO-positsioneerimisel ja ma saan aru, et see on ka teiste otsingumootorite jaoks, nii et pikas perspektiivis suureneb väärtuslik orgaaniline liiklus.

Mis põhjustab DOMi suurenemist?

DOM-i lõplikku suurust mõjutavad paljud tegurid, nagu näiteks mall ise, mida erinevad kasutatavad pluginad lisavad ja millise sisu lisate, näiteks keerulised plokid või piltide räpased "liugurid" jne . Samuti teatud "ehitajate" poolt genereeritud kood.

Näiteks kuni 2022. aastani, mil ma loobusin Elementorist, sest see vastutas optimeerimisele ja harva juhtus, et see ei rikkunud midagi peaaegu igas uuenduses, pluss paar halba kogemust nende tehnilise toega, muutis see ehitaja veebikoodi tõeliseks tähestikusupiks ja õudusunenäoks tuhandete

. Ma ei tea, kas see on tänaseks paranenud.

Sama aasta aprillis lisas Elementor Flexboxi "konteineri" kui väga uue ja revolutsioonilise uuenduse, kui konteiner oli juba aastaid olnud GenerateBlocksi aluseks.

Kuidas mõõta DOMi?

Mõõtmiseks olen valinud postituse, mis ei ole veel väga optimeeritud, veidi pikk ja eri tüüpi elementidega.

Alustame kõige tuntumast ja populaarsemast: PageSpeed Insights . Google märgib seal hoiatusena(oranži värviga), kui body elemendis on üle 800 sõlme, ja veateatena(punase värviga), kui body elemendis on üle 1400 sõlme, ning sõnumi selle soovitusega:"Vältida liigset DOM-i suurust".

Vältida liigset DOM-i suurust WordPressis 0

Sõltuvalt iga analüüsitava lehe sisust ja struktuurist leiate rohkem või vähem vihjeid selle kohta, milliseid elemente saate rünnata. Eeliseks on see, et tavaliselt kuvatakse pilt, mis osutab kõnealusele elemendile.

Tahaksin teile veel kord meelde tuletada, et kõik need hoiatused on ainult soovitused ja et te ei tohiks paanikasse sattuda ega muutuda nende näitajate suhtes kinnisideeks. On lehekülgi, mis pakuvad head kasutajakogemust ja head tajutavat kiirust, kuid mille PageSpeed'i skoor on madal.

GTmetrixiga saame üldiselt samu tulemusi DOMi kohta.

Vältida liigset DOM-i suurust WordPressis 1

Kuid siin on tema taotluste "veejooksu" graafik väga kasulik, et kontrollida korraga kõiki elemente, mis on sorteeritud tüübi ja laadimisaja järgi.

Vältida liigset DOM-i suurust WordPressis 2

Muud sarnased võimalused on Pingdom või isitwp.

Kuid kõige lihtsam ja kiirem viis on ükskõik millise brauseri kaudu. Avage analüüsitav lehekülg ja tehke paremklõps / "inspect" ning vahekaardil "Network" leiate palju üksikasjalikuma veejuhtumi , sest saate seda täiendada lehte kerides ja kõik taotlused lisatakse loetellu. Seejärel saate neid sorteerida kaalu, tüübi, aja jne järgi.

Vältida liigset DOM-i suurust WordPressis 3

Selle akna all on tulemuste kokkuvõte. Vasakul on taotluste arv. Paremal, sinise värviga, DOMContentLoaded sündmuse aeg ja punase värviga selle lehe laadimisaeg.

Vähendage DOM-i suurust Perfmatters'i "Lazy Elements" abil.

Perfmatters, see oluline plugin, mida ma ei väsi kunagi soovitamast, lisas oma 28. augusti 2024. aasta versioonis 2.3.3 võimaluse nimega Lazy Elements, mis, kuigi see on veel beetas, töötab tõesti hästi, et hõlbustada DOM-i kergendamist.

Vältida liigset DOM-i suurust WordPressis 4

See funktsioon võimaldab lisada valesti nimetatud "LazyLoad" konkreetsetele elementidele ja nende järeltulijatele (lastele), lisades ükskõik millise osa vanemkonteineri atribuudi stringist (class="example").

Võite lisada klassi perfmatters-lazy-element ka konkreetsele konteinerile kasutatavas malli või leheküljeehitajas.

Perfmatters 'i poolt selle uue funktsionaalsuse kohta esitatud dokumentatsioonis hoiatatakse meid, et me ei püüaks rakendada "Lazy Load" elementidele, mis on ülevalpool voldi. See tähendab, et see, mis laaditakse ekraanile ja mida kasutaja näeb esimesena ilma allapoole kerimata.

Lisaks märgitakse, et kui näete, et midagi on visuaalselt katki, veenduge, et olete kasutanud lehel unikaalset stringi, mida ei jagata teiste elementidega.

Nagu aeglaselt laadivate piltide puhul, paigutatakse sisu sisse . See tähendab, et kõik, mis laadib aeglaselt, on tehniliselt ikkagi Google'i poolt indekseeritav ja indekseeritav. Siiski ei saa nad kindlalt öelda, kuidas Google suhtub elementidesse, millel on Lazy Load stringis. Seega soovitavad nad SEO mõttes kõigepealt testida.

Samuti hoiatab see, et te ei püüaks rakendada Lazy Load'i elementidele, mis sisaldavad pilte, mis käivitavad "valguskasti". Ja nii see ongi, ma olen suutnud kontrollida, et WordPressi emakeelne lightbox funktsioon lõpetab töö, kui seda rakendava elemendi klass lisatakse nimekirja.

Lühidalt öeldes, kui me ei ole ettevaatlikud ja testime kannatlikult iga elementi ükshaaval, on oht, et CLS käivitub.

Muidu töötab "Lazy Elements" suurepäraselt. Tänu sellele funktsioonile olen säästnud palju aega DOMi hõrendamisel heade tulemustega. Ma loodan, et Perfmatters jätkab oma arengut, et parandada ja laiendada oma võimalusi.