Qué ocurre realmente cuando escribes una dirección web en el navegador

Es algo que hacemos constantemente. Abrimos Chrome, Firefox, Edge o Safari, escribimos una dirección como https://franparedes.es, pulsamos Enter y, apenas unos instantes después, aparece una página web.

Parece sencillo.

Sin embargo, durante esos pocos milisegundos están ocurriendo una enorme cantidad de procesos: el navegador interpreta la dirección, busca dónde se encuentra el servidor, establece una conexión, negocia una comunicación segura, solicita documentos, descarga recursos y finalmente convierte todo ese código en la página que vemos en pantalla.

Entender qué ocurre cuando escribimos una URL en el navegador es una excelente manera de comprender cómo funciona realmente Internet y, además, ayuda a entender conceptos fundamentales del desarrollo web como DNS, HTTP, HTTPS, servidores, HTML, CSS, JavaScript, caché o rendimiento web.

Vamos a seguir el recorrido completo.

Introducción: de una dirección web a una página en pantalla

Imaginemos que escribimos:

https://franparedes.es

Para nosotros es simplemente la dirección de una página.

Para el navegador contiene bastante información.

Podemos dividir una URL más completa de esta forma:

https://franparedes.es/blog/articulo?id=25

Aquí encontramos diferentes elementos:

https:// → protocolo utilizado.
franparedes.es → nombre de dominio.
/blog/articulo → ruta solicitada.
?id=25 → parámetros enviados con la petición.

Pero existe un problema inicial.

Los ordenadores que forman Internet no necesitan el nombre franparedes.es para comunicarse entre ellos. La comunicación finalmente debe dirigirse hacia una dirección IP.

Por tanto, una de las primeras tareas será descubrir qué servidor corresponde al dominio que hemos escrito.

Y ahí comienza realmente el viaje.

1. El navegador interpreta la URL

Lo primero que hace el navegador es analizar lo que hemos escrito.

Debe determinar si se trata de:

una dirección web,
una búsqueda,
una URL completa,
un recurso local,
o algún protocolo especial.

Cuando detecta una URL como:

https://franparedes.es

identifica principalmente dos datos:

Protocolo: HTTPS
Dominio: franparedes.es

El protocolo indica cómo debe realizarse la comunicación.

Actualmente la mayoría de sitios utilizan HTTPS, la versión segura de HTTP.

A partir de aquí, el navegador necesita descubrir dónde está alojada esa web.

2. El navegador busca la dirección IP

Los servidores conectados a Internet se identifican mediante direcciones IP.

Por ejemplo, conceptualmente podríamos tener:

franparedes.es → 203.0.113.25

La IP del ejemplo es únicamente ilustrativa.

Recordar direcciones como esta sería poco práctico para las personas. Por eso utilizamos nombres de dominio.

El sistema encargado de traducir nombres como:

franparedes.es

en direcciones IP es el DNS (Domain Name System).

Podemos imaginarlo como una especie de agenda distribuida de Internet.

Nosotros conocemos el nombre.

El DNS ayuda a localizar la dirección necesaria para llegar al servidor correspondiente.

3. Antes de preguntar al DNS se comprueba la caché

Consultar continuamente servidores DNS sería ineficiente.

Por eso existen diferentes niveles de caché.

El sistema puede comprobar si ya conoce la respuesta a la pregunta:

¿Qué IP corresponde a franparedes.es?

Dependiendo del sistema y de la configuración, pueden intervenir cachés del navegador, del sistema operativo o del resolvedor DNS utilizado por nuestra conexión.

Si existe una respuesta válida almacenada, puede reutilizarse.

Esto evita consultas innecesarias y ayuda a reducir la latencia.

Si la dirección no está disponible en caché, será necesario realizar una resolución DNS.

4. Entra en funcionamiento el sistema DNS

Aquí comienza una de las partes más interesantes.

Normalmente nuestro dispositivo utiliza un resolvedor DNS recursivo, que puede pertenecer al proveedor de Internet o a un servicio DNS configurado por el usuario o la organización.

