The DOM (Document Object Model) is a programming interface for HTML and XML documents and the name given to the structure of an HTML document, composed of branches and nodes containing objects.
The history of the Document Object Model dates back to the so-called"browser wars" of the late 1990s between Netscape Navigator and Microsoft Internet Explorer, as well as JavaScript and JScript, the first scripting languages to be widely implemented in the JavaScript engines of web browsers.
DOM structure in WordPress: tree, branches and nodes
The DOM in WordPress is not very different from any other website.
<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)
- Tree: The entire page is represented as a tree with a root node
(<html>)and its child elements. - Branches: Each element within a
<div>,<header>,<footer>,etc.,represents a branch of the tree. - Nodes: All HTML elements, such as
<p>,<img>,or<a>,are nodes that hang from branches. These nodes can be internal (containing other nodes) or external (the "leaves" of the tree that have no other children).
Thus, the density of the branches will depend on the type and number of elements that compose it. For example, a complex navigation menu in WordPress can generate several levels of branches and dozens of nodes due to the number of links and submenus.
You can think of nodes as all the HTML elements on a page. The more elements you have, usually the longer it takes, which leads to a higher Total Block Time(TBT).
This can be a tricky thing to optimise in WordPress, as you can't simply remove the DOM elements that make up the structure of a page. However, we can selectively display these elements and load a string of objects below the fold, thus reducing the overall size of the DOM.
Why reduce the size of the DOM?
A bulky DOM tree can slow down your site's load time in several ways, increasing memory usage by causing longer and slower style calculations, as well as expending unnecessary data costs for users.
These different scenarios can include the unnecessary loading of nodes that are not visible when the user first loads the page, the repetition of node position and style calculations on a constant basis, and the storage of an excessive number of references to nodes that overload the memory of users' devices.
The short and long term benefits of optimising page load speed have already been explained in a thousand and one articles. In short, in the short term you avoid people leaving your site bored of waiting and most likely they will spend more time on it. The loading speed is one of the factors recognised by Google in SEO positioning and I understand that it is also for the rest of search engines, so in the long term the precious organic traffic will increase.
What causes the DOM to increase in size?
The final size of the DOM is influenced by many factors such as the template itself, what the different plugins you use add and the type of content you add such as complex blocks or the nefarious "sliders" of images, etc. . Also the code generated for example by the so-called "Builders".
For example, until 2022, year in which I abandoned Elementor because it resisted optimisation and it was rare that it didn't break something in almost every update, plus a couple of bad experiences with their technical support, this builder turned the web code into a real alphabet soup and a nightmare with thousands of
In April of that same year, Elementor incorporated the Flexbox "Container" as a very new and revolutionary novelty, when the container had already been the basis of GenerateBlocks for years.
How to measure DOM?
For the measurement I have chosen a post that is not very optimised yet, a bit long and with different types of elements.
Let's start with the best known and most popular: PageSpeed Insights . Google marks there as a warning(in orange) when the body element has more than 800 nodes and as an error warning(in red) when the body element has more than 1,400 nodes and a message with this recommendation:"Avoid excessive DOM size".
Depending on the content and structure of each page you analyse, you will find more or less clues as to which elements you can attack. The advantage is that it usually shows an image pointing to the element in question.
Once again, I would like to remind you that all these alerts are only recommendations and that you should not panic or become obsessed with these metrics. There are pages that offer a good user experience and a good perceived speed with low PageSpeed scores.
With GTmetrix we will generally get the same results on the DOM.
However, here his "waterfall" graph of requests is very useful to inspect at a glance all items sorted by type and by the time they take to load.
But the easiest and quickest way is through any browser. Open the page to be analysed and right click / "inspect" and in the "Network" tab you will find a much more detailed waterfall because you can complete it by scrolling the page and all the files it contains will be added. You can then sort them by weight, type, time, etc.
Below this window you will find a summary of the results. On the left, the number of requests. On the right, in blue, the DOMContentLoaded event time and in red the load time of that page.
Reduce DOM size with Perfmatters' "Lazy Elements".
Perfmatters, that essential plugin that I never get tired of recommending, added in its version 2.3.3 of 28 August 2024 an option called Lazy Elements that, although it is still in Beta, works really well to facilitate the task of lightening the DOM.
This function allows adding the misnamed "Lazy Load" to specific elements and their descendants (children) by adding any single portion of an attribute string (class="example") of a parent container.
In the documentation provided by Perfmatters on this new functionality, we are warned not to try to apply "Lazy Load" to elements that are above the fold. That is, what loads on the screen and the first thing the user sees without scrolling down.
It is further noted that if you see that something is visually broken, make sure that you have used a unique string on the page that is not shared with other elements.
As with slow-loading images, the content is placed inside a . This means that anything that loads lazily is still technically crawlable and indexable by Google. However, they cannot say for sure how Google will treat elements with Lazy Load in a string. So they recommend, in terms of SEO, to test first.
It also warns not to try to apply Lazy Load to elements containing images that start a "lightbox". And so it is, I have been able to verify that the native WordPress lightbox function stops working when the class of an element that implements it is added to the list.
Otherwise, "Lazy Elements" works perfectly. Thanks to this feature I have saved a lot of time thinning the DOM with good results. I hope Perfmatters will continue its development to improve and expand its options.
