Navegadores web: qué son y cómo funcionan de verdad por dentro

Escribes nelkodev.com, pulsas Enter y en menos de un segundo tienes una página delante. Esa frase esconde una de las preguntas de entrevista más viejas del oficio: "¿qué pasa exactamente cuando escribes una URL y pulsas Enter?". La mayoría de guías sobre navegadores web se quedan en "el navegador interpreta el código y lo muestra". Eso no explica nada. Entre tu tecla y el primer píxel pintado hay una resolución de nombres, una conexión de red, un cifrado, una petición, una respuesta y un pipeline de renderizado con cinco fases. Llevo más de veinte años escribiendo código sobre esa fontanería, y entenderla es la diferencia entre usar el navegador y saber por qué a veces va lento, por qué el candado importa y por qué el modo incógnito no te hace invisible.

Voy a contarlo entero, sin saltarme la parte difícil. Al final vas a mirar la barra de direcciones de otra manera.

Qué es un navegador web (y qué no es: navegador, buscador y motor)

Un navegador web es un programa que pide documentos a servidores por internet, los interpreta y los pinta en tu pantalla para que puedas leerlos e interactuar con ellos. Chrome, Firefox, Safari, Edge y Brave son navegadores. Hasta aquí, la definición que da todo el mundo.

Lo que casi nadie aclara son las tres cosas que la gente confunde a diario:

• Un navegador es la aplicación (Chrome). Es lo que instalas.
• Un buscador es un sitio web al que el navegador accede (Google, Bing, DuckDuckGo). No instalas Google; lo visitas. Que Chrome abra Google al arrancar no los convierte en lo mismo.
• Un motor es el componente interno que convierte el código de la página en algo visible. No lo ves ni lo instalas por separado: viene dentro del navegador.

Esta distinción no es pedantería. Cuando alguien dice "cambia de navegador porque este rastrea", a veces solo hace falta cambiar el buscador por defecto. Y cuando dice "todos los navegadores son iguales por dentro", resulta que casi tiene razón, pero por un motivo que verás enseguida: comparten motor.

Qué pasa de verdad cuando escribes una URL y pulsas Enter

El recorrido tiene dos grandes mitades. Primero, la red: conseguir el documento. Segundo, el render: convertir ese documento en píxeles. Ambas ocurren dentro del navegador, pero son mundos distintos.

La mitad de red, en orden:

1. El navegador traduce el nombre nelkodev.com a una dirección IP (DNS).
2. Abre una conexión con esa IP (TCP) y, si es https, la cifra (TLS).
3. Envía una petición HTTP y recibe una respuesta: normalmente HTML.

La mitad de render empieza cuando llega ese HTML. Voy paso a paso, porque cada uno tiene una trampa que conviene conocer.

Paso 1: DNS, la agenda de contactos de internet

Los ordenadores no se hablan por nombres, sino por direcciones IP (192.0.2.10 o su versión IPv6). El DNS, Domain Name System, es la guía que traduce un nombre legible a esa dirección. Cuando pulsas Enter, tu navegador pregunta "¿cuál es la IP de nelkodev.com?" y alguien le contesta.

Ese "alguien" es una cadena de cachés. Tu propio equipo guarda respuestas recientes; si no la tiene, pregunta al resolver de tu proveedor de internet; si tampoco, se sube por la jerarquía hasta los servidores autoritativos del dominio. Puedes ver la respuesta cruda desde tu terminal:

# Resolver un dominio a su dirección IP
dig +short nelkodev.com

El error típico aquí no es que "internet no va", sino que una entrada cacheada está obsoleta. Cambias un dominio de servidor y durante horas media red sigue viendo la IP vieja porque el DNS tiene un TTL, tiempo de vida, y hasta que expira nadie vuelve a preguntar. Si alguna vez has migrado una web y te ha funcionado a ti pero no a un cliente, casi siempre es esto: cada uno tenía una respuesta DNS distinta en caché.

Paso 2: TCP y TLS, abrir y cifrar la conexión (el candado del https)

