Cuando escribimos una dirección en el navegador y pulsamos Enter, parece que la página web aparece casi de inmediato.
Pero detrás de ese instante hay una cadena de procesos tecnológicos que normalmente pasan completamente desapercibidos.
Antes de que podamos ver una imagen, leer un texto o pulsar un botón, el navegador tiene que localizar el servidor, establecer una conexión segura, solicitar los recursos de la página, recibirlos y convertir toda esa información en algo que nuestros ojos puedan interpretar.
Una página web no aparece simplemente.
Se construye delante de nosotros.
Todo empieza con un nombre.
Supongamos que escribimos:
berhattan.com
El navegador no sabe inicialmente dónde está ese sitio web.
Los ordenadores se comunican utilizando direcciones IP, por lo que el primer paso consiste en averiguar qué dirección IP corresponde al dominio que hemos introducido.
Aquí entra en juego el DNS (Domain Name System).
El DNS funciona, simplificando mucho, como un sistema de traducción entre nombres de dominio y direcciones IP.
En lugar de obligarnos a recordar una dirección numérica, podemos utilizar un nombre mucho más sencillo.
Es uno de los primeros pasos que ocurren cada vez que visitamos una web.
Después llega la conexión.
Una vez localizada la dirección del servidor, el navegador necesita establecer una comunicación con él.
Si la web utiliza HTTPS, además de establecer la conexión se realiza un proceso de negociación criptográfica que permite que la comunicación entre el navegador y el servidor sea segura.
Es aquí donde interviene TLS (Transport Layer Security).
El objetivo es que los datos que viajan entre ambos extremos no circulen de forma legible para cualquiera que pudiera interceptarlos.
Por eso aparece el conocido candado del navegador.
HTTPS no es simplemente un elemento visual.
Es la consecuencia visible de una comunicación protegida mediante cifrado.
El navegador hace una petición.
Una vez establecida la conexión, el navegador puede solicitar la página.
Aquí aparece otro protagonista fundamental:
HTTP (Hypertext Transfer Protocol).
HTTP es el protocolo que permite solicitar y transmitir recursos entre el navegador y el servidor.
El navegador puede pedir, por ejemplo, el documento HTML de una página.
El servidor procesa la petición y devuelve una respuesta.
En una situación sencilla podríamos imaginar algo parecido a esto:
Navegador → ¿Me puedes enviar esta página?
Servidor → Sí. Aquí tienes el HTML.
Pero la historia no termina ahí.
De hecho, acaba de empezar.
HTML: la estructura de la página.
El HTML contiene la estructura y el contenido de la página.
Define elementos como títulos, párrafos, enlaces, imágenes, listas o formularios.
Por ejemplo, cuando vemos un titular en una página, existe una estructura HTML detrás que indica al navegador que aquello es un encabezado.
El HTML es, por tanto, una parte fundamental de la arquitectura de una página web.
Pero por sí solo no suele ser suficiente para producir una interfaz visualmente atractiva.
Ahí entra CSS.
CSS: cómo se presenta la página.
CSS permite definir cómo debe mostrarse el contenido.
Colores, tamaños, espacios, tipografías, columnas, márgenes, posiciones y adaptación a diferentes tamaños de pantalla son algunas de las cosas que pueden controlarse mediante CSS.
Gracias a CSS, la misma estructura HTML puede convertirse en una página visualmente completamente diferente.
Por eso conviene distinguir entre estructura y presentación.
HTML organiza.
CSS presenta.
Y después tenemos un tercer elemento fundamental.
JavaScript: cuando la página necesita interactuar.
JavaScript permite añadir comportamiento a una página web.
Menús desplegables, formularios dinámicos, filtros, determinadas animaciones, validaciones o aplicaciones web completas pueden depender de JavaScript.
No todas las páginas necesitan utilizarlo de la misma manera.
Una página sencilla puede funcionar con muy poco JavaScript, mientras que una aplicación web compleja puede depender de grandes cantidades de código ejecutado en el navegador.
Y esto tiene una consecuencia importante:
cada recurso adicional que tiene que descargar y procesar el navegador forma parte del trabajo necesario para mostrar la página.
El navegador tiene que construir la página.
Cuando el navegador recibe HTML, CSS, JavaScript, imágenes, fuentes y otros recursos, tiene que procesarlos.
No se limita a descargar archivos y mostrarlos.
Tiene que interpretar la información y construir una representación de la página que posteriormente pueda dibujar en pantalla.
De forma simplificada, el navegador:
- recibe el HTML;
- construye la estructura del documento;
- procesa las hojas de estilo;
- calcula cómo deben colocarse los elementos;
- ejecuta el JavaScript necesario;
- prepara los elementos para ser dibujados;
- finalmente los representa en pantalla.
Todo esto ocurre en muy poco tiempo.
Por eso una web rápida no depende únicamente del hosting.
Es habitual pensar que una web rápida es simplemente una web alojada en un servidor rápido.
El servidor importa, pero no es el único elemento.
La velocidad percibida por el usuario depende de muchos factores:
- tiempo de respuesta del servidor;
- calidad de la conexión;
- DNS;
- protocolo utilizado;
- cantidad de HTML;
- tamaño de las imágenes;
- hojas CSS;
- JavaScript;
- fuentes externas;
- número de peticiones;
- caché;
- compresión;
- CDN;
- capacidad de procesamiento del dispositivo del usuario.
Una página puede tener un servidor excelente y, aun así, ser lenta si obliga al navegador a descargar y procesar una cantidad excesiva de recursos.
Del mismo modo, una web correctamente optimizada puede ofrecer una experiencia rápida sin necesitar una infraestructura desproporcionada.
HTTP/2 y HTTP/3 también forman parte de esta historia.
La evolución de los protocolos web ha intentado mejorar precisamente la manera en la que estos recursos se solicitan y transportan.
HTTP/2 introdujo mejoras importantes respecto a HTTP/1.1, entre ellas la posibilidad de multiplexar diferentes solicitudes dentro de una misma conexión.
HTTP/3 da un paso diferente al utilizar QUIC sobre UDP.
Esto puede reducir determinados problemas asociados al transporte tradicional y mejorar el comportamiento de las conexiones modernas.
Por eso la tecnología utilizada para servir una página también forma parte de la experiencia final del usuario.
En berhattan ofrecemos a nuestros clientes sistemas basados tanto en tecnologías tradicionales como en HTTP/2 y HTTP/3 mediante QUIC, dependiendo de la configuración y necesidades del proyecto.
Y entonces aparece la página.
Después de todo este proceso, finalmente vemos aquello que parecía haber ocurrido instantáneamente.
Un titular.
Una fotografía.
Un menú.
Un botón.
Un formulario.
Pero cada uno de esos elementos ha pasado por una cadena tecnológica antes de llegar a nuestros ojos.
Y esa cadena es mucho más interesante de lo que parece.
Diseñar una web también significa entender lo que hay detrás.
El diseño web no consiste únicamente en elegir colores, tipografías o imágenes.
Una buena página necesita que diferentes capas tecnológicas funcionen correctamente juntas.
Dominio, DNS, servidor, HTTPS, protocolos, HTML, CSS, JavaScript, bases de datos, caché y navegador forman parte de una misma cadena.
Cuando todas esas piezas están correctamente planteadas, el usuario no tiene por qué conocerlas.
Simplemente entra en la página y la página funciona.
Y precisamente ahí está una de las partes más interesantes del diseño web: hacer que una tecnología extraordinariamente compleja parezca sencilla.
En berhattan nos interesa trabajar precisamente en esa parte que normalmente no se ve.
Porque detrás de una página web hay mucho más que una pantalla.
Hay una infraestructura completa que hace posible que esa pantalla aparezca en apenas unos instantes.
