En este artículo explicamos qué significa que una página tenga un DOM excesivo según Lighthouse 13 y las DevTools de Chrome, cómo medirlo de verdad, por qué afecta sobre todo a la capacidad de respuesta (INP) y qué técnicas reducen el trabajo del navegador y cuáles no, aunque se repitan mucho.
Qué mide Lighthouse hoy: el insight «Optimize DOM size»
Hasta Lighthouse 12 existía la auditoría «Avoid an excessive DOM size» (dom-size). En Lighthouse 13, publicado en octubre de 2025, se sustituyó por el insight «Optimize DOM size» (dom-size-insight), el mismo que aparece en el panel Performance de las DevTools. El insight informa de tres datos:
- Total de elementos del DOM. Incluye los shadow roots e ignora los nodos que no son elementos y el contenido de los
<iframe>. - Profundidad máxima del árbol.
- El elemento con más hijos.
Los umbrales han cambiado de enfoque. La auditoría antigua avisaba cuando el body tenía más de unos 800 nodos y daba error a partir de unos 1.400 (documentación de la auditoría). El insight nuevo ya no suspende por contar elementos: según su documentación, falla cuando detecta un recálculo de estilos o un layout de más de 40 ms que afecta a muchos elementos (más de 300 en el recálculo de estilos, más de 100 objetos de layout). Es decir, ya no penaliza un DOM grande por sí mismo, sino que ese DOM haga lento el trabajo de renderizado. Los 800 y 1.400 nodos siguen siendo una orientación útil, pero no son el criterio del insight.
Por qué importa: estilos, layout e INP
El tamaño del DOM no afecta tanto a la descarga, porque el HTML se comprime bien, como al trabajo que hace el navegador cada vez que algo cambia. Cuantos más elementos, más caro es calcular qué reglas CSS se aplican a cada uno (recálculo de estilos) y dónde va cada caja (layout). El equipo de Chrome describe el tamaño del DOM como uno de los mejores indicadores de cuánto tardarán los estilos y el layout. Un DOM grande también consume más memoria.
Donde más se nota es en la Interaction to Next Paint (INP), que sustituyó a FID como Core Web Vital en marzo de 2024. INP mide el tiempo desde que el usuario interactúa hasta que se pinta el siguiente fotograma. Si la interacción modifica el DOM (abrir un menú, filtrar un listado), el recálculo de estilos y el layout que provoca entran en ese tiempo, y con un DOM grande pueden ser muy costosos, como explica el artículo de web.dev sobre tamaño del DOM e interactividad. El objetivo es un INP de 200 ms o menos en el percentil 75 (umbrales de INP). Lo desarrollamos en nuestro artículo sobre capacidad de respuesta e interactividad.
Cómo medir el DOM de verdad
El panel Elements de las DevTools no tiene ningún contador de nodos. Estas son las formas fiables de medirlo:
1. Desde la consola
Con la página cargada, en la consola de DevTools:
document.querySelectorAll('*').lengthDevuelve el número de elementos (no cuenta nodos de texto ni comentarios), igual que el insight, con una diferencia: querySelectorAll no entra en los shadow roots. Si además quieres la profundidad máxima y el elemento con más hijos, este fragmento lo calcula:
const elementos = document.querySelectorAll('*');
let maxProfundidad = 0;
let masHijos = null;
for (const el of elementos) {
let profundidad = 0;
for (let p = el; p.parentElement; p = p.parentElement) profundidad++;
if (profundidad > maxProfundidad) maxProfundidad = profundidad;
if (!masHijos || el.children.length > masHijos.children.length) masHijos = el;
}
console.log({ total: elementos.length, maxProfundidad, hijos: masHijos.children.length }, masHijos);2. Con el Performance monitor
En DevTools, abre el menú de comandos (Cmd+Shift+P en macOS, Ctrl+Shift+P en Windows y Linux), escribe «Performance monitor» y selecciona Show Performance monitor. La métrica DOM Nodes muestra en tiempo real el número de nodos, junto a los layouts y recálculos de estilo por segundo (documentación). Es la forma más cómoda de ver cómo crece el DOM al hacer scroll infinito, abrir menús o cargar más resultados.
3. Con Lighthouse o el panel Performance
Graba una carga o una interacción en el panel Performance y revisa el insight «Optimize DOM size». Además de los tres datos del DOM, resalta en la traza los recálculos de estilo y layouts que el tamaño del DOM probablemente ha empeorado. Esto es lo que te dice si el problema es real, no solo el recuento.
Técnicas que sí reducen el DOM o su coste
Simplificar el marcado y quitar envoltorios
La forma principal de reducir el DOM es eliminar anidamiento innecesario: div que solo envuelven a otro div, contenedores puestos para centrar algo que ya resuelve flexbox o grid. En React y Vue, los fragmentos permiten devolver varios elementos sin añadir un envoltorio.
En WordPress, la fuente más habitual de DOM excesivo son los maquetadores visuales: cada sección, columna y widget añade sus propias capas de envoltorio, y una página larga montada así multiplica los elementos. Lo mismo pasa con los megamenús que incluyen todo el árbol de navegación en cada página, los sliders con decenas de diapositivas y los listados que pintan todos los elementos de golpe. Antes de optimizar nada, cuenta los elementos de la plantilla vacía y compáralos con los de la página completa; así sabes qué parte viene del tema y qué parte del contenido.
Paginar en vez de pintarlo todo
Un listado con 500 productos o comentarios en una sola página es un DOM de miles de elementos. Paginar, o cargar más bajo demanda cuando el usuario lo pide, mantiene el DOM inicial acotado. Con el scroll infinito, ojo: si nunca se eliminan los elementos que ya han salido de la pantalla, el DOM no para de crecer.
Virtualizar listas largas
Cuando hace falta una lista larga y continua (tablas de datos, buscadores con muchos resultados), la virtualización solo mantiene en el DOM las filas visibles y unas pocas de margen, y las recicla al hacer scroll. La documentación del insight cita el virtual scrolling del CDK de Angular y las bibliotecas de windowing en React; una opción independiente del framework es TanStack Virtual.
Añadir al DOM lo que está oculto cuando se necesita
Pestañas, acordeones, modales o submenús que empiezan ocultos no necesitan estar en el DOM desde el principio. Generarlos cuando el usuario los abre reduce el DOM inicial. Tiene coste: hay que cuidar la accesibilidad y que el contenido importante para SEO no dependa de una interacción.
content-visibility: auto
La propiedad CSS content-visibility: auto no quita nodos, pero permite al navegador saltarse el layout y el pintado de los bloques que están fuera de pantalla hasta que se acercan al viewport. El contenido sigue en el DOM, así que sigue siendo buscable y navegable. Conviene acompañarla de contain-intrinsic-size para reservar un tamaño estimado y que la barra de scroll no salte:
.listado > article {
content-visibility: auto;
contain-intrinsic-size: auto 400px;
}Con auto delante del valor, el navegador recuerda el tamaño real del bloque una vez que lo ha renderizado. Según web.dev, la propiedad funciona en Chrome y Edge desde la versión 85, Firefox 125 y Safari 18, y es Baseline desde septiembre de 2025.
Reducir el coste de los estilos
Si no puedes reducir el número de elementos, sí puedes abaratar cada recálculo: selectores CSS más simples y menos reglas que dependan de la estructura. La documentación del insight también menciona los Web Components: el shadow DOM no reduce el tamaño del DOM, pero sí acota el coste de recalcular estilos.
Lo que no reduce el DOM
Hay recomendaciones que circulan asociadas a este problema y que no lo resuelven:
- Minificar o combinar CSS y JavaScript: reduce bytes de descarga, no elementos del DOM. Y combinar archivos ha perdido sentido con HTTP/2 y HTTP/3.
- Sacar estilos y scripts en línea a archivos externos: un atributo
styleno crea nodos, y un<style>o<script>en línea es un solo elemento. El efecto en el tamaño del DOM es despreciable. - Lazy load de imágenes:
loading="lazy"retrasa la descarga de la imagen, pero el<img>está en el DOM igualmente. Es útil para el peso de la página, no para el tamaño del DOM. Lo explicamos en el artículo sobre lazy load.
Por dónde empezar
- Mide el total de elementos, la profundidad y el elemento con más hijos en las plantillas principales (portada, listado, ficha, artículo).
- Graba en el panel Performance las interacciones habituales (menú, filtros, buscador) y mira si el insight señala recálculos de estilo o layouts largos.
- Ataca primero lo que más elementos aporta: envoltorios del tema o del maquetador, listados sin paginar y menús que pintan todo el árbol.
- Comprueba el efecto en INP con datos de campo, no solo en el laboratorio. Tienes más contexto en nuestra guía técnica de Core Web Vitals en WordPress.