1. Cuánto tiempo esperamos por una página y qué cabe en un segundo
¿Cuántos segundos puedes esperar para que cargue una página? En 1993, Jakob Nielsen estableció tres límites importantes para la experiencia del usuario. En concreto, 0,1 segundos es el límite para sentir que la respuesta es inmediata, 1 segundo es el límite para no interrumpir el flujo de pensamiento y 10 segundos es el límite para mantener la atención en la pantalla [1].
Estas pautas se basan en investigaciones realizadas en 1968 y 1991 [1]. En la web actual, una métrica clave es el tiempo que tarda en aparecer la parte más grande de la página (como una imagen o un bloque de texto grande). Se considera "bueno" si esto ocurre en menos de 2,5 segundos en el 75% de las cargas de página [2].
Para este análisis, usaremos 1 segundo como nuestro "presupuesto de tiempo" para la comunicación. Veremos qué consume este tiempo, empezando por lo que no podemos reducir.
2. Por qué la velocidad de la luz impone un tiempo mínimo de viaje
Aunque la luz viaja muy rápido, la distancia impone un tiempo mínimo. La luz viaja a aproximadamente 300.000 km por segundo en el vacío, pero dentro de las fibras de vidrio de los cables, se ralentiza debido al índice de refracción (aproximadamente 1,5) [3]. Esto significa que la luz en una fibra óptica viaja a unos 200.000 km por segundo.
La distancia en línea recta entre Tokio y Los Ángeles es de unos 8.800 km. A esa velocidad, el viaje de ida toma unos 44 milisegundos y el viaje de ida y vuelta unos 88 milisegundos. A este tiempo de ida y vuelta se le llama RTT (Round Trip Time). Este es el límite teórico mínimo, muy cercano al límite de 0,1 segundos mencionado antes [3].
Es similar a un eco en una montaña: cuanto más lejos está la montaña, más tardas en escuchar la respuesta. Pero en internet, el equipo remoto no solo refleja la señal, sino que la recibe, procesa una respuesta y la envía de vuelta. Los 88 milisegundos son el mínimo si el cable fuera perfectamente recto y los equipos no tardaran nada en procesar. En realidad, los cables submarinos no son rectos, por lo que tardan más. Para comparar, entre Tokio y Osaka (unos 400 km), el viaje de ida y vuelta toma unos 4 milisegundos. Así, el viaje de ida y vuelta entre Tokio y Los Ángeles tarda más de 20 veces lo que tarda el de Tokio a Osaka.
3. Cómo el DNS convierte una dirección web en un número IP
Cuando escribes una dirección web (URL), el navegador necesita el número del equipo de destino (dirección IP). El sistema DNS busca este número. Si no hay información guardada, la consulta viaja a un servidor raíz, luego a un servidor de dominio superior (como .jp o .com) y finalmente al servidor del dominio específico. Cada paso requiere un viaje de ida y vuelta [4].
Para ahorrar tiempo, las respuestas se guardan en caché. Los equipos y servidores guardan los resultados durante un tiempo determinado (TTL) y los reutilizan hasta que caducan [4]. Es como anotar la dirección de un amigo en tu agenda para no buscarla de nuevo, pero con una fecha de caducidad.
La segunda vez que buscas el mismo nombre, la respuesta puede venir de una caché cercana, evitando viajes largos. Así, el primer paso puede requerir casi cero viajes o varios, dependiendo de si ya tienes los datos guardados.
4. Cuántos viajes de ida y vuelta hacen falta para establecer la conexión
Una vez que tienes el número IP, debes establecer una conexión. Primero, el protocolo TCP realiza un saludo, similar a decir "hola" y "te escucho", para sincronizar los números de secuencia. Esto toma 1 viaje de ida y vuelta [5].
Luego, para páginas seguras (https), se negocia la encriptación usando TLS. Hasta TLS 1.2, esto tomaba 2 viajes. Con TLS 1.3, introducida en 2018, la negociación para una nueva conexión se reduce a 1 viaje [6][7].
Solo después de esto, el navegador envía la solicitud HTTP ("dame esta página") y espera el primer byte de respuesta, lo que añade otro viaje de ida y vuelta. Para una conexión nueva desde Tokio a Los Ángeles, el desglose mínimo es: TCP (1 viaje, ~88 ms), TLS 1.3 (1 viaje, ~176 ms acumulados) y HTTP (1 viaje, ~264 ms acumulados).
5. Por qué una página web está formada por decenas de archivos
La primera respuesta suele ser un archivo HTML. Este archivo indica dónde están otros recursos: hojas de estilo CSS, scripts JavaScript, imágenes y fuentes. El navegador lee el HTML y solicita estos archivos adicionales.
Según los datos de HTTP Archive de julio de 2025, la mediana de solicitudes por página es de 77 en equipos de escritorio y 72 en teléfonos. Los archivos JavaScript son los más frecuentes [8].
En el protocolo antiguo HTTP/1.1, los navegadores abrían múltiples conexiones simultáneas para descargar varios archivos a la vez, lo que requería repetir el saludo TCP para cada nueva conexión [9]. HTTP/2, estandarizado en 2022, permite varias conversaciones simultáneas sobre una sola conexión [9]. Sin embargo, existe una barrera de orden: el navegador no sabe qué archivos pedir hasta que lee el HTML. Aunque tiene un escáner previo para anticipar algunas solicitudes, las decenas de peticiones siguen chocando con el tiempo de viaje de ida y vuelta [10].
6. Cómo TLS 1.3, QUIC y las copias cercanas reducen los viajes
No podemos cambiar la velocidad de la luz, pero sí reducimos el número de viajes y la distancia. TLS 1.3 reduce la negociación a 1 viaje. Con 0-RTT, se puede enviar datos cifrados junto con el primer mensaje si ya te has conectado antes. Sin embargo, el estándar advierte que esto tiene una debilidad de seguridad frente a ataques de repetición (replay), aceptada como un intercambio por rendimiento [6][7].
QUIC unifica el establecimiento de conexión equivalente a TCP y la negociación TLS 1.3 en un solo paso, acelerando la conexión [12]. Iniciado como experimento por Google en 2013 y estandarizado como RFC 9000 en 2021, QUIC funciona sobre UDP para facilitar su despliegue en equipos y redes existentes [13][11]. HTTP/3 usa QUIC, evitando que la pérdida de un paquete detenga otras descargas, algo que ocurría en HTTP/2 [14].
La otra estrategia es reducir la distancia. Las redes CDN colocan copias de los contenidos en servidores cercanos a los usuarios. Si la copia está en Tokio u Osaka, el viaje de ida y vuelta baja a unos pocos milisegundos, según nuestros cálculos previos [15].
7. Cómo el navegador convierte los datos recibidos en la imagen de la pantalla
Los datos recibidos aún no son una imagen. El navegador lee el HTML para crear la estructura (DOM) y el CSS para las reglas visuales (CSSOM). Combina ambos para calcular el tamaño y la posición (layout) y finalmente pinta los píxeles en la pantalla [10].
El análisis del HTML comienza tan pronto como llegan los primeros bytes, sin esperar a todo el archivo. Mientras espera el CSS, el análisis de HTML y la descarga continúan, pero la ejecución de JavaScript suele pausarse. Si llegan imágenes tarde, el diseño puede recalcularse [10].
Volviendo a la pregunta inicial: para un servidor al que te conectas por primera vez, son necesarios 3 viajes de ida y vuelta solo para recibir el primer byte (sin contar DNS). Los archivos siguientes pueden usar la conexión establecida. Ese segundo de espera incluye tanto los viajes de datos como el tiempo que el navegador tarda en construir la página.
¿Quieres investigarlo tú mismo?
Puedes ver estos viajes usando las herramientas de desarrollo del navegador. Abre la pestaña "Red" (Network) y recarga la página. Hazlo junto con un adulto de tu familia.
Al seleccionar un archivo, verás la sección "Timing". Allí se desglosan el tiempo de búsqueda DNS, la conexión (saludos TCP y TLS) y la espera de la respuesta del servidor [16]. Al recargar la página una segunda vez, observa qué tiempos desaparecen o se acortan gracias a las cachés.
Advertencia de seguridad: los registros de red pueden contener información sensible como datos de inicio de sesión. Nunca publiques capturas de pantalla de estas herramientas en redes sociales ni compartas los archivos de registro con otras personas.