Cómo funciona un navegador

 (howbrowserswork.com)
67 puntos por GN⁺ 2026-01-06 | 1 comentarios | Compartir por WhatsApp
  • Guía de aprendizaje interactiva creada para que ingenieros web y usuarios en general puedan entender de forma intuitiva cómo funciona internamente un navegador
  • Visualiza paso a paso el proceso desde escribir en la barra de direcciones hasta la creación de la solicitud HTTP, la resolución DNS, la conexión TCP, el parsing de HTML, la construcción del DOM y el pipeline de renderizado
  • Cada etapa está compuesta por ejemplos que se pueden escribir o manipular directamente, lo que permite experimentar en la práctica la comunicación de red y el proceso de renderizado
  • Muestra con claridad el papel del DOM y la diferencia entre las etapas de Layout–Paint–Composite, permitiendo ver visualmente qué elementos afectan el rendimiento
  • Material para aprender de forma estructurada conceptos clave dirigido a desarrolladores que quieran estudiar la arquitectura del navegador o entender la optimización del rendimiento web

Descripción general

  • Esta guía fue creada para quienes usan la web todos los días pero no entienden con claridad cómo funciona un navegador
    • Busca compensar las limitaciones de materiales existentes que suelen ser demasiado técnicos o demasiado superficiales
    • Está diseñada para que los detalles técnicos puedan aprenderse de manera intuitiva mediante pequeños ejemplos interactivos
  • Se omiten la versión de HTTP, SSL/TLS, los detalles internos de DNS y otros aspectos, y está organizada de forma concisa alrededor de los conceptos esenciales
  • El proyecto está publicado como código abierto y se pueden proponer mejoras a través de GitHub

El navegador y la URL

  • Todas las cadenas que el usuario escribe en la barra de direcciones se convierten internamente en una URL
  • Después de escribir y presionar Enter, se ofrece una interfaz práctica para ver directamente el proceso de conversión

Convertir una URL en una solicitud HTTP

  • El navegador primero confirma la URL exacta que va a visitar y luego envía una solicitud HTTP al servidor
  • Un ejemplo de encabezados de la solicitud es el siguiente 
    Host: example.com
Accept: text/html
  • El encabezado Host sirve como identificador del servidor al que se enviará la solicitud

Resolver la dirección del servidor (DNS)

  • El navegador no puede usar directamente un nombre de dominio como example.com
    • Necesita convertirlo en una dirección IP mediante el sistema DNS para poder comunicarse con el servidor
  • Al escribir un dominio en el campo de entrada, se puede ver el resultado de la resolución DNS (dirección IP)

Establecer la conexión TCP

  • Después de obtener la IP mediante DNS, el navegador establece una conexión confiable con el servidor usando el protocolo TCP
  • La conexión se establece mediante el proceso de handshake de 3 pasos
    1. SYN: el cliente solicita la conexión
    2. SYN-ACK: el servidor responde y confirma
    3. ACK: el cliente hace la confirmación final
  • TCP mantiene una comunicación estable gracias a la garantía de orden de los datos y la retransmisión
  • Es posible experimentar con la estabilidad de la transmisión cortando la red o manipulando paquetes

Solicitud y respuesta HTTP

  • Tras establecer la conexión TCP, el navegador envía la solicitud HTTP y el servidor devuelve la respuesta HTTP
  • El recorrido de la solicitud y la respuesta se muestra visualmente, permitiendo observar el flujo de paquetes
  • Cuando llega la respuesta, el navegador separa los encabezados del cuerpo y comienza a renderizar el HTML

Parsing de HTML y creación del árbol DOM

  • El navegador entrega los bytes de HTML al parser para construir el árbol DOM
  • Si se introduce HTML de ejemplo, se puede ver visualmente cómo etiquetas como <h1> y <p> se convierten en nodos DOM
  • El parsing se realiza en streaming, por lo que los nodos pueden crearse incluso antes de que llegue todo el documento
  • Cuando aparece una etiqueta <script>, el parsing se detiene temporalmente para ejecutar el script
  • El DOM terminado se combina con CSS para formar el render tree

La importancia del DOM

  • El DOM (Document Object Model) es el modelo del documento en la memoria del navegador y es
    la estructura central compartida por el parser de HTML, el motor de selectores CSS y el runtime de JavaScript
  • Los cambios en el DOM se reflejan de inmediato en el layout, los estilos y la interacción del usuario
  • Se ofrece una vista previa donde al modificar código JavaScript, los cambios en el DOM se reflejan en tiempo real

Layout, Paint, Composite

  • Cuando el DOM y el CSS están listos, el navegador ejecuta el pipeline de renderizado
    • Layout (Reflow): calcula el tamaño y la posición de los elementos
    • Paint: rellena los píxeles
    • Composite: combina capas en la GPU
  • Un cambio de color vuelve a ejecutar solo Paint, pero un cambio de tamaño vuelve a ejecutar tanto Layout como Paint
  • Se puede comprobar con un clic si cada etapa se vuelve a ejecutar o no
  • Muestra visualmente que las páginas con muchas operaciones de Layout se renderizan más lentamente

