What is the DOM?
A browser can’t draw HTML code as it arrives. It first turns it into a tree: every tag becomes an element, and elements sit inside one another the way the tags do. That tree is the Document Object Model, or DOM. It is what the browser actually lays out and paints, and what scripts on the page read and change.
The size and shape of the tree matter because the browser keeps working with it after the page has loaded. Every time something changes, such as a menu opening or a product being added to a basket, it has to work out again which elements are affected and where they go. The more elements there are, and the deeper they are nested, the longer that takes, and the slower the page feels to use.
How this test works
Our server downloads your page and builds the tree from its code, the same way a browser does. Then it measures the three things Lighthouse, Google’s testing tool, reports for a page: how many elements there are, how many levels deep the deepest one sits, and which single element has the most elements directly inside it. We count them the way Lighthouse does, so our figures can be set beside its report: the elements inside the body of the page, with depth counted from the body as level 1. The elements in the head, such as meta tags and links to stylesheets, are not part of that total; they are shown separately. The chart shows how the elements are spread across the levels, so you can see whether the page is flat or a long way down.
The figures at the top follow the page through the steps a browser takes. It receives the page as bytes and decodes them into characters. It cuts the characters into tokens: start tags, end tags, comments and pieces of text. Each token becomes a node, and the nodes are linked into the DOM. So the figures read in order as bytes, characters, tokens, nodes and DOM elements, each counted on your page. Characters are fewer than bytes when the page uses letters that take more than one byte, and elements are fewer than nodes because pieces of text and comments are nodes too.
Tokens are counted the way a browser’s tokenizer produces them, which is also how Googlebot reads a page, since it renders pages with the same engine as Chrome. Each tag and each comment is one token. Text is handed on one character at a time, including the code inside scripts and styles, and a final token marks the end of the file. So the figure is much larger than the number of tags: a page with a lot of text or inline code has a lot of tokens. It is our estimate from the page’s code. A few special cases, such as “&” counting as one character, are not allowed for.
The report also shows what the tree is made of: the tags used most, wrappers that carry no meaning of their own, and elements with nothing in them.
Styles and scripts that hold up the page
The DOM is only half of what a browser needs before it can show anything. It also has to read the page’s styles and work out how each element should look. Until both are ready, the screen stays blank. So we also count the stylesheets in the head of the page, which the browser must download and read first, and the scripts there that stop it from reading on until they have run.
What is a good result?
Google no longer gives a fixed limit. The current DOM size check in Lighthouse and Chrome’s developer tools reports three figures, the total number of elements, the depth of the tree and the most children of one element, and fails a page only when it measures the cost: a style recalculation or layout that takes longer than 40 milliseconds. That can only be measured in a real browser, so this test can’t tell you whether your page passes it.
Until version 13, Lighthouse did use fixed marks: it warned when the body of a page had more than about 800 elements and reported a problem above about 1,400. They are still a sensible yardstick.
Our score is built on them. A body with 800 elements or fewer scores the full 100. From 800 to 1,400 the score eases down to 90: we treat that range as normal, with 1,400 as its upper end. Above 1,400 it falls faster, in a straight line, and reaches 0 at 3,000 elements, which we treat as badly overloaded. So 2,100 elements scores about 50. This scale is Seokla’s, not Google’s.
For depth and for the number of children there are no marks from Google. Google’s own note is that a deep tree isn’t a problem in itself, but is often a sign of nesting that isn’t needed. We use 32 levels and 60 children as our own guide.
One more difference from Google’s tools: they count the elements after the page’s scripts have run, and we count them as the page arrives. On most sites the two agree closely. On a site that builds its content in the browser, theirs will be higher.
What this test can’t tell you
We read the page as it arrives from the server and don’t run its scripts. If your site builds its content in the browser with JavaScript, the real DOM is larger than the one we count, sometimes much larger. A page with very few elements and very little text in its code is the usual sign of this, and the report points it out.
We also can’t tell you how long a browser takes to build and update the tree. That depends on the visitor’s device. The Performance panel in Chrome’s developer tools measures it on yours.