Con la IP en la mano, el navegador abre una conexión. Sobre internet, esa conversación fiable la sostiene TCP: un saludo de tres mensajes que garantiza que ambos extremos están y que los datos llegan en orden.

Si la dirección es https, encima de TCP se monta TLS, y aquí está el candado de la barra de direcciones. En el handshake TLS el servidor presenta un certificado que demuestra que es quien dice ser, y ambos extremos acuerdan una clave para cifrar todo lo que venga después. A partir de ese momento, quien esté en medio de la red, el wifi de la cafetería, tu proveedor, ve que hablas con nelkodev.com, pero no ve el contenido.

Dos malentendidos frecuentes que conviene enterrar:

• El candado no significa "sitio seguro" ni "sitio de confianza". Significa "la conexión está cifrada y el certificado es válido para este dominio". Una web de phishing puede tener candado perfectamente: se saca un certificado gratis en cinco minutos. El candado protege el transporte, no tus intenciones.
• https no oculta a quién visitas, solo qué intercambias. El nombre del dominio viaja en claro en varias capas. Tu red sabe que entraste en un banco; no sabe tu contraseña.

Paso 3: la petición y la respuesta HTTP

Con la conexión abierta y cifrada, el navegador manda una petición HTTP. Es texto estructurado: un método (GET), una ruta, y una lista de cabeceras que describen quién pregunta y qué acepta. El servidor responde con un código de estado, sus propias cabeceras y, normalmente, un cuerpo con HTML. Puedes espiar toda esa conversación:

# Ver la petición, el handshake TLS y las cabeceras de respuesta
curl -v https://nelkodev.com

El código de estado es la primera pista de qué ha pasado: 200 es "aquí lo tienes", 301 y 302 son redirecciones, 404 es "esto no existe", 500 es "me he roto por dentro". Un detalle que ahorra depuraciones: muchas cabeceras de la respuesta gobiernan lo que el navegador hará después. Cache-Control decide cuánto tiempo guarda el navegador ese recurso; Set-Cookie le pide que almacene una cookie; Content-Type le dice si lo que llega es HTML, una imagen o un JSON. El navegador obedece esas cabeceras, así que la mitad de los comportamientos "raros" de una web se explican leyéndolas, no tocando el código de la página.

El motor de renderizado: de HTML y CSS a píxeles

Llegó el HTML. Ahora empieza la segunda mitad, la que convierte texto en una página. El componente que hace esto se llama motor de renderizado, y su trabajo, según lo describe la propia documentación de MDN sobre cómo funcionan los navegadores, sigue cinco fases en orden:

1. Parseo del HTML → DOM. El navegador lee el HTML y construye un árbol de objetos en memoria, el DOM (Document Object Model). Cada etiqueta es un nodo.
2. Parseo del CSS → CSSOM. Hace lo mismo con las hojas de estilo: construye el CSSOM, otro árbol que dice cómo se ve cada nodo.
3. Render tree. Combina DOM y CSSOM en un solo árbol con lo que sí se va a pintar. Lo que tiene display: none no entra aquí.
4. Layout (o reflow). Calcula la geometría: cuánto mide y dónde va cada caja en la pantalla.
5. Paint. Rellena esos rectángulos con píxeles: colores, texto, bordes, imágenes. Después, la composición junta las distintas capas en la imagen final.

Aquí está la trampa que penaliza a webs enteras: un <script> sin más atributos, colocado en mitad del documento, detiene la construcción del DOM hasta que ese script se descarga y se ejecuta. El parser se para en seco.

<body>
  <h1>Contenido importante</h1>
  <!-- Este script bloquea el parseo de todo lo que viene debajo -->
  <script src="libreria-pesada.js"></script>
  <p>Este párrafo no aparece hasta que el script termina.</p>
</body>

Por eso los scripts van al final del <body> o con los atributos defer o async, que le dicen al navegador "sigue construyendo la página, ya ejecutaré esto luego". Es de los cambios más baratos y con más impacto en la velocidad percibida de un sitio.

