Screpy - AI SEO Audit Tool

Reduce Excessive DOM Size

Statements made by Google underline one point: Document Object Model AKA web page should not be on excessive size.

Reviewed by Screpy Editorial Team

Why DOM size is important?

We now know that Excessive DOM size negatively impacts web performance. So how exactly does it do this? Let’s examine it together!

The decrease in Network Efficiency & Load Performance

The high DOM size causes decrease in network efficiency and load performance. Having a high DOM tree means a lot of actors that need to be loaded with the page. Loading a large number of details that are not even visible to the user each time causes the page to open much more slowly and reduces the user experience.

The decrease in Runtime Performance

The higher the DOM size, the lower the runtime performance. Runtime performance is a metric that measures how your website performs while running in the normal process, not while it is being loaded. The large size of DOM causes you to experience a slowdown in standard running times.

The process is like this: Each time a user enters your web page, the browser continuously recomputes the position and styling of nodes. The more complex it takes to perform this recomputing process, the slower the rendering will be.

The decrease in Memory Performance

At this point, you need to check your JavaScript. The high size of DOM sometimes results in general query selections that will probably reduce your memory performance. Because in such a case, you may be storing a large number of references to a high number of nodes. This will cause your memory performance to decrease in users’ devices.

Using Lighthouse to Avoid Excessive DOM Size

What Google Lighthouse does is pretty simple. System;

  1. Outputs a report of the total DOM elements within a page.
  2. Calculates the maximum DOM depth of a page.
  3. Calculates the maximum DOM child elements of a page.

Reduce Excessive DOM Size

Let’s also list the DOM data requested by Google and many other browser tools. Which DOM Trees are flagged by Lighthouse? Here are they:

  1. Pages with more than 1500 nodes are flagged.
  2. Pages with depths greater than 32 nodes are flagged.
  3. Pages hosting parent nodes with 60 child nodes are flagged.

What Can You Do To Optimize DOM Size?

So, what are the main ways to optimize the DOM for you, especially as requested by Google and other browser systems?

The main thing you need to do is use systems that will destroy unnecessary DOMs and generate the necessary ones at the right time. What does it mean?

When to create nodes?

For example, let’s say you are currently submitting a large DOM tree. In this case, all you have to do is load your page. Then to determine in detail which nodes are shown. After taking your note, you will have the chance to destroy the invisible nodes that are not displayed on the page. You should only generate those nodes when the user has a behavior that will cause you to display the nodes in question, for example when the user exhibits an expected scroll behavior or clicks a button.

What if you cannot avoid a large DOM tree?

If it is not possible to reduce the large DOM tree you have due to some software features of your web page, let’s tell you what to do: Simplify CSS selectors. In this way, you will improve rendering performance. Google has content on Reduce the Scope and Complexity of Style Calculations. You can also have a look at it.

Measure the DOM before removing useful content.

Treat DOM size as a page-specific performance signal, not a reason to delete visible copy. Find the component that creates the most nodes, reduce unnecessary markup, and measure the same URL again.

  • Record total elements, maximum depth, and the largest repeated child group before editing.
  • Inspect accordions, navigation, tables, and client-rendered lists for hidden or duplicated nodes.
  • Compare the rendered DOM after the fix and retest the affected interactions.

How to diagnose it

  • Use the Elements panel or a page audit to identify the subtree responsible for most nodes; the page total alone does not identify the component to fix.
  • Check the DOM after JavaScript has finished. Client-rendered menus, filters, and infinite lists may add far more nodes than the initial HTML.

How to fix it

  • Render long result sets in pages or with virtualization, and create off-screen rows only when the user needs them.
  • Remove wrappers that have no layout, semantic, accessibility, or behavior purpose. Reuse one shared component instead of shipping duplicate desktop and mobile trees.

How to verify the fix

  • Repeat the same measurement at the same viewport and application state, then compare node count and depth with the recorded baseline.
  • Test keyboard navigation, screen-reader relationships, responsive layouts, and content discovery after reducing markup.

Limits and false positives

  • A large documentation page may need many semantic nodes; do not remove headings, labels, table structure, or accessible descriptions only to lower a count.
  • Collapsing content with CSS does not reduce DOM size when every hidden node is still rendered.

Before

<ul>{items.map((item) => <ResultRow item={item} />)}</ul>

After

<PaginatedResults items={items} pageSize={25} />

Related tasks

Reducing Render-Blocking Resources

In order for your website to work properly, you need to get rid of URLs that hamper the rendering process. Here are a few tips for you!

Monday, November 23, 2020

Heading Order: Fix Skipped Heading Levels

Use a logical H1-H6 hierarchy so people and assistive technology can understand page structure. Learn how to find and fix skipped heading levels.

Thursday, November 12, 2020