De la barra de direcciones a los píxeles: cómo carga un navegador una página web

Escribir example.com y presionar Enter parece algo instantáneo, pero ocurren varios pasos antes de que aparezca cualquier cosa en la pantalla. Cuando se empieza en el desarrollo web, términos como DNS, servidor, HTML, CSS y JavaScript pueden parecer temas separados. Este artículo los conecta en una sola secuencia, de modo que tengas un modelo mental al cual podrás añadir temas posteriores, desde APIs hasta el rendimiento de renderizado.

El proceso consta de cuatro etapas: encontrar el sitio, solicitarle contenido, recibir ese contenido y convertirlo en una página visible.

Etapa 1: Encontrar dónde se encuentra el sitio web

La gente identifica los sitios web por su nombre. Nombres como estos son fáciles de recordar:

example.com
google.com
youtube.com

No obstante, las computadoras en una red se dirigen entre sí mediante direcciones IP, identificadores numéricos como 203.0.113.10 para IPv4 o formas hexadecimales más largas para IPv6. Antes de que el navegador pueda comunicarse con un sitio, debe traducir su nombre a una dirección. Esa es la función del DNS, el Sistema de Nombres de Dominio.

Una buena forma de imaginar el DNS es la lista de contactos de tu teléfono: almacenas y buscas a las personas por nombre, y el teléfono busca su número por ti. Nunca necesitas memorizar los dígitos. El DNS hace lo mismo en la web: escribes un nombre de dominio y el DNS proporciona la dirección de la máquina que lo sirve.

En la práctica, la búsqueda se realiza de forma escalonada y con un alto nivel de caché. El navegador primero verifica su propio caché, luego el del sistema operativo, y solo entonces consulta a un resolvedor DNS, generalmente gestionado por su proveedor de Internet o un servicio DNS público. Si el resolvedor no conoce ya la respuesta, recorre la jerarquía DNS hasta encontrar los servidores responsables de ese dominio. Gracias al caché, un sitio que visitó recientemente suele resolverse casi de inmediato.

Etapa 2: Envío de la solicitud

Con una dirección IP en mano, el navegador puede ponerse en contacto con el servidor del sitio: una computadora cuya función es almacenar, generar y entregar los archivos y datos que necesita un sitio web.

Antes de que se transfiera cualquier contenido web, el navegador establece una conexión con ese servidor. En el caso de un sitio moderno https://, esto también implica un intercambio TLS, en el cual ambas partes acuerdan las claves de cifrado y el navegador verifica el certificado del servidor para asegurarse de que está comunicándose con el sitio real. Solo entonces el navegador envía una solicitud HTTP.

En su camino, la solicitud atraviesa muchas redes y dispositivos, como tu router, el equipo de tu proveedor y varios routers intermedios, antes de llegar al servidor. En esencia, la solicitud dice: “Por favor, envíame lo necesario para mostrar esta página”. También incluye detalles como la ruta exacta solicitada, los formatos soportados por el navegador y cualquier cookie relacionada con ese sitio.

Etapa 3: Recibir la respuesta

El servidor procesa la solicitud y responde con una respuesta HTTP. La primera respuesta suele ser un documento HTML, y ese documento hace referencia a otros recursos que el navegador solicita posteriormente, entre los cuales se incluyen:

• Documentos HTML
• Fuenteles de estilo CSS
• Archivos JavaScript
• Imágenes
• Otros datos, como fuentes o JSON desde una API

Un restaurante simplifica este intercambio para que sea fácil de recordar:

• El navegador es el cliente.
• La solicitud es el pedido.
• El servidor es la cocina.
• La respuesta es la comida.

Usted realiza un pedido, la cocina lo recibe, prepara el plato y lo envía. La web funciona según el mismo patrón: el navegador solicita, el servidor realiza el trabajo y el resultado vuelve. Cada respuesta también incluye un código de estado, como 200 para indicar éxito o 404 cuando la página no existe, lo cual indica al navegador cómo tratar lo que ha recibido.

Etapa 4: Convertir archivos en una página

Tener los archivos no es lo mismo que mostrar una página. El navegador aún debe interpretarlos y combinarlos en lo que usted ve, y cada uno de los tres lenguajes fundamentales de la web tiene un papel distinto.