Si el resolvedor tampoco tiene la respuesta almacenada, puede iniciar las consultas necesarias dentro de la jerarquía DNS.

De forma simplificada, pueden intervenir:

Servidor raíz
      ↓
Servidor del TLD (.es)
      ↓
Servidor autoritativo de franparedes.es
      ↓
Dirección IP

Los servidores raíz no tienen que conocer directamente la IP de todas las páginas de Internet.

Pueden indicar dónde continuar buscando.

En nuestro ejemplo, la extensión es:

.es

El proceso continúa hacia la infraestructura correspondiente al dominio de nivel superior y finalmente hacia los servidores DNS autoritativos del dominio.

Estos pueden proporcionar el registro necesario para localizar el destino.

Entre los registros DNS más conocidos encontramos:

A → relaciona un nombre con una dirección IPv4.
AAAA → relaciona un nombre con una dirección IPv6.
CNAME → establece un alias hacia otro nombre.
MX → indica servidores relacionados con el correo electrónico.
TXT → permite almacenar información de texto utilizada para diferentes verificaciones y configuraciones.

Después de este proceso, el navegador ya puede disponer de una dirección a la que intentar conectarse.

5. El navegador establece la conexión

Ya sabemos dónde está el servidor.

Ahora hay que comunicarse con él.

Tradicionalmente, gran parte del tráfico HTTP se ha realizado sobre TCP, mientras que tecnologías más modernas como HTTP/3 utilizan QUIC, basado en UDP.

Si se utiliza TCP, antes de intercambiar los datos de la aplicación se establece una conexión mediante el conocido three-way handshake.

Simplificando:

Cliente → SYN → Servidor
Cliente ← SYN-ACK ← Servidor
Cliente → ACK → Servidor

Podemos imaginarlo como:

Cliente: ¿Podemos hablar?
Servidor: Sí, estoy preparado.
Cliente: Perfecto, empezamos.

Todo esto ocurre extremadamente rápido, aunque la distancia física entre usuario y servidor puede afectar a la latencia.

6. HTTPS añade una capa de seguridad

Como hemos escrito:

https://

la comunicación debe ser segura.

HTTPS utiliza TLS (Transport Layer Security) para proteger la comunicación.

Durante el establecimiento de la sesión segura se realizan tareas como:

negociación de parámetros criptográficos,
presentación y validación del certificado digital,
comprobación de la identidad del servidor,
establecimiento de claves para proteger la sesión.

El navegador comprueba, entre otras cosas, si el certificado presentado es válido para el dominio y si puede confiar en la cadena de certificación.

Una vez establecida la conexión segura, la información puede viajar cifrada.

Esto es fundamental cuando enviamos datos como:

contraseñas,
formularios,
información personal,
sesiones de usuario,
información bancaria.

Sin HTTPS, una comunicación HTTP convencional no ofrece esa protección criptográfica frente a terceros situados en el camino de la comunicación.

7. El navegador envía una petición HTTP

Una vez preparada la comunicación, el navegador puede solicitar el recurso.

Conceptualmente, una petición podría parecerse a:

GET / HTTP/1.1
Host: franparedes.es

En realidad, las peticiones modernas contienen bastante más información mediante cabeceras HTTP.

Por ejemplo, pueden indicar características relacionadas con:

tipos de contenido aceptados,
idioma,
compresión,
cookies,
caché,
origen de determinadas peticiones.

El método:

GET

indica que queremos obtener un recurso.

Existen otros métodos HTTP importantes:

GET
POST
PUT
PATCH
DELETE

Por ejemplo, al enviar determinados formularios podemos encontrarnos con una petición POST.

8. La petición llega al servidor web

La petición atraviesa Internet hasta llegar a la infraestructura que aloja la página.

Allí podemos encontrar tecnologías como:

Nginx,
Apache,
servidores de aplicaciones,
balanceadores de carga,
proxies inversos,
servicios CDN.

Dependiendo de cómo esté construida la web, la respuesta puede ser muy sencilla o requerir bastante procesamiento.

Si solicitamos un archivo estático:

