Undvik överdriven DOM-storlek i WordPress

DOM-struktur i WordPress: träd, grenar och noder

DOM (Document Object Model) är ett programmeringsgränssnitt för HTML- och XML-dokument och benämningen på strukturen i ett HTML-dokument, som består av grenar och noder som innehåller objekt.

Dokumentobjektmodellens historia går tillbaka till det så kallade"webbläsarkriget" i slutet av 1990-talet mellan Netscape Navigator och Microsoft Internet Explorer, samt JavaScript och JScript, de första skriptspråken som implementerades i stor utsträckning i JavaScript-motorerna i webbläsare.

DOM-struktur i WordPress: träd, grenar och noder

DOM i WordPress skiljer sig inte mycket från någon annan webbplats.

<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äd: Hela sidan representeras som ett träd med en rotnod(<html>) och dess underordnade element.
Grenar: Varje element i en <div>, <header>, <footer> etc. representerar en gren i trädet.
Noder: Alla HTML-element , t.ex. <p>, <img> eller <a>, är noder som hänger från grenar. Dessa noder kan vara interna (innehålla andra noder) eller externa (trädets "blad" som inte har några andra barn).

Förgreningarnas täthet beror alltså på vilken typ och hur många element som ingår i dem. Till exempel kan en komplex navigeringsmeny i WordPress generera flera nivåer av grenar och dussintals noder på grund av antalet länkar och undermenyer.

Du kan tänka på noder som alla HTML-element på en sida. Ju fler element du har, desto längre tid tar det vanligtvis, vilket leder till en högre total blocktid(TBT).

Detta kan vara en knepig sak att optimera i WordPress, eftersom du inte bara kan ta bort DOM-elementen som utgör strukturen på en sida. Vi kan dock selektivt visa dessa element och ladda en sträng med objekt under vikningen, vilket minskar den totala storleken på DOM.

Varför minska storleken på DOM?

Ett skrymmande DOM-träd kan sakta ner webbplatsens laddningstid på flera sätt, öka minnesanvändningen genom att orsaka längre och långsammare stilberäkningar samt orsaka onödiga datakostnader för användarna.

Dessa olika scenarier kan inkludera onödig laddning av noder som inte är synliga när användaren först laddar sidan, upprepning av beräkningar av nodposition och stil på en konstant basis och lagring av ett alltför stort antal referenser till noder som överbelastar minnet på användarnas enheter.

De kortsiktiga och långsiktiga fördelarna med att optimera sidans laddningshastighet har redan förklarats i tusen och en artiklar. Kort sagt, på kort sikt undviker du att människor lämnar din webbplats uttråkade av att vänta och troligen kommer de att spendera mer tid på den. Laddningshastigheten är en av de faktorer som erkänns av Google i SEO-positionering och jag förstår att det också är för resten av sökmotorerna, så på lång sikt kommer den dyrbara organiska trafiken att öka.

Vad är det som gör att DOM ökar i storlek?

Den slutliga storleken på DOM påverkas av många faktorer som själva mallen, vad de olika plugins du använder lägger till och vilken typ av innehåll du lägger till, till exempel komplexa block eller de skadliga "sliders" av bilder etc. Även koden som genereras till exempel av de så kallade "Builders".

Till exempel, fram till 2022, år då jag övergav Elementor eftersom det motstod optimering och det var sällsynt att det inte bröt något i nästan varje uppdatering, plus ett par dåliga erfarenheter med deras tekniska support, förvandlade denna byggare webbkoden till en riktig alfabetssoppa och en mardröm med tusentals

. Jag vet inte om det har förbättrats idag.

I april samma år införlivade Elementor Flexbox "Container" som en mycket ny och revolutionerande nyhet, när behållaren redan hade varit grunden för GenerateBlocks i flera år.

Hur mäter man DOM?

För mätningen har jag valt ett inlägg som inte är särskilt optimerat ännu, lite långt och med olika typer av element.

