Categories
Web Development

What Is DOM and How To “Avoid an Excessive DOM Size”

Web Browsers are a beautiful creation that allows us to view & use web pages on the internet. The governing fundamentals that make that happen transpire at the speed of light.

From the many, one of the core principles is DOM — or short for — Document Object Model.

What Is DOM (Document Object Model)?

If you’ve ever worked with Google PageSpeed Insights, you’ve probably come across a recommendation of “Avoid an excessive DOM size.” However, perhaps, you do not know what that entails, or taking a step back, you don’t even understand what DOM, DOM depth, etc. are.

Therefore, in order to interpret what PageSpeed Insights is telling us, we need to get a grasp on the role of DOM in all of this.

Defining DOM

When browsers accept a web page, it needs to comprehend its HTML, CSS, JavaScript, etc. Only then, it can start displaying all of the content. Now, to even begin to assimilate what the page is, your browser first needs to arrange the document in a tree-like structure.

This arrangement is typically divided into two parts:

  1. HTML: Responsible for the primary content.
  2. CSS: In charge of how the page should look like and or the rules that need to be followed. In other words, it manages the styling of a page.
  3. When both are constructed, the browser combines the two to form a render tree — a concept you don’t have to worry about in this post. Essentially though, this is when rendering starts to happen.

In what’s described in bullet 1 above, the arrangement of the HTML markups is what DOM basically is. The technical definition of how it behaves, what it is, etc., will vary vastly from defining it here. Still, to convey the information and just about scratch the surface into novice terms, you can think of a DOM as a logical tree-like arrangement of the HTML components.

How the DOM Tree-Like Structure Looks Like

When it comes to technical concepts, visuals certainly help! In that same spirit, to help you ease into the technicality of how a DOM looks like, keep the following 2 screenshots in mind — grabbed straight from Wikipedia, and Google Developers.

Document Object Model (DOM) Wikipedia
Image Source: Wikipedia
Document Object Model (DOM) Google Developers
Image Source: Google Developers

3 Other DOM Technical Lingo You Should Know

  1. Nodes: Anything between an opening HTML tag and the closing of the said HTML Tag, is called an HTML element. For example, if you look at the picture that follows, everything between the <a></a> tags (including the tags themselves) is called an HTML element.
an example of an HTML node
An example of an HTML element. For all intents of this post, know that all HTML elements are referred to as nodes. Although technically, everything in the DOM is a node.
  1. DOM Depth: Refers to how deep or how many steps down a particular node is. For instance, the <body> element in the Wikipedia image has a depth of 1. (HTML–>Body). The count always starts from HTML, whose value is zero (0).
  2. Child Elements: A sub-node of a node can be called a child element. For example, body is a child of HTML.

Why Is a Large DOM Size Problematic?

There are a couple of foundational reasons as to why a large DOM size has a direct & negative impact on performance:

  • The more intense, heavy, and intricate a code is, the more time it takes for the browser to parse the HTML, and construct a DOM tree, to eventually begin rendering. At the heart of the problems, this is the dominant cause of when things start to go sideways. All of the other issues are virtually a derivation of this systemic complication.
  • A large DOM size can also unfavorably impact your TTFB. This happens because your HTML document size is directly proportional to how big or small your DOM is. Simply put, think of it as downloading a movie on the internet. A file with a vast size will take more time, than one that’s not in comparison (all things being equal).
  • Further, an enormous DOM can end up having noticeable differences in memory usage.

When Does PageSpeed Insights/Lighthouse Trigger a Red Flag for Excessive DOM Size?

According to web.dev, Lighthouse triggers a red flag for an excessive DOM size when:

  • A Page has more than 1,500 total nodes.
  • Has a DOM depth of more than 32.
  • Has greater than 60 child notes belonging to a parent node.

Note that not all 3 conditions need to be met. If your page fails the test for either, Lighthouse will still prompt warning signs.

How To "Avoid an Excessive DOM Size"
Image Source: web.dev

How To “Avoid an Excessive DOM Size”

Reducing DOM size is an advanced tactic, and in most situations, involves a lot of work.

Generally speaking, less code is better. Put another way, if you could achieve the same exact results with less code, it’s better.

Anyhow, below are some of the best practices for avoiding an excessive DOM size:

  • Avoid unnecessary code, themes, and plugins. Eradicate all of the unrequired HTML tags and elements. Pursuing this may involve a lot of testing, as you’d need to ensure it doesn’t break your site or its functionality.
  • Speaking of, if there’s a functionality that more so embellishes rather than enhances, think of getting rid of it. For example, do you really need a search bar in the header and then again in the footer?
  • Divide large pages into multiple pages as it can significantly help you reduce your code. An example can be of leveraging pagination.
  • Use all of the coding best practices, invest in the use of modern technologies geared towards speed & UX — without compromising on your site’s performance, and learn and apply web development methodologies suitable for improved load times, such as lazy loading images.
  • A bit more precise guidance, can be found here.

You May Also Want to Check Out:

Summing Up

Bringing everyone on board to shrink your DOM size is not only ambitious but cumbersome. In an ideal world, yes, you should aim to solve for it; however, the questions you need to ask yourself are these: Is it worth the time, effort, and resources? Are there any other areas or even technologies that can positively improve your page loads & speed — that’s low effort and wouldn’t suck out a lifetime?

If the answer is yes to either of those, my advice would be to tackle those first and then revisit “excessive DOM size.” Another reason is that you may knowingly or unknowingly minimize your DOM while you’re working on other tactics. For instance, when you get rid of non-essential plugins or JavaScripts.

Expert Citations