imagen.jpg

el servidor podría simplemente localizarlo y devolverlo.

Pero si solicitamos una página dinámica, el proceso puede ser bastante diferente.

9. El backend puede generar la página dinámicamente

Imaginemos una aplicación creada con Laravel y PHP.

El navegador solicita:

https://ejemplo.com/articulos

La infraestructura web dirige la petición hacia la aplicación.

Laravel analiza la ruta:

Route::get('/articulos', ...);

A partir de ahí pueden intervenir:

Ruta
 ↓
Controlador
 ↓
Modelo
 ↓
Base de datos
 ↓
Vista

Por ejemplo, la aplicación podría consultar una base de datos MySQL para obtener los artículos publicados.

Simplificando:

SELECT * FROM posts WHERE published = 1;

PHP procesa los resultados y Laravel genera finalmente una respuesta HTML.

El navegador no necesita conocer todo este proceso interno.

Simplemente recibe una respuesta.

Esta separación es fundamental para entender la diferencia entre frontend y backend.

10. El servidor devuelve una respuesta HTTP

El servidor responde con información que incluye un código de estado HTTP.

Uno de los más conocidos es:

200 OK

Significa que la petición se ha procesado correctamente.

Otros códigos habituales son:

301 Moved Permanently
404 Not Found
403 Forbidden
500 Internal Server Error

Los códigos HTTP se agrupan en familias:

1xx → Información
2xx → Éxito
3xx → Redirecciones
4xx → Errores relacionados con la solicitud
5xx → Errores del servidor

Después de las cabeceras llega el contenido de la respuesta.

En una página web puede tratarse inicialmente de HTML.

11. El navegador recibe el HTML

Supongamos que recibe algo parecido a esto:

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Fran Paredes</title>
    <link rel="stylesheet" href="/css/style.css">
</head>

<body>

    <h1>Fran Paredes</h1>

    <img src="/images/logo.webp" alt="Fran Paredes">

    <script src="/js/app.js"></script>

</body>
</html>

Aquí aparece otro detalle fundamental.

Recibir el HTML no significa que la página haya terminado de descargarse.

El HTML contiene referencias hacia otros recursos.

En nuestro ejemplo:

/css/style.css
/images/logo.webp
/js/app.js

El navegador tendrá que solicitarlos.

12. Comienzan nuevas peticiones

La primera petición puede desencadenar muchas otras.

Por ejemplo:

HTML
 ├── CSS
 ├── JavaScript
 ├── logo.webp
 ├── fotografia.webp
 ├── fuente.woff2
 └── iconos.svg

Una página moderna puede necesitar decenas o incluso cientos de recursos.

Aquí entra en juego uno de los aspectos más importantes del rendimiento web.

Cuantos más datos haya que descargar y procesar, mayor puede ser el coste necesario para mostrar la página.

Por eso optimizamos elementos como:

imágenes,
fuentes,
CSS,
JavaScript,
caché,
número de peticiones,
carga diferida,
recursos externos.

13. El navegador construye el DOM

Mientras recibe el HTML, el navegador comienza a interpretarlo.

A partir del documento crea una estructura llamada DOM (Document Object Model).

Por ejemplo:

<body>
    <main>
        <h1>Hola</h1>
        <p>Bienvenido a mi web</p>
    </main>
</body>

puede representarse conceptualmente como:

document
└── html
    └── body
        └── main
            ├── h1
            └── p

JavaScript puede posteriormente consultar y modificar esta estructura.

Por ejemplo:

document.querySelector('h1').textContent = 'Hola mundo';

El DOM es, por tanto, una pieza fundamental en el funcionamiento del frontend.

14. El navegador procesa también el CSS

El navegador descarga las hojas de estilo y analiza sus reglas.

Por ejemplo:

h1 {
    font-size: 3rem;
    font-weight: 700;
}

A partir del CSS se construye otra representación interna relacionada con los estilos, habitualmente denominada CSSOM.

De forma muy simplificada:

HTML → DOM
CSS  → CSSOM

