¿Qué es el DOM? Document Object Model explicado
El DOM es el árbol de una página web en la memoria del navegador. Cómo se construye, cómo lo cambia JavaScript y cómo afecta su tamaño a la velocidad.
¿Qué es el DOM?
El Document Object Model (DOM) es la representación en memoria que hace el navegador de una página web. Al analizar el HTML, el navegador construye un árbol de nodos (elementos, texto y atributos), y los scripts usan la API del DOM para leer y cambiar la estructura, el estilo y el contenido de ese árbol. Según MDN, el DOM es una API web y no forma parte del propio lenguaje JavaScript.
Cómo construye el navegador el DOM
El navegador convierte los bytes del HTML en caracteres, luego en tokens y luego en objetos, y enlaza los objetos en un árbol que refleja las relaciones padre-hijo del marcado. Hace lo mismo con el CSS y construye otro árbol, el CSSOM. Son dos estructuras independientes que el navegador combina para decidir qué pintar, por eso una página no puede renderizarse antes de conocer su CSS. El DOM no es una copia literal de tu código fuente: conserva los espacios en blanco como nodos de texto, y los scripts pueden añadir, mover o quitar nodos después de la carga, así que el DOM que ves en las DevTools puede diferir de «ver código fuente».
Nodos, elementos y la API
Cada objeto del árbol es un nodo. El elemento es el tipo más habitual, pero el texto y los atributos también son nodos. El objeto document es la raíz desde la que partes. Toma este marcado:
<body>
<h1>Pricing</h1>
<p class="note">Billed monthly</p>
</body>Tres líneas de JavaScript lo seleccionan, lo cambian y reaccionan a él:
const note = document.querySelector(".note"); // seleccionar el primer elemento que coincide
note.textContent = "Billed yearly"; // cambiar su texto
note.addEventListener("click", () => note.remove()); // reaccionar a un clic y luego quitarloLos enfoques de renderizado se diferencian sobre todo en dónde se construye el DOM. En una aplicación de una sola página, JavaScript crea la mayor parte en el navegador. Con renderizado en el servidor, el servidor envía HTML, el navegador construye el DOM a partir de él y la hidratación engancha después los manejadores de eventos.
¿Cuándo está listo el DOM?
DOMContentLoaded se dispara cuando el HTML está completamente analizado y se han ejecutado los scripts diferidos. No espera a imágenes, subframes ni scripts async; el evento posterior load marca la página totalmente cargada. MDN señala que usar load donde bastaría DOMContentLoaded es un error común. Los scripts que necesitan elementos ya existentes deben usar defer, esperar a DOMContentLoaded o comprobar antes document.readyState.
El DOM y la velocidad de la página
Cada cambio en el DOM puede provocar trabajo de estilos, maquetación y pintado, y el coste crece con el tamaño del árbol. Lighthouse avisa cuando el body tiene más de unos 800 nodos y marca un error por encima de unos 1.400. Los árboles grandes ralentizan el recálculo de estilos y la maquetación, y los selectores amplios como querySelectorAll("li") pueden mantener miles de referencias a nodos en memoria. Eso se nota en la capacidad de respuesta y, por tanto, en Interaction to Next Paint (INP). Además, los elementos insertados tarde sin espacio reservado desplazan el contenido y perjudican el Cumulative Layout Shift.
Errores comunes
- Escribir entrada del usuario con
innerHTML. MDN lo califica como probablemente el vector más común de cross-site scripting. UsatextContentpara texto plano. - Layout thrashing. Alternar lecturas del DOM como
offsetWidthcon escrituras de estilo en un bucle obliga al navegador a recalcular la maquetación en cada vuelta. Agrupa primero las lecturas y haz después las escrituras. - Consultar demasiado pronto. Un script en
<head>sindeferse ejecuta antes de que exista el body, así quequerySelectordevuelvenull. - Marcado profundo y lleno de envoltorios. Aplana el anidamiento y usa flexbox o grid en lugar de contenedores extra.
- Renderizarlo todo de entrada. Las listas largas y las secciones ocultas añaden nodos que nadie ve aún. Cárgalos de forma diferida o usa
content-visibility.
El DOM en las pruebas y la monitorización
Una prueba de carga a nivel de protocolo, como una ejecutada con JMeter, envía peticiones HTTP y nunca construye un DOM, así que no te dice lo pesada que es una página para el navegador. Para eso necesitas un navegador real. El LoadFocus Core Web Vitals Checker muestra datos de campo de una URL, incluida la capacidad de respuesta, y Page Speed Monitoring ejecuta auditorías Lighthouse programadas desde 25 regiones en la nube (Lighthouse es la herramienta detrás del aviso de tamaño del DOM mencionado arriba). Para mejorar el INP, lee How to Optimize Interaction to Next Paint (en inglés) y, para configurar alertas, How to Monitor Core Web Vitals (en inglés).
Preguntas frecuentes: Document Object Model
¿Es el DOM parte de JavaScript?
No. El DOM es una API web que proporcionan los navegadores. JavaScript es el lenguaje más habitual para llamarla, pero el DOM se define por separado.
¿Cuál es la diferencia entre el DOM y el código fuente HTML?
El código fuente es el texto que envía tu servidor. El DOM es el árbol vivo que el navegador construye a partir de él. Los scripts pueden cambiar el DOM tras la carga, así que las DevTools pueden mostrar nodos que no aparecen en «ver código fuente».
¿Cuántos nodos del DOM son demasiados?
Lighthouse avisa a partir de unos 800 nodos en el body y marca un error en torno a 1.400. Son umbrales orientativos, no límites estrictos, y una página puede ser lenta por debajo de ellos si sus selectores y su maquetación son costosos.
¿Cuál es la diferencia entre DOMContentLoaded y load?
DOMContentLoaded se dispara cuando el HTML está analizado y los scripts diferidos se han ejecutado, sin esperar a imágenes ni scripts async. El evento load llega más tarde, cuando la página está totalmente cargada.
¿Por qué es arriesgado innerHTML?
Interpreta una cadena como HTML, así que una entrada de usuario sin sanear puede ejecutar JavaScript malicioso mediante atributos como onerror. Usa textContent cuando el contenido sea texto plano.
¿Afecta el tamaño del DOM a las Core Web Vitals?
Puede hacerlo. El trabajo costoso de estilos y maquetación que provoca un DOM grande ralentiza las interacciones, lo que cuenta en el INP, y los elementos insertados tarde pueden desplazar el diseño.
Términos relacionados
- First Contentful Paint (FCP): definición, umbrales y soluciones
- Image Size: Definición, Optimización Web, Mejores Prácticas
- ¿Qué es la monitorización de infraestructura?
- Interaction to Next Paint (INP): definición, umbrales y cómo mejorarlo
- ¿Qué es JMeter?
- Largest Contentful Paint (LCP): definición, umbrales y soluciones
- ¿Qué es la latencia?
- ¿Qué es el lazy loading (carga diferida)?
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.