Låt oss börja med den mest kända och populära: PageSpeed Insights . Google markerar där som en varning(i orange) när body-elementet har mer än 800 noder och som ett felmeddelande(i rött) när body-elementet har mer än 1 400 noder och ett meddelande med denna rekommendation:"Undvik överdriven DOM-storlek".

Undvik överdriven DOM-storlek i WordPress 0

Beroende på innehållet och strukturen på varje sida du analyserar kommer du att hitta mer eller mindre ledtrådar till vilka element du kan attackera. Fördelen är att det oftast visas en bild som pekar på elementet i fråga.

Jag vill än en gång påminna om att alla dessa varningar endast är rekommendationer och att du inte ska gripas av panik eller bli besatt av dessa mätvärden. Det finns sidor som erbjuder en bra användarupplevelse och en bra upplevd hastighet med låga PageSpeed-poäng.

Med GTmetrix kommer vi i allmänhet att få samma resultat på DOM.

Undvik överdriven DOM-storlek i WordPress 1

Här är dock hans "vattenfallsgraf" över förfrågningar mycket användbar för att på ett överskådligt sätt inspektera alla objekt sorterade efter typ och efter den tid det tar att ladda dem.

Undvik överdriven DOM-storlek i WordPress 2

Men det enklaste och snabbaste sättet är genom vilken webbläsare som helst. Öppna sidan som ska analyseras och högerklicka / "inspektera" och i fliken "Nätverk" hittar du ett mycket mer detaljerat vattenfall eftersom du kan komplettera det genom att bläddra på sidan och alla filer som den innehåller kommer att läggas till. Du kan sedan sortera dem efter vikt, typ, tid etc.

Undvik överdriven DOM-storlek i WordPress 3

Under detta fönster hittar du en sammanfattning av resultaten. Till vänster, antalet förfrågningar. Till höger, i blått, DOMContentLoaded-händelsetiden och i rött laddningstiden för den sidan.

Minska DOM-storleken med Perfmatters "Lazy Elements".

Perfmatters, det viktiga plugin som jag aldrig tröttnar på att rekommendera, lade i sin version 2.3.3 den 28 augusti 2024 till ett alternativ som heter Lazy Elements som, även om det fortfarande är i Beta, fungerar riktigt bra för att underlätta uppgiften att lätta DOM.

Undvik överdriven DOM-storlek i WordPress 4

Denna funktion gör det möjligt att lägga till den felaktigt benämnda"Lazy Load" till specifika element och deras ättlingar (barn) genom att lägga till en enda del av en attributsträng (class="example") i en överordnad container.

I den dokumentation som Perfmatters tillhandahåller om denna nya funktionalitet varnas vi för att försöka tillämpa "Lazy Load" på element som ligger ovanför vikningen. Det vill säga det som laddas på skärmen och det första användaren ser utan att scrolla ner.

Det noteras vidare att om du ser att något är visuellt trasigt, se till att du har använt en unik sträng på sidan som inte delas med andra element.

Precis som med de långsamt laddande bilderna placeras innehållet inuti en . Det innebär att allt som laddas långsamt fortfarande är tekniskt genomsökbart och indexerbart av Google. De kan dock inte säga säkert hur Google kommer att behandla element med Lazy Load i en sträng. Så de rekommenderar, när det gäller SEO, att testa först.

Det varnar också för att försöka tillämpa Lazy Load på element som innehåller bilder som startar en "lightbox". Och så är det, jag har kunnat verifiera att den inbyggda WordPress lightbox-funktionen slutar att fungera när klassen för ett element som implementerar den läggs till i listan.

Annars fungerar "Lazy Elements" perfekt. Tack vare den här funktionen har jag sparat mycket tid på att tunna ut DOM:en med bra resultat. Jag hoppas att Perfmatters kommer att fortsätta sin utveckling för att förbättra och utöka sina alternativ.