Qué pasa entre que escribes una dirección y pulsas Enter
Entre tu tecla y la página hay media docena de pasos, varios ordenadores y unas cuantas décimas de segundo. Entenderlos explica por qué a veces algo va lento y dónde está el problema.
Escribes una dirección, pulsas Enter y aparece una página. Parece instantáneo.
En realidad han pasado seis o siete etapas, han intervenido varios ordenadores repartidos por el mundo y se han intercambiado mensajes de ida y vuelta. Todo en unas décimas de segundo.
Vale la pena conocer el recorrido, porque cuando algo va mal casi siempre falla en un punto concreto de esta cadena.
1. El navegador interpreta lo que escribiste
Antes de tocar la red, decide qué has querido decir. Si escribiste algo sin puntos, probablemente sea una búsqueda. Si tiene forma de dominio, será una dirección.
Después comprueba su lista HSTS: dominios que declararon servirse solo por HTTPS. Si el tuyo está, la petición se hace en HTTPS aunque hayas escrito http://, sin pasar por una redirección. Es lo que impide que alguien intercepte ese primer salto sin cifrar.
2. Del nombre a la dirección: DNS
Los ordenadores no se encuentran por nombre, sino por dirección IP. Traducir bawitools.com a un número es trabajo del DNS.
La búsqueda va por capas, y cada una existe para no tener que llegar a la siguiente:
- La caché del propio navegador
- La caché del sistema operativo
- El archivo
hosts, que puede forzar una respuesta - El servidor DNS que uses — el de tu operador, o uno público
- Y si nadie lo sabe: los servidores raíz, luego los del dominio
.com, luego los del dominio concreto
Cuando funciona, tarda milisegundos. Cuando falla, el síntoma es inconfundible: la página no carga pero otras sí, o el navegador se queda un rato largo en “buscando el sitio”.
3. Abrir la conversación: TCP
Con la IP en la mano, el navegador establece conexión mediante el llamado saludo de tres pasos: tu ordenador pregunta, el servidor confirma, tu ordenador confirma la confirmación.
Aquí manda la física. Cada ida y vuelta cuesta lo que tarde la señal en recorrer la distancia, y eso es latencia: el retraso que no se arregla contratando más megas. Un servidor en la otra punta del mundo tiene una latencia que ninguna tarifa mejora.
Es la diferencia entre ancho de banda y latencia, y explica por qué una conexión rapidísima puede sentirse lenta.
4. Ponerse de acuerdo en el cifrado: TLS
Si es HTTPS —hoy casi siempre— hay una negociación más: acordar el método de cifrado, presentar el certificado y generar las claves de la sesión.
El navegador comprueba tres cosas del certificado: que lo firme una autoridad en la que confía, que no esté caducado y que corresponda al dominio que pediste. Si algo falla, aparece el aviso de conexión no privada.
TLS 1.3 redujo esto a una sola ida y vuelta, y para una conexión ya conocida puede llegar a cero.
5. La petición
Recién ahora se pide la página. El navegador manda una línea del tipo GET /es/blog/ junto con unas cabeceras: qué navegador es, qué idiomas prefiere, qué formatos acepta, y si ya tiene una copia en caché.
Esa última parte importa. Si el navegador dice “ya tengo la versión con esta huella”, el servidor puede responder 304 Not Modified —apenas unos bytes— en vez de mandar la página entera.
6. El servidor responde
Y responde con un número que conviene saber leer:
| Código | Qué significa |
|---|---|
| 200 | Aquí tienes |
| 301 | Se mudó para siempre, ve a esta otra |
| 302 | Se mudó por ahora |
| 304 | No ha cambiado, usa tu copia |
| 403 | Existe, pero no puedes verlo |
| 404 | No existe |
| 500 | Existe, pero se rompió al generarlo |
| 503 | El servidor no da abasto |
Las redirecciones cuestan: cada una es otra vuelta completa. Por eso un sitio bien configurado enlaza directamente a la URL final en vez de encadenar saltos.
7. Pintar la página
Llega el HTML y empieza la parte visible:
El navegador lo lee de arriba abajo y va construyendo el árbol del documento. Cuando encuentra una hoja de estilos, para: sin estilos no puede saber cómo se ve nada, así que el CSS bloquea el pintado. Cuando encuentra un script, también para, porque ese script podría modificar el documento — salvo que lleve async o defer.
Con el documento y los estilos, calcula la posición y el tamaño de cada elemento, y por fin pinta.
Por eso el orden importa tanto: estilos arriba y scripts al final o marcados como diferidos. Un script pesado en mitad del <head> retrasa la primera imagen de la página aunque todo lo demás esté listo.
Y luego llegan las fuentes tipográficas, y con ellas el parpadeo de texto que cambia de aspecto al cargar.
Dónde mirar cuando va lento
Con este mapa, el diagnóstico se vuelve concreto. Abre F12 → Red y mira la columna de tiempos:
- Mucho tiempo en “DNS” → problema de resolución. Prueba con otro servidor DNS.
- Mucho en “Conexión” o “SSL” → el servidor está lejos o va saturado. Un CDN es la respuesta habitual.
- Mucho en “Esperando” (TTFB) → el servidor tarda en generar la página. Es lógica de servidor o base de datos, no red.
- Mucho en “Descarga” → los archivos pesan demasiado. Imágenes sin optimizar suelen ser el 80 % del problema.
- Todo rápido pero la página tarda en verse → es el pintado: scripts bloqueantes, o demasiado JavaScript por delante del contenido.
Esa distinción ahorra mucho tiempo. Optimizar imágenes cuando el problema es el TTFB no arregla nada, y es un error frecuente.
Lo que queda
Detrás de cada Enter hay una traducción de nombres, un saludo entre máquinas, una negociación criptográfica, una petición, una respuesta y un proceso de dibujo — repetido para cada uno de los archivos que compone la página, que suelen ser decenas.
Que todo eso ocurra en menos de un segundo, de forma fiable, millones de veces al día, es una de esas cosas que solo parecen normales porque funcionan.