Cuántos motores de render quedan de verdad: Blink, Gecko y WebKit

La lista de "navegadores más usados" que repiten todas las guías da una impresión falsa de variedad. Por debajo, hoy solo quedan tres motores de renderizado con desarrollo activo:

Motores que existieron y ya no cuentan: Trident (el de Internet Explorer) y EdgeHTML (el primer Edge) están descontinuados. Microsoft tiró EdgeHTML a la basura y reconstruyó Edge sobre Chromium. Es decir, el navegador de Microsoft usa hoy el motor de Google. Puedes contrastar el linaje en la documentación de Chrome sobre Blink.

Que queden tres motores importa por una razón práctica: si algo funciona en los tres, funciona en la web real. No necesitas probar en quince navegadores; necesitas probar en Blink, Gecko y WebKit. El resto es repetición.

Por qué casi todos los navegadores son Chromium con otra piel

Aquí está el dato que reordena mentalmente toda la lista. Edge, Brave, Opera y Vivaldi son, por dentro, Chromium: el mismo motor Blink, el mismo intérprete de JavaScript, el mismo comportamiento de render. Lo que cambia es la capa de encima, la interfaz, los ajustes de privacidad por defecto, el bloqueador de anuncios, la sincronización, pero el corazón que decide cómo se ve y se ejecuta una página es común.

Esto tiene una cara buena y una mala. La buena: como desarrollador, un sitio que va bien en Chrome va prácticamente igual en Edge, Brave y Opera, porque comparten motor. La mala: cuando un solo motor domina el mercado, ese motor deja de facto de ser un estándar acordado y pasa a ser "lo que haga Blink". La web sana necesita que Gecko y WebKit sigan vivos, aunque tú uses Chrome. Elegir Firefox de vez en cuando no es nostalgia: es mantener abierta la competencia entre motores.

Así que cuando alguien pregunta "¿cuál es la diferencia real entre Chrome, Edge, Brave y Opera?", la respuesta honesta es: la piel, los valores por defecto de privacidad y el ecosistema. El motor, casi ninguna.

El motor de JavaScript y por qué el hilo principal es uno solo

Dentro del navegador hay un segundo motor especializado solo en ejecutar JavaScript. También va emparejado con cada motor de render: V8 en Blink/Chrome, SpiderMonkey en Gecko/Firefox y JavaScriptCore en WebKit/Safari. Su trabajo es coger tu código y ejecutarlo rápido.

Lo importante no es el nombre, sino una restricción que casi nadie explica y que gobierna el rendimiento de toda web moderna: el navegador ejecuta tu JavaScript, calcula estilos, hace el layout y pinta, todo en un único hilo principal. MDN lo dice sin rodeos: en su mayor parte, los navegadores se consideran de un solo hilo. Y ese hilo tiene un presupuesto de tiempo brutal: para mantener una animación fluida a 60 imágenes por segundo, cada frame debe estar listo en 16,67 milisegundos (1000 dividido entre 60).

La consecuencia es directa: si tu JavaScript ocupa el hilo principal, la página se congela. No hay más hilo que pueda pintar mientras tanto.

// Todo esto corre en el mismo hilo que pinta la interfaz.
// Mientras el bucle no acabe, la página no responde a clics ni scroll.
const inicio = performance.now();
while (performance.now() - inicio < 3000) {
  // Tres segundos bloqueando el hilo principal
}
console.log('Ahora el navegador vuelve a responder');

Ese bucle deja la pestaña muerta tres segundos. Es la versión exagerada de lo que hace, en pequeño, cualquier cálculo pesado mal colocado: un ordenamiento de miles de filas, un parseo enorme, una librería que hace demasiado al arrancar. Cuando una web "va a tirones" en un móvil, casi siempre es el hilo principal saturado, no la red. La solución pasa por trocear el trabajo, aplazarlo, o sacarlo a un Web Worker, el único mecanismo que sí corre en otro hilo, a cambio de no poder tocar el DOM directamente.

Caché, cookies y almacenamiento local: qué guarda tu navegador y para qué

