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.
- HTML: Responsible for the primary content.
- 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.
- 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.
3 Other DOM Technical Lingo You Should Know
- 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.
- 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. (
Body). The count always starts from HTML, whose value is zero (0).
- Child Elements: A sub-node of a node can be called a child element. For example,
bodyis a child of
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”
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.
- A bit more precise guidance, can be found here.
You May Also Want to Check Out:
- What Is an Early Hints 103 Status HTTP Code, and How It Helps Load Times
- How To Know if a Site Is Actually Serving WebP Format Images
- What Is x-content-type-options: nosniff Response Header?
- Basic Differences Between a CSS ID and a CSS Class
- Preconnect to Required Origins: What Is rel=”preconnect”
- A Prefatory Guide to dns-prefetch
- Link Rel Preload and Site Speed: A Preliminary Guide
- Static and Dynamic Content: Delineating the Differences
- A Basic Introduction to HTML5 Semantic Elements
- What Is the strict-origin-when-cross-origin Referrer Policy?
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?