El navegador combina la información necesaria para determinar qué elementos deben mostrarse y cómo deben aparecer.

15. Se calcula la posición de cada elemento

El navegador necesita calcular las dimensiones y posiciones de los elementos.

Debe resolver cuestiones como:

¿Cuánto mide este bloque?
¿Dónde comienza?
¿Qué anchura tiene?
¿Qué espacio deja el margen?
¿Cómo afecta Flexbox?
¿Cómo se distribuye Grid?

Esta fase suele relacionarse con el layout.

Por ejemplo:

.container {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 2rem;
}

El navegador debe calcular cómo distribuir esas tres columnas según el espacio disponible.

Por eso un CSS excesivamente complejo o determinados cambios constantes realizados mediante JavaScript pueden afectar al rendimiento.

16. Finalmente se dibuja la página

Una vez que el navegador sabe:

qué elementos existen,
qué estilos tienen,
cuánto miden,
dónde deben colocarse,

puede comenzar el proceso de pintado y composición en pantalla.

Simplificando mucho:

HTML
 ↓
DOM

CSS
 ↓
CSSOM

DOM + estilos
 ↓
Renderizado
 ↓
Layout
 ↓
Paint
 ↓
Composición
 ↓
Pantalla

Y finalmente vemos la página.

Todo este trabajo puede haber ocurrido en una fracción de segundo.

17. JavaScript puede modificar la página después

La historia tampoco termina cuando aparece el primer contenido.

JavaScript puede continuar ejecutándose.

Por ejemplo:

fetch('/api/noticias')
    .then(response => response.json())
    .then(data => {
        console.log(data);
    });

El navegador podría realizar otra petición a una API y actualizar posteriormente parte de la interfaz.

Este comportamiento es muy habitual en aplicaciones creadas con tecnologías como:

React,
Vue,
Angular,
JavaScript nativo.

Por eso algunas aplicaciones muestran primero una estructura básica y después van incorporando información dinámicamente.

18. La caché evita repetir trabajo innecesariamente

Supongamos que volvemos mañana a la misma página.

El navegador podría tener algunos recursos almacenados:

logo.webp
style.css
app.js
fuente.woff2

Si las políticas de caché permiten reutilizarlos, no será necesario descargarlos completamente otra vez.

Esto puede mejorar considerablemente la velocidad.

El servidor puede controlar parte de este comportamiento mediante cabeceras HTTP relacionadas con la caché.

Por ejemplo:

Cache-Control: public, max-age=31536000

Una estrategia de caché bien diseñada puede tener un impacto importante en el rendimiento de una web.

19. ¿Y qué papel tiene una CDN?

Muchas páginas utilizan una CDN (Content Delivery Network).

La idea consiste en distribuir o cachear determinados contenidos en infraestructura situada en diferentes ubicaciones.

Imaginemos que el servidor principal está muy lejos del usuario.

Sin CDN:

Usuario
        ↓
      gran distancia
        ↓
Servidor

Con una CDN, ciertos recursos pueden servirse desde una ubicación más próxima o desde una infraestructura optimizada para su distribución:

Usuario
   ↓
CDN cercana
   ↓
Servidor de origen

Además de rendimiento, determinadas plataformas CDN ofrecen funciones adicionales relacionadas con seguridad, protección frente a ataques, optimización y gestión del tráfico.

20. Todo el recorrido completo

Podemos resumir todo lo anterior de esta forma:

Usuario escribe una URL
        ↓
El navegador interpreta la dirección
        ↓
Comprueba información disponible en caché
        ↓
Resolución DNS
        ↓
Obtiene la dirección IP
        ↓
Establece la conexión
        ↓
Negociación TLS si utiliza HTTPS
        ↓
Envía una petición HTTP
        ↓
La petición llega al servidor
        ↓
El backend puede procesarla
        ↓
Puede consultar una base de datos
        ↓
Genera una respuesta
        ↓
El servidor devuelve HTML
        ↓
El navegador analiza el HTML
        ↓
Solicita CSS, JS, imágenes, fuentes...
        ↓