Resumen

  • Una guía que permite aprender experimentando directamente todo el proceso, desde escribir una dirección hasta el renderizado
  • Al completar todas las etapas, es posible formar un modelo mental claro de cómo funciona un navegador
  • El proyecto es de código abierto, y se pueden proponer mejoras mediante issues o Pull Requests en GitHub

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-01-06
Comentarios en Hacker News

  • No todos los navegadores tuvieron DOM desde el principio
    Al inicio existían WorldWideWeb (Nexus, 1990), Erwise (1992), ViolaWWW (1992), Lynx (1992), NCSA Mosaic (1993), Netscape 1.0 (1994) e IE 1.0 (1995)
    Lynx sigue siendo hasta hoy, intencionalmente, un navegador sin DOM
    AOL 1.0–2.0 usaba un motor estático (AOLPress) sin objetos programables
    La posibilidad de interactuar con el DOM llegó a partir de Netscape 2.0 (1995), IE 3.0 (1996), AOL 3.0 (1996) y Opera 3.0 (1997)
    Después, Netscape 4.0 (document.layers) e IE 4.0 (document.all) usaron modelos distintos
    El primer DOM estándar fue W3C DOM Level 1 (1998): IE 5.0 (1999) lo soportó parcialmente, y Konqueror 2.0 (2000) junto con Netscape 6.0 (2000) empezaron a soportarlo por completo
    Safari 1.0 (2003), Firefox 1.0 (2004) y Chrome 1.0 (2008) soportaron el DOM estándar desde el inicio, y hoy siguen el WHATWG DOM Living Standard

    • El navegador Dillo también sigue teniendo una arquitectura sin DOM
      Como interpreta y renderiza directamente el texto HTML, su uso de RAM es muy bajo
    • Me pregunto si sería más preciso expresarlo como “el DOM en los navegadores modernos”

  • Es un proyecto genial
    Si eres lector de HN, también vale la pena ver High-Performance Browser Networking y Every Layout
    Ambos son recursos excelentes que tratan a fondo el rendimiento web y la estructura de CSS

    • HPBN es de verdad un libro muy bien escrito
      En el capítulo 4 logré entender la estructura de frames de TLS, y eso me permitió depurar problemas de latencia en mi trabajo anterior
      También fue interesante la parte sobre los trade-offs al ajustar el tamaño de los frames TLS
      Probablemente no sea algo que uno use seguido, pero me hizo ver que es posible hacer ajustes finos a nivel de red
    • Gracias por el enlace de HPBN, es un material realmente interesante

  • Es un enfoque interesante, como experimentar browser.engineering sin instalar nada
    Cuando se muestran ejemplos del navegador y del servidor, creo que sería más fácil de entender si se agregaran íconos visuales (por ejemplo, escritorio/servidor)

    • Planeo agregar más secciones y detalles
      Por ahora estoy reuniendo feedback, y la sugerencia de los íconos me parece una buena idea que voy a considerar

  • Me gustó mucho, así que ya lo guardé en marcadores
    Pero sí se echa de menos el proceso de carga de recursos como imágenes, hojas de estilo y scripts a partir de HTML/DOM
    Esa parte es importante para entender por qué a veces se rompe el estilo de una página o faltan imágenes

    • Lo omití a propósito para mantener la simplicidad
      Estoy pensando cómo agregar esos bloques sin que se vuelva demasiado complejo

  • Cuando la ventana del navegador es angosta (menos de 1170px), hay un problema donde la sección de la tabla de contenido se superpone al cuerpo del texto

    • Lo estoy corrigiendo

  • Estaría bien pulir un poco más la lógica de análisis de URL
    La mayoría de los usuarios no tendrá problemas, pero el navegador también maneja de forma especial los esquemas de protocolo distintos de https:// o http://
    Sería bueno capturar también esos casos
    Referencia: List of URI schemes

  • Excelente proyecto
    Me pregunto si como siguiente paso planeas agregar detalles del proceso de reflow

  • Es una lástima que más de la mitad de la página esté dedicada a las solicitudes de red
    En realidad, la parte compleja del navegador está en el pipeline de análisis y renderizado

    • Planeo cubrir con más detalle la parte del motor de renderizado
      Como no sabía en qué sección profundizar, primero lo publiqué y ahora estoy recogiendo feedback
    • El DOM también puede verse como parte del pipeline de renderizado

  • Puede que sea una pregunta fuera de lugar, pero me pregunto qué pasaría si se eliminara por completo la búsqueda DNS y todo funcionara solo con nombres de dominio legibles para humanos

    • Y una idea todavía más rara: ¿qué tal si se enrutara usando direcciones Ethernet en lugar de direcciones IP?
      Sería como convertir todo internet en un único switch gigantesco
      Recuerdo haber visto un texto de un fundador de Tailscale con una idea parecida

  • Muy buen trabajo