Qué ocurre cuando visitas una página web

Escribes una dirección, presionas Enter y en segundos aparece una página. Parece algo simple, casi automático. Pero detrás de esa visita ocurren varias conversaciones técnicas: tu navegador pregunta dónde está el sitio, abre una conexión, negocia seguridad, habla con un servidor, espera una respuesta y luego arma la página en pantalla.

Entender ese camino ayuda muchísimo cuando una web está lenta, se cae, muestra errores raros o simplemente “a veces funciona y a veces no”. No siempre el problema está en “el hosting”. A veces está en DNS, en una consulta lenta, en una imagen pesada, en un CDN mal configurado o en JavaScript bloqueando el navegador.

Vamos a recorrerlo sin convertir esto en una tesis.

1. Primero: el navegador necesita encontrar el servidor

Cuando visitas:

https://blog.devops.com.do/

el navegador no sabe mágicamente dónde vive ese dominio. Necesita convertir el nombre en una IP. Para eso usa DNS.

En la práctica, DNS responde algo como:

blog.devops.com.do → 104.x.x.x

Puedes verlo con herramientas como dig o nslookup:

dig blog.devops.com.do

Eso no arregla nada por sí solo, pero te dice algo importante: si DNS falla, la petición ni siquiera llegó al servidor. Es como tener la dirección de un negocio mal escrita: puedes tener el mejor local del mundo, pero el delivery nunca va a llegar.

En producción, muchos problemas que parecen “la web está caída” son realmente problemas de DNS, propagación, registros mal puestos o un proxy como Cloudflare apuntando donde no debe.

2. Después viene la conexión

Ya con la IP, el navegador abre una conexión hacia el servidor. Si el sitio usa HTTPS —como debería— también ocurre una negociación TLS. Ahí se valida el certificado y se crea un canal cifrado.

La versión simple:

Navegador → IP del servidor → conexión → HTTPS listo

Si el certificado está vencido, mal emitido o no coincide con el dominio, el navegador se va a quejar antes de mostrar la página. Por eso un sitio puede “estar vivo” técnicamente, pero bloquearse por seguridad.

Una forma rápida de mirar headers y confirmar que hay respuesta es:

curl -I https://blog.devops.com.do/

Ahí puedes ver código HTTP, servidor, caché, redirects y otros detalles. No es una herramienta glamorosa, pero para diagnosticar web es como una linterna en un cuarto oscuro.

3. El servidor web recibe la petición

Cuando la conexión llega, normalmente la primera pieza que responde es un servidor web como Nginx, Apache, Caddy o algún proxy/CDN delante.

El servidor web decide qué hacer con la petición:

GET /posts/que-ocurre-cuando-visitas-una-pagina-web/

Puede responder con un archivo estático, redirigir, aplicar caché, comprimir la respuesta o pasar la petición a una aplicación.

Por ejemplo:

Visitante → Nginx → aplicación → base de datos

O, si es una imagen/CSS/JS:

Visitante → Nginx → archivo estático

Esa diferencia importa. Servir un archivo estático suele ser barato. Ejecutar lógica, consultar base de datos, armar HTML y llamar APIs externas es mucho más costoso.

Por eso una web bien optimizada intenta no despertar toda la aplicación cuando solo necesita entregar un logo, un CSS o una imagen.

4. La aplicación decide qué contenido entregar

Si la página es dinámica, el servidor web pasa la petición a la aplicación. Puede ser PHP, Node.js, Python, Ruby, Go, Java o lo que tenga el proyecto detrás.

La aplicación hace preguntas como:

• ¿Qué ruta pidió el usuario?
• ¿Necesita login?
• ¿Qué datos debo mostrar?
• ¿Tengo esto en caché?
• ¿Tengo que consultar la base de datos?
• ¿Debo llamar una API externa?

Un caso común: visitas la página de un producto. La app puede buscar el producto, precio, inventario, imágenes, reseñas y promociones.

Eso parece una sola página, pero por dentro puede ser una fila de tareas:

Ruta → controlador → caché → base de datos → plantilla → respuesta HTML

Si una de esas piezas tarda, todo se siente lento.

Aquí es donde aparecen los clásicos: consultas lentas, falta de índices, APIs externas demoradas, procesos saturados o código haciendo más trabajo del necesario.

5. La base de datos puede ser el cuello de botella

Muchas páginas necesitan datos. Ahí entra MySQL, PostgreSQL, MariaDB, Redis, MongoDB o cualquier motor que esté detrás.

Una consulta rápida puede tomar milisegundos. Una mala consulta puede tomar segundos. Y una mala consulta repetida cientos de veces puede tumbar la experiencia completa.