HTML proporciona la estructura

HTML describe qué hay en la página y cómo está organizada: encabezados, párrafos, botones, imágenes, enlaces, etc. Es el esqueleto. El navegador lo analiza para crear el DOM (Modelo de Objetos de Documento), un árbol de elementos a partir del cual se desarrolla el resto del proceso.

CSS controla la apariencia

CSS determina cómo se ve esa estructura: colores, fuentes, espaciado, diseño y tamaños. Si HTML es el esqueleto, CSS es todo lo que le da una forma visual. El navegador analiza las hojas de estilo para convertirlas en su propia estructura y asigna cada regla a los elementos a los que se aplica.

JavaScript agrega comportamiento

JavaScript hace que la página sea interactiva: responde a los clics de botones, ejecuta animaciones, carga y actualiza contenido sin una recarga completa, entre muchas otras cosas. Los scripts pueden leer y modificar el DOM y los estilos, por lo que una página puede transformarse después de aparecer por primera vez.

Combinándolo todo

Al unir la estructura y los estilos, el navegador calcula dónde debe ir cada elemento (diseño) y luego dibuja el resultado (renderizado). Por defecto, una etiqueta simple <script> detiene el análisis del HTML mientras se descarga y ejecuta el script, lo cual es una de las razones por las que los consejos de rendimiento suelen recomendar los atributos defer o async.

Todo el proceso en orden

Secuenciando las etapas:

1. Se ingresa la dirección de un sitio web.
2. DNS traduce el nombre a una dirección IP.
3. El navegador se conecta al servidor y envía una solicitud.
4. El servidor recibe y procesa la solicitud.
5. El servidor envía una respuesta.
6. El navegador recibe el HTML y solicita el CSS, JavaScript, las imágenes y otros datos a los que hace referencia.
7. El navegador analiza y combina esos recursos.

La página finalizada aparece en su pantalla.

Con una conexión rápida, gran parte de esto ocurre en una fracción de segundo, por lo que parece que simplemente al presionar Enter la página aparece.

Por qué vale la pena tener este modelo

Conocer esta secuencia une conceptos que normalmente se enseñan por separado: navegadores, DNS, servidores, HTML, CSS y JavaScript. También le proporciona un lugar donde incorporar nuevos conocimientos. Cuando más adelante aprenda sobre APIs, las reconocerá como intercambios adicionales de solicitud y respuesta. Al estudiar el trabajo en el backend, sabrá que se lleva a cabo en el lado del servidor de la etapa 3. Al analizar el rendimiento del frontend, sabrá que se trata principalmente de acelerar las etapas 3 y 4.

También ayuda con la depuración. Un error de “sitio no encontrado” indica la etapa 1, un tiempo de espera o error de conexión corresponden a la etapa 2, un estado 500 se refiere al servidor en la etapa 3, y una página que carga pero parece defectuosa se debe a problemas en CSS o JavaScript en la etapa 4.

Puntos clave

• DNS convierte nombres fáciles de recordar en direcciones IP, con caché en varios niveles.
• El navegador establece una conexión segura mediante TLS para HTTPS y envía una solicitud HTTP.
• El servidor responde con HTML, que a su vez hace referencia a CSS, JavaScript, imágenes y otros recursos.
• HTML forma el DOM para la estructura, CSS le da estilo y JavaScript agrega funcionalidades antes de que el navegador diseñe e imprima la página.
• Cada etapa falla de manera reconocible, lo que convierte a este modelo en una herramienta práctica para la depuración además de un recurso didáctico.

Lecturas relacionadas

• De la hoja de estilos a la pantalla: dónde se integra CSS en el proceso del navegador — Sigue a CSS desde su descarga hasta que se muestra en píxeles: cómo se construyen el DOM, CSSOM y el árbol de renderizado, dónde tiene lugar la cascada de estilos y qué fuentes de estilo compiten por cada elemento.
• Por qué las micro-optimizaciones no resuelven el problema del rendimiento real de JavaScript — Explica por qué buscar métricas medibles como el tamaño del paquete y las actualizaciones de renderizado a menudo pasa por alto las causas reales de una experiencia de usuario lenta en las aplicaciones JavaScript.