Ya tienes el mapa de lo que ocurre entre que escribes una URL y el servidor responde. Pero lo que llega de vuelta es texto: un documento HTML. Ahora entra en juego el navegador, que tiene que convertir ese texto en la página que ves. Este proceso tiene nombre, pasos concretos y, si lo entiendes, te explica por qué unas páginas cargan rápido y otras no.
Un apunte antes de empezar, porque a partir de aquí nombramos tres lenguajes. Una página web se hace con tres: HTML (la estructura: qué hay en la página y qué es cada cosa), CSS (el aspecto: cómo se ve) y JavaScript (el comportamiento: qué pasa cuando interactúas). Todavía no los has escrito —los aprenderás en los niveles 1 y 2—; aquí solo necesitas saber qué hace cada uno para seguir cómo el navegador los junta en lo que ves.
Del texto al árbol: parsear el HTML#
En cuanto el navegador recibe los primeros bytes del HTML, empieza a parsearlo: lee el texto carácter a carácter y construye un árbol de objetos en memoria. Ese árbol es el DOM (Document Object Model).
Cada etiqueta se convierte en un nodo. Un <div> que contiene un <p> se convierte en un
nodo padre con un nodo hijo. Los textos dentro de las etiquetas también son nodos. El resultado
es una jerarquía que refleja la estructura del documento.
Lo importante: el DOM no es el fichero HTML. Es la representación viva en memoria que el navegador mantiene mientras la página está abierta. Cuando desde JavaScript cambias el DOM, estás modificando esa estructura en memoria —la página cambia en vivo— sin tocar el fichero original del servidor.
El árbol paralelo: el CSSOM#
Mientras parsea el HTML, el navegador va encontrando estilos: la etiqueta <style>, los
atributos style="..." inline, y referencias a ficheros .css externos que descarga en paralelo.
Con todo eso construye el CSSOM (CSS Object Model): otro árbol, esta vez de reglas de estilo.
El CSSOM es bloqueante para el pintado: el navegador no pinta nada hasta tener el CSSOM
completo, porque sin saber los estilos no puede saber qué aspecto tiene nada. Por eso un fichero
CSS grande en el <head> retrasa el momento en que el usuario ve algo.
Juntar los dos: el render tree#
Con el DOM y el CSSOM listos, el navegador los combina en el render tree: un árbol que contiene únicamente los nodos que hay que pintar, con sus estilos calculados aplicados.
Nota lo que queda fuera: los nodos con display: none no están en el render tree (no se
pintan). El <head> tampoco. Los nodos ocultos con visibility: hidden sí están —ocupan
espacio—, pero no se ven.
Calcular dónde va cada cosa: layout#
Con el render tree en la mano, el navegador entra en la fase de layout (también llamada
reflow): calcula la posición y el tamaño exactos de cada caja en la pantalla. ¿Cuánto
mide este párrafo? ¿Dónde empieza este <div>? ¿Cuántas líneas ocupa este texto?
Este cálculo es costoso porque todo puede afectar a todo: si un elemento crece, puede empujar a su vecino, que a su vez empuja al siguiente. Esto importa en el contexto de JavaScript: cada vez que modificas el DOM o los estilos desde JS, el navegador puede tener que repetir el layout para los elementos afectados. Si lo haces en un bucle sobre cien elementos, pagas ese coste cien veces seguidas, y el resultado es una página que se nota lenta o que se congela al interactuar.
Pintar píxeles: paint y composite#
Tras el layout, el navegador sabe dónde va cada cosa. Ahora toca pintarla: convertir esa geometría en píxeles reales. Esta fase se llama paint, y cubre colores, bordes, sombras, texto.
Por encima de paint hay una fase más: composite. La página puede dividirse en capas
independientes (un <video>, un elemento con transform, un scroll independiente), que se
pintan por separado y se componen al final como transparencias apiladas. Esto es lo que hace
que animaciones de transform y opacity sean baratas: solo tocan la fase composite, sin
disparar layout ni paint.
Dónde encaja JavaScript#
El motor JavaScript del navegador —V8 en Chrome y Edge, SpiderMonkey en Firefox— es un inquilino que comparte hilo con el renderizado. Eso tiene una consecuencia directa: mientras JavaScript está ejecutando, el renderizado espera. Y al revés: mientras el navegador pinta, el JS espera.
Esto explica por qué un <script src="app.js"> colocado en el <head> sin atributos es
problemático: el parser llega a esa línea, para el parseo del HTML, espera a que el
fichero llegue de la red, lo ejecuta entero y solo entonces sigue construyendo el DOM. Si
app.js tarda —porque es grande o la red es lenta— el usuario ve la pantalla en blanco durante
todo ese tiempo.
La solución que se usa hoy:
defer: el fichero se descarga en paralelo sin detener el parser, y se ejecuta cuando el HTML está completamente parseado, en orden. Es el atributo correcto para la mayoría de scripts.async: también descarga en paralelo, pero ejecuta en cuanto llega, sin esperar al DOM ni respetar el orden. Solo tiene sentido para scripts completamente independientes (analíticas, tracking).
El patrón histórico de poner <script> al final del <body> era un workaround para lo mismo:
si el script está al final, el HTML ya está parseado cuando llega a él. Con defer eso ya no
hace falta.
Una nota honesta: hoy React, Vue y otros frameworks generan mucho JavaScript que hay que gestionar bien para no bloquear el pintado inicial. “Tiempo hasta el primer píxel visible” (First Contentful Paint) es una métrica real que se mide y se optimiza en proyectos profesionales. Ahora que sabes por qué existe, entenderás las decisiones que rodean a esa métrica cuando llegues al Nivel 7.
Comprueba lo que sabes#
Pregunta 1 de 5