La idea no es mirar SQL por mirar SQL, sino entender si la base de datos está respondiendo bien. En MySQL o MariaDB, una consulta problemática puede investigarse con herramientas como EXPLAIN:

EXPLAIN SELECT * FROM orders WHERE customer_id = 123;

Ese tipo de revisión ayuda a responder preguntas simples:

• ¿Está usando índice?
• ¿Está leyendo demasiadas filas?
• ¿Está haciendo joins pesados?
• ¿La tabla creció y nadie ajustó nada?

En la vida real, una web puede ir bien durante meses y volverse lenta sin cambiar el diseño. Solo creció la data. Lo que antes buscaba entre 5,000 registros ahora busca entre 5 millones. Misma página, otra realidad.

6. La respuesta vuelve al navegador

Cuando la aplicación termina, devuelve una respuesta. Normalmente HTML, JSON, una imagen, un archivo o un redirect.

Una respuesta HTTP trae un código:

200 OK
301 Moved Permanently
404 Not Found
500 Internal Server Error

También trae headers, que pueden decir cosas como:

cache-control: public, max-age=3600
content-type: text/html; charset=utf-8
content-encoding: br

Esos headers influyen mucho. Pueden indicar si el navegador debe guardar algo, si la respuesta viene comprimida, si hay redirects o si un CDN puede cachearla.

Con curl puedes medir una visita de forma simple:

curl -o /dev/null -s -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://blog.devops.com.do/

No reemplaza herramientas como Lighthouse, WebPageTest o el panel Network de Chrome DevTools, pero da una señal rápida: ¿el servidor respondió tarde o el peso está después?

7. El navegador todavía tiene trabajo

Recibir HTML no significa que la página ya está lista. El navegador tiene que leerlo, descargar CSS, JavaScript, fuentes, imágenes y construir lo que ves.

A veces el servidor responde rápido, pero la página se siente lenta porque el frontend pesa demasiado.

Ejemplo realista:

• HTML: rápido
• CSS: normal
• imágenes: enormes
• JavaScript: bloquea interacción
• fuente externa: tarda
• analytics/chat/widgets: cargan tarde

Resultado: técnicamente el servidor “respondió bien”, pero el usuario siente una página pesada.

Por eso medir solo el backend no basta. También hay que mirar qué pasa en el navegador:

Servidor rápido + frontend pesado = experiencia lenta
Servidor lento + frontend liviano = espera inicial larga
Servidor rápido + frontend liviano = buena experiencia

No hay misterio. Hay cadena.

8. Dónde suelen aparecer los problemas

Cuando alguien dice “la web está lenta”, el problema puede estar en muchos puntos:

• DNS lento o mal configurado;
• certificado HTTPS vencido o mal instalado;
• servidor saturado;
• caché inexistente o mal usada;
• consultas lentas;
• demasiadas llamadas a APIs externas;
• imágenes sin optimizar;
• JavaScript pesado;
• redirects innecesarios;
• CDN mal configurado;
• bots consumiendo recursos.

Lo importante es no adivinar. Adivinar en infraestructura sale caro y casi siempre termina en “sube el servidor” aunque el problema era una consulta sin índice o una imagen de 8 MB en el home.

Una forma simple de pensar el flujo

Puedes imaginar una visita como pedir comida en un restaurante:

DNS = encontrar el restaurante
Conexión = llegar y sentarte
HTTPS = confirmar que estás hablando con el lugar correcto
Servidor web = quien recibe la orden
Aplicación = la cocina organizando el plato
Base de datos = la despensa/inventario
Navegador = quien monta el plato en la mesa

Si la dirección está mal, no llegas. Si el mesero tarda, esperas. Si la cocina está lenta, esperas. Si falta un ingrediente, se complica. Si el plato llega pero hay que armarlo pieza por pieza en la mesa, también se siente lento.

La experiencia final depende de toda la cadena.

Idea final

Visitar una página web parece simple porque todo ocurre muy rápido cuando está bien diseñado. Pero detrás hay DNS, conexiones, seguridad, servidores, aplicación, base de datos, caché y navegador trabajando juntos.

Cuando entiendes ese camino, diagnosticar se vuelve más fácil. Ya no dices “la web está lenta” como si fuera una sola cosa. Puedes empezar a preguntar mejor:

• ¿Tarda en resolver DNS?
• ¿El servidor responde lento?
• ¿La base de datos está pesada?
• ¿La respuesta pesa demasiado?
• ¿El navegador está bloqueado por JavaScript?
• ¿El caché está ayudando o estorbando?

Esa es la diferencia entre apagar fuegos a ciegas y operar sistemas con criterio.

Una web rápida no nace de magia ni de un botón de “optimizar”. Nace de entender qué ocurre en cada paso y quitar fricción donde realmente duele.