Avoid an excessive DOM size WordPress.

Avoid andexcessive DOM size WordPress. In this post I’ll be talking about how to avoid an excessive DOM size when using WordPress, what to do if you have an excessive DOM size and why it’s a good idea to address an excessive DOM size. This post covers:

For this post to make sense you’ll need to have a basic understanding of how a browser renders a web page.

I’ll cover the DOM part below (although in quite simple terms), but the information linked to above will give you more context, even if you just read the basic explanation.

It would also help if you knew a little bit about HTML before reading this post, but it’s not mandatory.

What is a DOM?

DOM stands for document object map. This is the first part of page output that a browser uses to start rendering a page. As the name suggests, it’s quite map like.

If you thought of a web page as a completed picture in a child’s colouring book, the DOM would be the picture before the child did the colouring.

The DOM is the initial page layout, minus styling information and Javascript (these both get applied to the DOM after it’s been loaded). The DOM of a simple contact form page, would look something like this:

As the DOM is effectively the initial construction phase of a page in a browser (and then CSS and JavaScript are then applied once the DOM has been calculated). Having a big DOM very roughly means that your page has a big map, and applying CSS and JavaScript to a big map makes a browser work harder due to the “big” aspect.

A big DOM = more browser work = slower page load time (probably).

Consequently it’s a good idea to address an excessive DOM size, as this will improve the experience of your site visitors, and it will also improve performance, which can positively affecting page ranking in search engine results.

What makes a DOM excessive in size?

A DOM is made of nodes. I’ll come to what nodes are in a moment, but first let’s talk numbers.

According to Google’s Chrome/Lighthouse documentation:

A DOM count of more than around 800 nodes will result in a warning.

A DOM count of more than around 1400 nodes will result in an error.

HTML Nodes.

There are different types of nodes that can be contained in the DOM.

Element nodes:

These represent HTML elements in the document. For example, <div>, <p>, <h1>, and <a>. Each tag in your HTML markup corresponds to an element node in the DOM.

In this example, the nodes are <div> and <p>:

<div id="container"> 
<p>Hello, world!</p> 
</div>

Text nodes:

These represent the textual content within an element. Text nodes are the actual text between HTML tags.

In this example, “This is a”, “text”, and “node.” are text nodes:

<p>This is a <em>text</em> node.</p>

When you manipulate the content of an element using JavaScript, you are often interacting with the text nodes.

Attribute nodes:

These represent the attributes of an element. Attributes provide additional information about an element. Each attribute of an element is represented as a node.

In this example, href and title are attribute nodes of the <a> element:

<a href="https://example.com" title="Example">Link</a>

Document Nodes:

These represent the entire document. They are the root of the DOM tree.

The <!DOCTYPE html> declaration, the <html> element and verything contained within it are considered part of the document node.

How the nodes get on the page.

You put them there…

The nodes get added to the page by you putting them there. That’s right, nodes are required in HTML to display your content as you want it to.

For example if I just want a paragraph saying hello in normal text, this is what would be in my html:

<p>Hello</p>

That’s one node: <p>

But if I want Hello to be in bold and italics, then my html would be somethig like this:

<p><b><i>Hello</p></b></i>

Now we have 3 nodes: <p><b><i>

So the more formatting you have, the more nodes you end up with.

But that’s not the oly way that nodes get on the page…

Page builders put them there…

There are a variety of nodes that pagebuilders will add to your site’s pages. Some page builders do this more that others (they don’t all work in the same way). Some examples of the sorts of nodes that paebuilders will add to site pages are:

Wrapper Divs

Page builders often wrap content within additional div elements for styling or structural purposes. These divs may have custom classes or attributes to control layout and appearance. For example:

<div class="row">
    <div class="col-md-6">
        <!-- Content added by page builder -->
    </div>
    <div class="col-md-6">
        <!-- Content added by page builder -->
    </div>
</div>

Custom Containers

Page builders may introduce custom container elements to encapsulate sections of content. These containers might have specific styling or functionality associated with them. For example:

<section class="custom-container"> <!-- Content added by page builder --> </section>

Shortcode Embeds

Page builders often utilize shortcodes to embed dynamic content or functionality within the page. These shortcodes are typically replaced with HTML markup when the page is rendered. So before rendering a shortcode would look like this:

[gallery ids="123,456,789"]

And after rendering it might look like this:

<div class="gallery">
    <!-- Gallery images added by page builder -->
</div>

Widgetised Areas

Page builders might insert widgetized areas where users can add widgets for various purposes, such as displaying recent posts, social media feeds, or custom content. For example:

<div class="widget-area">
    <!-- Widgets added by page builder -->
</div>

Dynamic Content Blocks

Page builders might generate dynamic content blocks, such as sliders, testimonials, or feature boxes, which are often encapsulated within specific HTML elements. Such as:

<div class="testimonial">
    <!-- Testimonial content added by page builder -->
</div>

Do be aware that the above are just some examples, and nodes added by page builders will vary according to the page builder itself.

Nodes in a practical context.

As you’ll know from reading the above, there are some nodes that you add by creating and formatting content, and there are other nodes that might be added by the pagebuilder you’re using.

Let’s put this in a pratical context for a moment.

Imagine that you’ve written a blog post. Let’s say it’s quite a long blog post due to the subject matter. The length alone increases the DOM size (unless, perhaps you’ve written the entire post in one lone sentence instead of using paragraphs). So we’ve got:

More length = more nodes

If, like me, you separate your blog post in to sections using spacers and dividers, this will result in more nodes. So we’ve also got:

