Qué es una interfaz web y qué hay debajo de lo que ves
Publicado el 2026-09-12 por frfrand
Del momento en que escribís una dirección hasta que aparece la página: DNS, TCP, TLS, HTML, CSS y JavaScript, cada uno con su trabajo. Y por qué esa cadena explica casi todos los problemas de rendimiento.
"Interfaz web" suena a la parte bonita: los botones, los colores, el diseño. Eso es sólo lo último de una cadena, y entender la cadena entera es lo que te permite arreglar cosas en vez de adivinar.
Qué pasa cuando apretás Enter
Encontrar la dirección. El nombre que escribiste no significa nada para la red. El navegador le pregunta al DNS a qué dirección corresponde. Si ese dato no está en caché, son varios saltos hasta obtenerlo.
Abrir la conexión. Con la dirección en mano, se abre una conexión TCP: un intercambio de ida y vuelta para acordar que los dos lados están listos. Si el sitio usa HTTPS, arriba de eso va el handshake TLS, donde el servidor presenta su certificado.
Pedir y recibir. Recién ahí el navegador manda la petición. El servidor responde con HTML: un documento de texto que describe la estructura de la página.
Construir la imagen. El navegador lee ese HTML y arma un árbol de elementos. Mientras lo lee encuentra referencias a hojas de estilo, imágenes y scripts, y va pidiendo cada una. El CSS define cómo se ve, el JavaScript define cómo se comporta.
Los tres lenguajes, y por qué son tres
HTML dice qué es cada cosa. Esto es un título, esto un párrafo, esto un botón. Es estructura y significado, no apariencia.
CSS dice cómo se ve. Colores, tamaños, posiciones, qué pasa cuando la pantalla es angosta.
JavaScript dice qué hace. Responde a clics, pide datos al servidor, cambia la página sin recargarla.
La separación no es capricho histórico: es lo que permite que un lector de pantalla entienda la página sin ver los colores, que un buscador la indexe, y que se pueda rediseñar sin tocar el contenido.
Por qué esto importa para el rendimiento
Casi todos los problemas de "la página tarda" están en uno de esos pasos, y saber cuál cambia completamente la solución:
- Tarda en empezar a mostrar algo → probablemente sea el servidor generando el HTML, o el DNS si es la primera visita.
- Muestra el texto sin estilos por un instante → el CSS llegó tarde.
- Se ve pero no responde a los clics → el JavaScript todavía se está descargando o ejecutando.
- Salta y se reacomoda mientras carga → hay imágenes sin tamaño declarado, o fuentes que llegaron después.
La pestaña Red de las herramientas del navegador muestra exactamente dónde se fue el tiempo. Es la herramienta de diagnóstico más útil y la que menos se abre.
HTTP es una conversación de texto
Lo que viaja no es magia binaria. Una petición es texto:
GET /precios HTTP/1.1 Host: miapp.com
Y la respuesta también, con un código de estado adelante. Vale conocer los grupos:
2xx salió bien 3xx está en otro lado 4xx el problema es de quien pidió 5xx el problema es del servidor
Ese último grupo es el que te tiene que preocupar: un 404 significa que alguien pidió algo que no existe, y eso puede ser normal. Un 500 significa que tu código falló.
Y el detalle que cambió todo
HTTP no recuerda nada. Cada petición es independiente y el servidor no sabe si ya hablaste con él antes.
Por eso existen las cookies: un dato que el servidor te pide guardar y que tu navegador reenvía en cada petición siguiente. Toda la idea de "estar logueado" se apoya en eso.
Entender que el protocolo es sin memoria explica un montón de decisiones raras del desarrollo web, empezando por por qué manejar sesiones es más complicado de lo que parece.