What the DOM Complexity Analyzer does
This analyser counts the elements in a page's HTML, measures how deep the tree goes and how wide its busiest parents are, and then points at the parts responsible: the subtrees holding most of the elements and the structures repeated dozens of times. Paste HTML or fetch a public URL; the parsing happens in your browser.
A large DOM is rarely a problem in itself - it is a multiplier. Every style recalculation, layout and query has more nodes to walk, so interactions get slower, memory goes up and Interaction to Next Paint suffers most on mid-range phones. Knowing the total is less useful than knowing which component to change, which is what the hotspot and repeated-structure reports are for.
How to use it
- Paste the page's HTML, or enter a public URL and press Fetch page HTML. For pages that build most of their content with JavaScript, copy the rendered DOM instead: in DevTools, right-click the html element in the Elements panel and choose Copy outerHTML.
- Press Analyse DOM. The tiles show elements inside the body, the maximum depth below body and the largest number of direct children any one element has.
- Read the hotspots: the most specific subtrees that hold at least 15% of all elements (and at least 50). That is usually a product grid, a mega-menu, a comments thread or an embedded widget.
- Check the repeated structures: element shapes that occur five or more times, with how many elements each copy costs. Trimming one wrapper from a card repeated 48 times removes 48 elements.
- Download the JSON or the hotspot CSV to compare before and after a change.
Reading the results
The thresholds are those Lighthouse used in its "Avoid an excessive DOM size" audit: a warning above roughly 800 elements in the body and a failure above roughly 1,400. Depth above 32 and more than 60 children on one parent are the figures that audit's guidance cited. They are conventions from a tool, not standards - a 1,500-element page that never changes after load can feel faster than a 600-element page that re-renders on every keystroke.
Newer Chrome guidance focuses on the cost of each update rather than the total: a layout touching more than about 100 layout objects, or a style recalculation touching more than about 300 elements, taking over 40 ms. A big DOM makes those more likely, which is why the total is still worth watching.
Counts here are of the HTML you supplied. A fetched page is the server's HTML only; client-side rendering, lazy lists and third-party widgets can add hundreds of elements after load.
Worked example: a product listing page with 48 cards
The Product listing example has a category menu of 70 links and a grid of 48 product cards. The analyser counts 1,250 elements in the body: above the 800 warning level, below the 1,400 failure level. Maximum depth is 8, so nesting is not the issue. The menu list has 70 direct children, over the 60 guideline.
The repeated-structure report shows why: li.product-card(div) occurs 48 times at 23 elements each, 1,104 elements in total - 88% of the page. Each card has a media wrapper and a media-wrap wrapper around the image, five separate span stars and three swatch buttons.
Replacing the five star spans with one element carrying an accessible label, and dropping one of the two image wrappers, saves 5 elements per card, or 240 across the grid, which brings the page to 1,010. Rendering the first 24 products and loading more on demand would halve the grid again.
Ways to shrink a DOM without changing the design
Remove wrappers that exist only for old layout techniques; CSS grid and flexbox rarely need more than one container. Replace repeated decorative elements such as rating stars, dividers and icon backgrounds with CSS or a single image. Render long lists in pages, or virtualise them, and use content-visibility: auto for long sections below the fold so the browser can skip their layout until they are near the viewport.
Inline SVG icons are a common hidden cost: a 20-path icon repeated 40 times is 800 elements. An SVG sprite referenced with <use>, or an <img> pointing at the SVG file, keeps them out of the DOM.
Limitations: what the result does not prove
- It measures the HTML you give it. A fetched URL shows what the server sends, not the DOM after scripts run; for single-page applications, paste the rendered DOM.
- Element count is a proxy. It cannot measure style recalculation or layout time; use the Performance panel in Chrome DevTools, or the INP Interaction Profiler, to see what an interaction actually costs.
- Thresholds come from Lighthouse's audit and Chrome's documentation, not from a web standard, and they are approximate by design.
- Shadow DOM content, iframes and canvas drawings are not counted.
Privacy: where your data goes
The analysis runs in your browser. If you choose to load a public URL instead of pasting, a2z.tools fetches that address read-only and returns the text to your tab; private and internal addresses are refused and nothing is stored. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Chrome for Developers - Avoid an excessive DOM size (Lighthouse)
- Chrome for Developers - Optimize DOM size (performance insight)
- web.dev - How large DOM sizes affect interactivity
- MDN - content-visibility
Frequently asked questions
How many DOM elements is too many?
Lighthouse's DOM size audit warned above about 800 elements in the body and failed above about 1,400. Those are useful guides rather than hard rules: what matters is how many elements each update touches, so a big but static page can be fine while a smaller page that re-renders often is not.
Does DOM size affect Core Web Vitals?
Mostly through Interaction to Next Paint. More elements make style recalculation and layout after each interaction slower, which adds to the delay before the next frame. A very large initial HTML document can also delay Largest Contentful Paint, because it takes longer to download and parse.
What is DOM depth and why does it matter?
Depth is how many levels of nesting sit between the body and the deepest element. Deep trees make some CSS selectors and layout calculations more expensive and usually signal wrapper elements that add nothing. Depth is counted here from body, so a direct child of body has depth 1.
Why is the count different from what DevTools shows?
DevTools shows the live DOM after scripts, extensions and lazy loading have run, and usually counts every element including head. This tool counts the HTML you supplied, and reports elements inside body separately, which is the figure Lighthouse used.
What counts as a repeated structure?
Elements with the same tag, first class and child element tags, occurring at least five times - list items, cards, table rows. Inner shapes that only repeat because their outer card repeats are folded into the outer one, so each saving is counted once.
Is the fetched HTML stored anywhere?
No. The a2z.tools server fetches the public URL on your behalf, applies the same private-address protections as the other page checks, returns the HTML to your browser and keeps nothing. Analysis of pasted HTML never leaves your browser at all.
Last reviewed by the A2Z.Tools team against the sources listed above.
