Il DOM (Document Object Model) è un'interfaccia di programmazione per documenti HTML e XML e il nome dato alla struttura di un documento HTML, composta da rami e nodi contenenti oggetti.
La storia del Document Object Model risale alla cosiddetta"guerra dei browser" della fine degli anni '90 tra Netscape Navigator e Microsoft Internet Explorer, nonché a JavaScript e JScript, i primi linguaggi di scripting a essere ampiamente implementati nei motori JavaScript dei browser web.
Struttura DOM in WordPress: albero, rami e nodi
Il DOM di WordPress non è molto diverso da quello di qualsiasi altro sito web.
<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)
- Albero: l'intera pagina è rappresentata come un albero con un nodo radice
(<html>)
e i suoi elementi figli. - Rami: ogni elemento di un
<div>,
<header>,
<footer>,
ecc. rappresenta un ramo dell'albero. - Nodi: tutti gli elementi HTML, come
<p>,
<img>
o<a>,
sono nodi che pendono dai rami. Questi nodi possono essere interni (contenenti altri nodi) o esterni (le "foglie" dell'albero che non hanno altri figli).
Pertanto, la densità dei rami dipenderà dal tipo e dal numero di elementi che lo compongono. Ad esempio, un menu di navigazione complesso in WordPress può generare diversi livelli di rami e decine di nodi a causa del numero di link e sottomenu.
I nodi possono essere considerati come tutti gli elementi HTML di una pagina. Più elementi ci sono, più tempo ci vuole e quindi il tempo totale di blocco(TBT) è maggiore.
Questo può essere un aspetto difficile da ottimizzare in WordPress, poiché non è possibile rimuovere semplicemente gli elementi DOM che costituiscono la struttura di una pagina. Tuttavia, possiamo visualizzare selettivamente questi elementi e caricare una stringa di oggetti sotto la piega, riducendo così la dimensione complessiva del DOM.
Perché ridurre le dimensioni del DOM?
Un albero DOM ingombrante può rallentare il tempo di caricamento del sito in diversi modi, aumentando l'utilizzo della memoria e causando calcoli di stile più lunghi e lenti, oltre a comportare costi di dati non necessari per gli utenti.
Questi diversi scenari possono includere il caricamento non necessario di nodi che non sono visibili quando l'utente carica la pagina per la prima volta, la ripetizione di calcoli di posizione e stile dei nodi su base costante e la memorizzazione di un numero eccessivo di riferimenti ai nodi che sovraccaricano la memoria dei dispositivi degli utenti.
I vantaggi a breve e lungo termine dell'ottimizzazione della velocità di caricamento delle pagine sono già stati spiegati in mille articoli. In breve, nel breve periodo eviterete che le persone abbandonino il vostro sito annoiate dall'attesa e molto probabilmente vi dedicheranno più tempo. La velocità di caricamento è uno dei fattori riconosciuti da Google nel posizionamento SEO e mi risulta che lo sia anche per il resto dei motori di ricerca, quindi a lungo termine il prezioso traffico organico aumenterà.
Cosa provoca l'aumento delle dimensioni del DOM?
La dimensione finale del DOM è influenzata da molti fattori, come il template stesso, ciò che i diversi plugin utilizzati aggiungono e il tipo di contenuto aggiunto, come blocchi complessi o i nefasti "slider" di immagini, ecc. Anche il codice generato, ad esempio, dai cosiddetti "costruttori".
Per esempio, fino al 2022, anno in cui ho abbandonato Elementor perché resisteva all'ottimizzazione ed era raro che non rompesse qualcosa in quasi ogni aggiornamento, oltre a un paio di brutte esperienze con il loro supporto tecnico, questo builder ha trasformato il codice web in una vera e propria zuppa alfabetica e in un incubo con migliaia di
Nell'aprile dello stesso anno, Elementor ha incorporato il "contenitore" Flexbox come novità assoluta e rivoluzionaria, quando il contenitore era già alla base di GenerateBlocks da anni.
Come misurare il DOM?
Per la misurazione ho scelto un post non ancora molto ottimizzato, un po' lungo e con diversi tipi di elementi.
Cominciamo con il più noto e popolare: PageSpeed Insights . Google segnala come avviso(in arancione) quando l'elemento body ha più di 800 nodi e come avviso di errore(in rosso) quando l'elemento body ha più di 1.400 nodi e un messaggio con questa raccomandazione:"Evita dimensioni eccessive del DOM".
A seconda del contenuto e della struttura di ogni pagina analizzata, troverete più o meno indizi su quali elementi potete attaccare. Il vantaggio è che di solito mostra un'immagine che punta all'elemento in questione.
Ancora una volta, vorrei ricordarvi che tutti questi avvisi sono solo raccomandazioni e che non dovete farvi prendere dal panico o dall'ossessione per queste metriche. Ci sono pagine che offrono una buona esperienza utente e una buona velocità percepita con punteggi PageSpeed bassi.
Con GTmetrix si ottengono generalmente gli stessi risultati sul DOM.
Tuttavia, in questo caso il suo grafico "a cascata" delle richieste è molto utile per esaminare a colpo d'occhio tutti gli elementi ordinati per tipo e per il tempo che impiegano a caricarsi.
Ma il modo più semplice e veloce è attraverso un qualsiasi browser. Aprite la pagina da analizzare e fate clic con il tasto destro del mouse / "ispeziona" e nella scheda "Rete" troverete una cascata molto più dettagliata perché potrete completarla scorrendo la pagina e verranno aggiunti tutti i file in essa contenuti. È quindi possibile ordinarli per peso, tipo, tempo, ecc.
Sotto questa finestra si trova un riepilogo dei risultati. A sinistra, il numero di richieste. A destra, in blu, il tempo dell'evento DOMContentLoaded e in rosso il tempo di caricamento della pagina.
Ridurre le dimensioni del DOM con gli "Elementi pigri" di Perfmatters.
Perfmatters, quel plugin essenziale che non mi stanco mai di consigliare, ha aggiunto nella versione 2.3.3 del 28 agosto 2024 un'opzione chiamata Lazy Elements che, sebbene sia ancora in fase beta, funziona molto bene per facilitare il compito di alleggerire il DOM.
Questa funzione consente di aggiungere il cosiddetto"Lazy Load" a elementi specifici e ai loro discendenti (figli), aggiungendo una singola porzione di una stringa di attributi (class="esempio") di un contenitore padre.
Nella documentazione fornita da Perfmatters su questa nuova funzionalità, si avverte di non cercare di applicare il "Lazy Load" agli elementi che si trovano sopra la piega. Vale a dire, ciò che viene caricato sullo schermo e la prima cosa che l'utente vede senza scorrere verso il basso.
Inoltre, se si nota che qualcosa è visivamente rotto, assicurarsi di aver utilizzato una stringa unica nella pagina che non sia condivisa con altri elementi.
Come per le immagini a caricamento lento, il contenuto è inserito all'interno di un elemento . Ciò significa che tutto ciò che viene caricato pigramente è ancora tecnicamente crawlabile e indicizzabile da Google. Tuttavia, non possono dire con certezza come Google tratterà gli elementi con Lazy Load in una stringa. Pertanto, in termini di SEO, si consiglia di effettuare prima dei test.
Avverte inoltre di non cercare di applicare il caricamento pigro agli elementi contenenti immagini che avviano una "lightbox". E così è, ho potuto verificare che la funzione lightbox nativa di WordPress smette di funzionare quando la classe di un elemento che la implementa viene aggiunta all'elenco.
Per il resto, "Lazy Elements" funziona perfettamente. Grazie a questa funzione, ho risparmiato molto tempo per sfoltire il DOM con buoni risultati. Spero che Perfmatters continui il suo sviluppo per migliorare ed espandere le sue opzioni.