More formatting = more nodes

If you love your widgets, and you’ve splashed them all over the pagel, you also have:

More widgets = more nodes

Obviously you can control the above by adjusting content, removing formatting, and using less widgets, but now lets add the page builder factor.

The problem with the page builder is that it adds nodes in a manner that’s not entirely transparent.

Just for example’s sake, let’s say the page builder adds 2 divs to all nodes.

That would mean, that if you have this in a portion of HTML (pre site builder):

3 Element nodes

2 widget nodes

4 formatting nodes

Total: 9 nodes

Once the page builder generated nodes are taken in to account, you’d have:

3 Element nodes

plus 6 site builder added divs

2 widget nodes

plus 4 site builder added divs

4 formatting nodes

plus 8 site builder added divs

Total: 27 nodes

Obviously 9 nodes increasing to 27 nodes is quite a jump. This is because (in the example above) the page builder effectively multiplies the number of nodes by a factor of 2 in addition to the nodes that were already present in the pre-sitebuilder html.

Although it’s not that likely that this is what’s taking place, what I’m hoping to illustrate here is that using a pagebuilder that is adding nodes could result in an exponential growth in nodes, and before you know it you have an excessive DOM size.

The annoying part of having an excessive DOM size.

The part that’s usually the annoying aspect of an excessive DOM size is that you’ll usually find this out after making page content, or maybe even an entire site.

It’s eaiser to to avoid having an excessive DOM size in the first place than it is to address this after creating a page or a site, but how would you know what to avoid if you’re making your own site for the first time?

When trying to reduce DOM size, it might not be the case that one specific action will suddenly cause a reduction in DOM size, you’re most likely going to have to undertake a few differen tasks to reduce DOM size. The only real exception to this would be if you’re using a page buuilder that’s heavily contributing to DOM size and you’re moving away from it, but that’s quite a task in itself.

You can help minimise DOM size my reducing formatting, or changing the content of your sites pages. Do you really need that spacer? Is that text in bold really required? OK, we all like to make our site’s pages look nice, so there may only be so far you can take this, but that in itself is annoying. Especially as you might well have to work through reformatting multiple pages on your site.

You can also help minimise the risk of having an excessive DOM size by using a site builder that doesn’t add lots of divs to your site’s pages, but you’re only going to find this out with experience, and by using multiple different page builders, which not everyone does.

The main page builders that are known to add a lot of divs are Elementor and Divi, which is a bit of a shame as these are both widely used due to being fully featured andvery usable.

The most annoying situation related to having an excessive DOM size is when it’s across an entire site. If this is the situation that you find yourself in, there’s not much alternative to rebuilding your site using a different page builder.

How to address and excessive DOM size.

Due to what it is that contributes to an excessive DOM size, you’re really looking at reworking your site’s pages, minimising formatting and page elements, or a complete site rebuild using a different page builder. You might even be looking at a combination of any of these.

This isn’t the best of news is it? Well there is some good news,

Identify what’s adding a lot to the DOM.

Look at your page output. Is there anything that’s showing up very frequently that’s specific to a particular pluign that’s contributing to your DOM size? If there is can this be addressed universally?

The best you can hope for here is using less widgets or a particular widget. The worst case scenario is that you might have to rebuild your entire site using a different page buidler. I’ve had to do this myself (I didn’t have an excessive DOM size, but I had a poor text to code ratio, and a few performance issues). You can read how I did this and what the affect was in my accidental wordpress experiment post.

Less is more, simplicity can be better.

Do you need all that crazy formatting? Could you use 2 fonts instead of 6? I’m talking spacers, mega menus, fonts, inner sections, it all adds up. Remove what you can, keep it simple, use what’s left to give your site a consistent look and feel.

Hardcode what you can.

Yep, that’s right, if you can do it manually rather than using something generated by a page builder or a widget, do exactly that. The HTML that you write and put in a footer is invariably going to contain less nodes than something generated for you.

Unload what you can.

Using an asset manager such as the Asset Clean Up plugin to unload Javascript and CSS that’s present but isn’t actually used will help reduce DOM elements. You can see the process in this section of the Reduce Unused JavaScript post on this site.

Consider a site rebuild if your page builder is the problem.

It’s better to bite this bullet than it is to try and work around it or do things differently. If it is your page builder causing, or at least significantly contributing to the DOM size, it’s going to be quicker and less painful to remake the site than it is to tinker around the edges. I would suggest having a read of the Accidental WordPress Experiment post if you’re thinking of doing this.

Lazy load what you can.

If it’s not in the viewport does it need to be loaded? Not if it’s media such as images or videos, and not if it’s comments, it doesn’t. Loading these when they appear in the viewport (which is what lazy loading does) will help reduce the size of the initial DOM. Many caching plugins can do this such as the Litespeed cache plugin, and the W3 Total Cache plugin.

Disable unused features.

In plugins and page builders you can often disable features. If you’re not using a feature turn it off. This stops elements and/or nodes specific to that feature being present in your page output.

Consider removing elements that add large amounts of DOM elements.

If someting signifcantly contributes to the DOM node count, consider removing it or replacing it with an equivalent plugin.

In conclusion.

An excessive DOM size can result in a poor expeirence for your site visitors and lower page rankings.
An excessive DOM size is caused by elements in your site’s page output.
It’s best to avoid having an excessive DOM size in the first place, as reducing DOM size can be quite a task.
Addressing an excessive DOM size will often involved multiple different courses of action.
You may have to move away from the pagebuilder you’re using and rebuild your site when doing so, to reduce the size of page’s DOM.