Construye DOM y procesa estilos
        ↓
Calcula el layout
        ↓
Pinta y compone los elementos
        ↓
Vemos la página

Lo sorprendente es que buena parte de este proceso puede producirse en apenas unos cientos de milisegundos.

21. ¿Por qué algunas páginas tardan más que otras?

Ahora podemos entender mejor por qué una página puede ser lenta.

El problema podría encontrarse prácticamente en cualquier punto del recorrido:

DNS lento
      ↓
Servidor lejano
      ↓
Conexión lenta
      ↓
Backend lento
      ↓
Consulta SQL pesada
      ↓
HTML demasiado grande
      ↓
Imágenes enormes
      ↓
Demasiado JavaScript
      ↓
CSS complejo
      ↓
Recursos externos
      ↓
Renderizado lento

Por eso optimizar una página web no consiste únicamente en comprimir imágenes.

El rendimiento web es el resultado de todo un sistema.

Un desarrollador puede analizar aspectos relacionados con:

tiempo de respuesta del servidor,
consultas a bases de datos,
caché,
CDN,
tamaño de imágenes,
JavaScript,
CSS,
fuentes,
peticiones HTTP,
renderizado del navegador.

Herramientas como las DevTools del navegador permiten observar muchas de estas operaciones prácticamente en tiempo real.

22. Un experimento sencillo para verlo en tu navegador

Podemos comprobar parte de todo este proceso sin instalar absolutamente nada.

En Chrome, Firefox o Edge podemos abrir las herramientas para desarrolladores y acceder a la pestaña Network.

Después recargamos una página.

Veremos aparecer recursos como:

document
stylesheet
script
image
font
fetch

También podremos analizar información como:

código de estado,
tamaño del recurso,
duración de la petición,
cabeceras HTTP,
dominio desde el que se descarga,
orden en el que se realizan las solicitudes.

Es uno de los mejores ejercicios para empezar a comprender cómo funciona realmente una página web.

Prueba además a comparar una primera carga con una segunda. Dependiendo de la configuración del sitio, podrás observar cómo la caché modifica el comportamiento de algunas peticiones.

Conclusión: una página web es mucho más que HTML, CSS y JavaScript

Cuando empezamos a estudiar desarrollo web es fácil pensar que una página consiste simplemente en escribir HTML, CSS y JavaScript.

Pero detrás existe una infraestructura fascinante.

Cuando escribimos una dirección web y pulsamos Enter intervienen conceptos como URL, DNS, direcciones IP, TCP o QUIC, TLS, HTTP, servidores, aplicaciones backend, bases de datos, HTML, CSS, JavaScript, DOM, caché y renderizado.

Todos ellos trabajan conjuntamente para conseguir algo que nosotros percibimos como una acción casi instantánea: abrir una página web.

Comprender este recorrido también cambia nuestra forma de desarrollar.

Cuando una página tarda demasiado en aparecer, podemos dejar de pensar simplemente que “la web va lenta” y empezar a preguntarnos:

¿Dónde se está perdiendo realmente el tiempo?

¿En el DNS? ¿En la conexión? ¿En el servidor? ¿En PHP? ¿En una consulta SQL? ¿En las imágenes? ¿En JavaScript? ¿Durante el renderizado?

Y esa forma de pensar es precisamente uno de los pasos que nos lleva de crear páginas web a comprender cómo funciona realmente la Web.

Referencias para seguir aprendiendo

Para profundizar en estos conceptos merece la pena consultar documentación de referencia como:

MDN Web Docs — documentación sobre HTTP, DNS, HTML, CSS, JavaScript y tecnologías fundamentales de la Web.
Cloudflare Learning Center — explicaciones especialmente claras sobre DNS, CDN, HTTPS, TLS y funcionamiento de Internet.
web.dev — documentación y buenas prácticas sobre rendimiento, experiencia de usuario y funcionamiento del navegador.
ICANN — información sobre el sistema de nombres de dominio y la infraestructura DNS.
IETF — organismo responsable de muchos de los estándares y protocolos fundamentales utilizados en Internet.