Every click, every menu opening and every filter change forces the browser to recalculate styles and update the layout. How expensive this work is depends directly on the size of the Document Object Model (DOM) -- the tree of nodes from which the browser builds every page. A bloated DOM makes every single interaction more expensive and is therefore one of the main causes of weak Interaction to Next Paint scores. With Lighthouse 13 (October 2025), Google reweighted the topic: the old audit that merely counted nodes has become the insight 'Optimize DOM size', which evaluates actual style and layout work above 40 milliseconds (Chrome for Developers). This article explains the thresholds, shows why large category lists and generic page builders bloat the DOM, and describes the techniques that slim the tree back down.
Key takeaways
- Every interaction forces the browser to recalculate styles and layout for the affected nodes - on the same main thread that handles input. A median mobile page holds 594 DOM elements, and 1,716 at the 90th percentile (HTTP Archive Web Almanac, 2024).
- Since Lighthouse 13 in October 2025, the DOM size insight no longer counts nodes but measures work: it fires when a style or layout recalculation takes longer than 40 milliseconds (Chrome for Developers).
- The node metrics still serve as orientation: Lighthouse warns from 800 nodes, reports an error from roughly 1,400 nodes, and flags a tree depth above 32 levels or more than 60 child nodes per element (Google Lighthouse).
- Trees get bloated mainly by unbounded lists and wrapper-div chains from generic page builders. Pagination caps the rendered entries, virtualization keeps only visible rows plus a buffer in the DOM - no content is lost either way.
- content-visibility: auto skips style and layout work outside the viewport; in one example initial rendering time dropped from 232 to 30 milliseconds (web.dev). The nodes stay in the tree, and contain-intrinsic-size reserves their space.
- Grid and Flexbox replace whole wrapper levels, and nodes set to display:none still count and should be removed. A node budget per template in the pipeline keeps the size down, since every new feature otherwise adds nodes unnoticed.
Why a large DOM makes every interaction expensive
The DOM is the tree structure with which the browser represents an HTML document in memory. Every element, every text node and every attribute is a node in this tree. On every interaction the browser has to determine which nodes are affected, recalculate their styles (style recalculation) and then work out their position and size (layout). The more nodes the tree contains and the more deeply it is nested, the longer this work takes -- and the longer the user waits for the visible response. This very wait time feeds into Interaction to Next Paint.
The HTTP Archive Web Almanac shows the typical scale: in 2024 a median mobile page consists of 594 DOM elements, and at the 90th percentile it is already 1,716 elements (HTTP Archive Web Almanac, 2024). The peaks lie far above that. How heavily a single action can burden the browser is illustrated by an example from the web.dev documentation: there, a single interaction triggered a style recalculation of 2,547 DOM elements (web.dev). At such a volume, the work per click quickly adds up to a noticeable delay.
The relationship is direct: a large DOM lengthens the duration of style and layout calculations, and those calculations run on the same main thread that also processes user input. As long as the browser is busy recalculating thousands of nodes, it cannot paint the next frame. That is the core of the problem Core Web Vitals optimization addresses: not raw loading time, but responsiveness on every subsequent action, decides the perceived speed.
Style recalculation and layout -- two separate phases
From counting nodes to an insight: what Lighthouse 13 changes
Up to Lighthouse 12, DOM scoring was a pure counting game. The 'Avoid an excessive DOM size' audit raised the alarm as soon as a page exceeded certain node counts -- regardless of whether those nodes caused any expensive work at all. With Lighthouse 13 in October 2025, Google fundamentally changed this logic. The static audit has become the insight 'Optimize DOM size', which no longer merely counts nodes but measures the actual style and layout work (Chrome for Developers).
The new insight only fires when a layout or style recalculation lasts longer than 40 milliseconds (Chrome for Developers). A large layout update is one that affects more than 100 layout objects; a large style recalculation covers more than 300 elements (Chrome for Developers). The advantage of this change: a page with many but static nodes that trigger no expensive recalculation is no longer wrongly penalized. Conversely, the insight puts the spotlight exactly on the cases where the DOM genuinely slows interactivity.
| Aspect | Old audit (up to Lighthouse 12) | New insight (from Lighthouse 13) |
|---|---|---|
| Basis of evaluation | Static number of DOM nodes | Measured style and layout work |
| Trigger | Exceeding fixed node thresholds | Recalculation longer than 40 ms (Chrome for Developers) |
| Large layout update | Not considered separately | More than 100 layout objects (Chrome for Developers) |
| Large style recalculation | Not considered separately | More than 300 elements (Chrome for Developers) |
| Focus | Symptom (many nodes) | Cause (expensive work per interaction) |
In practice this means a shift from symptom to cause. The raw node count remains a useful early indicator -- a page with several thousand nodes will almost inevitably trigger expensive recalculations somewhere. But the insight forces you to look at the elements actually affected per interaction. This very measurement stands at the beginning of any structured performance analysis, before a single line of markup is changed.
The thresholds at a glance
Even though the insight focuses on measured work, the classic node thresholds remain a valuable orientation -- they still appear in the Lighthouse report and in the DOM panel of the developer tools. Four metrics matter, and each describes a different kind of bloat.
Total number of nodes
Lighthouse warns from 800 nodes and reports an error from around 1,400 nodes per page (Google Lighthouse). Above that, the risk of expensive recalculations rises sharply.
Tree depth
If the tree is nested more than 32 levels deep, the structure counts as excessively nested (Google Lighthouse). Deep trees make style inheritance and resolution more expensive.
Children per element
If a single element contains more than 60 child nodes, Lighthouse flags it (Google Lighthouse). Such wide nodes often arise from long, unfiltered lists.
Style and layout work
The 'Optimize DOM size' insight fires as soon as a recalculation lasts longer than 40 milliseconds (Chrome for Developers) -- the actual proof of impact.
These values are not arbitrary limits but experience-based markers for the point where rendering work becomes noticeable. The order matters: first ask the insight and the field measurement which interaction is actually expensive, then use the node metrics to locate the cause in the markup. Anyone who blindly counts nodes easily optimizes in the wrong place.
Where the DOM gets bloated: category lists and page builders
Two patterns cause the vast majority of bloated trees. The first is large lists without limits: category pages with hundreds of products, endless tables, comment lists or directories. Each individual product tile quickly consists of a dozen nodes -- image, title, price, badges, buttons, wrappers. With 120 items on one page, that alone is well over a thousand nodes for the list, and the surrounding list container easily exceeds the limit of 60 children per element.
The second pattern is the wrapper-div soup of generic page builders. To stay flexible, many builder systems wrap every section, every row, every column and every element in several additional container divs. A conceptually simple section thereby turns into five or six levels of nesting that serve no visible purpose but drive the tree depth up. Together, these two patterns -- wide lists and deep nesting -- produce exactly the trees that trigger expensive recalculations on every interaction.
- Category and search-result pages that render all hits at once instead of paginating
- Generic page builders that nest every block in several wrapper divs
- Carousels and sliders that keep all slides in the DOM at once, even though only one is visible
- Hidden elements (display:none) that remain in the tree and continue to be counted
- Extensive mega menus that write the entire navigation into the DOM up front
- Tables with hundreds of rows rendered in full instead of only the visible section
A large DOM is rarely the result of a decision -- it grows unnoticed, tile by tile and wrapper by wrapper. The fastest node is the one the browser never has to build in the first place.
Pagination and virtualization: fewer nodes in the tree
The most effective lever against wide lists is not to write all elements into the DOM in the first place. Pagination limits the number of rendered entries per page to a manageable amount -- say 24 per page instead of 300 products at once. That reduces the node count immediately and substantially, without losing any content. Where a continuous list is genuinely desired, infinite scrolling with recycling achieves the same: new entries are loaded in while scrolling, and entries scrolled far out of view are removed from the DOM.
The most thorough form is virtualization (also called windowing). Here the browser keeps only the currently visible rows plus a small buffer in the DOM; everything outside the viewport exists only as a placeholder with reserved height. A list with a theoretical ten thousand entries thus permanently occupies only a few dozen nodes. For tables, search results and long feeds, virtualization is the most robust answer to a growing DOM -- a core building block of frontend optimization for data-intensive interfaces.
Practical tip: tackle the most expensive template first
content-visibility: skip rendering work
Where content must remain in the DOM but is not immediately visible, the CSS property content-visibility: auto helps. It lets the browser skip the rendering -- style calculation and layout -- for regions outside the viewport at first and catch up only when they come into view. The nodes stay in the tree, but the expensive work is dropped on the first load. In an example from the web.dev documentation, this cut the initial rendering time of a long page from 232 milliseconds to 30 milliseconds (web.dev).
The companion property contain-intrinsic-size is decisive. It gives the browser an estimated size for the not-yet-rendered regions so that the scrollbar stays stable and no layout shift occurs when scrolling into them. Without this hint, the late rendering would change the page height and worsen Cumulative Layout Shift -- how to avoid such shifts is covered in the article on avoiding layout shifts. Used correctly, content-visibility relieves the first frame without changing the structure or behavior of the page.
/* Skip rendering work for sections not yet visible.
contain-intrinsic-size reserves space so the scrollbar
stays stable (no layout shift). */
.section {
content-visibility: auto;
contain-intrinsic-size: auto 600px;
}
/* For long lists with uniform rows */
.product-row {
content-visibility: auto;
contain-intrinsic-size: auto 180px;
}content-visibility does not replace virtualization but complements it. Virtualization removes nodes from the DOM and thereby lowers the total count; content-visibility leaves the nodes in the tree but saves the rendering work for whatever is currently not on screen. For long, static content pages -- articles, documentation, FAQ stretches -- content-visibility is often the simpler and entirely sufficient solution.
Flatter markup and removing hidden nodes
Beyond quantity, structure matters. A flat tree with few, semantic elements is faster to recalculate than a deep chain of wrapper divs. Modern CSS layouts with grid and flexbox make many of the historically common nestings unnecessary: where three nested containers were once needed to achieve an arrangement, a single grid often suffices today. Every saved level reduces the tree depth and shortens style resolution for the nodes inside it.
Reduce wrappers
Container divs that wrap only a single child or merely set spacing can usually be removed entirely. Grid and flexbox handle the arrangement directly on the parent element.
Remove hidden nodes
Elements with display:none remain in the DOM and continue to count. Whatever is permanently unused -- old variants, hidden tabs with heavy content -- should be removed or loaded only on demand.
Semantics over div soup
A header, nav, main or article replaces several generic divs and improves accessibility at the same time. Fewer but more meaningful elements keep the tree clear and flat.
A lean DOM is conversion-relevant
A DOM-diet path in practice
A recurring pattern illustrates how the measures work together. Starting point: a category page of an online shop based on Shopware CE reports sluggish interactions during product filtering in the field data -- a common scenario in Shopware performance optimization. The DOM insight and the DevTools panel show the page at around 1,900 nodes, a tree depth of 38 levels and a style recalculation of 92 milliseconds per filter click (project experience). The cause: 120 product tiles on one page, each nested several times in wrapper divs.
The optimization path tackles three points. First, pagination limits the list to 24 products per page, which immediately lowers the list's node count. Second, a rework of the tile markup removes two superfluous wrapper levels per product and replaces them with a single grid, markedly reducing the tree depth. Third, content-visibility skips the rendering of tiles not yet in view. In sum the page drops to around 720 nodes, a depth of 12 levels and a style recalculation of 24 milliseconds -- without removing a single product or function (project experience). Comparable starting points recur in many projects across industries and template types.
The final validation in the field is important. Because the official field data updates as a rolling 28-day average, the effect of an optimization only becomes fully visible in the official values after several weeks. Until then, your own Real User Monitoring provides the faster feedback channel, and the DOM insight already confirms in the lab that the expensive recalculations have slipped below the 40-millisecond threshold.
Keeping DOM size low for good: budgets and monitoring
A DOM slimmed down once does not stay lean on its own. Every new feature, every additional widget and every extra row in a page builder adds nodes. That is why DOM size belongs in a performance budget: an upper limit for the number of nodes per template, checked in continuous integration on every deployment. If a change exceeds the budget, the pipeline alerts before the bloat goes live.
- Measure the node count per template and set a realistic budget per page type
- Paginate or virtualize category, search and list pages as a rule
- Regularly check wrapper divs for redundancy and replace them with grid/flexbox
- Set content-visibility for long, static content areas below the viewport
- Remove hidden and unused nodes (display:none, old variants) from the tree
- Monitor the DOM insight and the affected elements per interaction, per template
DOM size within the interplay of the vitals
Slimming the DOM also feeds into other optimization layers: reducing the amount of markup transferred benefits additionally from efficient text compression with Brotli and Zstandard, and speeding up navigations combines the lean DOM with the back/forward cache for instant backward jumps. A tight JavaScript budget likewise keeps the volume of dynamically generated nodes in check, as the article on JavaScript performance budgets shows. This combination of structure, delivery and budget control is a fixed part of our performance services.
We slim down the DOM on large catalog and list pages -- with pagination, virtualization, content-visibility and flatter markup -- to lower the interaction cost per click and raise INP field values. For an assessment of your DOM size and the resulting rendering load, we arrange a no-obligation initial consultation on Core Web Vitals optimization.