El navegador no olvida todo entre visitas. Guarda cosas, y conviene saber cuáles y con qué reglas, porque cada una resuelve un problema distinto:

• Caché. Copias de recursos que ya descargó (imágenes, CSS, scripts) para no volver a pedirlos. La gobierna la cabecera Cache-Control que manda el servidor. Es la razón de que la segunda visita a una web cargue mucho más rápido, y también la razón del clásico "recarga forzada con Ctrl+F5": le dices al navegador que ignore la caché y vuelva a pedirlo todo.
• Cookies. Trozos pequeños de texto que el servidor pide guardar y que el navegador reenvía en cada petición a ese mismo dominio. Sirven sobre todo para mantener la sesión: es lo que hace que sigas con la sesión iniciada al recargar. Al viajar en cada petición, no conviene meter en ellas nada grande.
• Almacenamiento local. localStorage y sessionStorage guardan datos en el navegador que no viajan al servidor en cada petición, a diferencia de las cookies.

// localStorage: persiste entre pestañas y reinicios (mismo origen)
localStorage.setItem('tema', 'oscuro');
const tema = localStorage.getItem('tema');

// sessionStorage: se borra al cerrar la pestaña
sessionStorage.setItem('paso', '2');

El error de bulto aquí es de seguridad: nunca guardes tokens de sesión ni datos sensibles en localStorage. Cualquier script que se cuele en tu página, un XSS, puede leerlo entero, porque localStorage es accesible desde JavaScript sin ninguna barrera. Las cookies marcadas HttpOnly, en cambio, son invisibles para JavaScript. Para lo delicado, cookie HttpOnly; para preferencias de interfaz, localStorage.

Modo incógnito: qué oculta y qué NO oculta (tu proveedor y tu empresa siguen viéndote)

El modo incógnito es la función peor entendida del navegador, y el malentendido tiene consecuencias reales. Según el soporte oficial de Google Chrome, al cerrar todas las ventanas de incógnito el navegador no conserva el historial ni los datos de los sitios que visitaste y no te mantiene la sesión iniciada. Los marcadores que crees y los archivos que descargues, en cambio, sí se quedan.

Y aquí la letra que importa: el modo incógnito no te hace invisible. Sigue perfectamente contigo:

• Tu proveedor de internet sigue viendo a qué dominios te conectas.
• Tu empresa, tu colegio o quien administre la red siguen viendo tu actividad.
• Los propios sitios que visitas te ven como a cualquier otro visitante y pueden identificarte en cuanto inicies sesión.

Dicho claro: incógnito borra tus rastros en ese ordenador, para que quien lo use después no vea por dónde anduviste. No te oculta de la red ni de los servidores. Para el ordenador compartido de casa, sirve. Para saltarte el filtrado de tu empresa o para "que no me rastreen", no sirve para nada. Si lo que buscas es que tu proveedor no vea tus dominios, eso es otra herramienta (una VPN o DNS cifrado), y tampoco es una capa de invisibilidad total.

Cuota de navegadores en España (datos de StatCounter, junio de 2026)

Los listados de "los más usados" ordenan por popularidad sin dar una cifra ni una fecha que puedas comprobar. Prefiero darte el dato con fuente y con fecha, porque estas cifras se mueven. Según StatCounter para España, sumando escritorio, móvil y tablet, en junio de 2026 el reparto era:

Fíjate en la columna de la derecha con lo que ya sabes: de los seis, cuatro son Blink. La cuota real de Blink en España supera con holgura lo que sugiere la línea de "Chrome". Esa es la foto que las listas al uso no te dan, y es justo la que necesitas para decidir dónde probar una web.

Si quieres bajar del navegador al código, cómo se construye lo que aquí solo has visto llegar y pintarse, tienes más sobre mi forma de trabajar el desarrollo web a medida y, si tienes un proyecto entre manos, podemos hablar de tu proyecto directamente. Entender la máquina por dentro es lo que separa una web que funciona de una que solo se ve bien el primer día.