Cómo funciona un navegador web

Voy a explicarlo por capas — de arquitectura general al detalle del rendering pipeline. Nivel senior técnico.

1. Arquitectura de alto nivel

Un navegador moderno NO es una sola cosa monolítica. Son 7 subsistemas principales que colaboran:

Engines de rendering hoy (2026):

• Blink (fork de WebKit desde 2013) → Chrome, Edge, Opera, Brave, Vivaldi
• Gecko → Firefox
• WebKit → Safari (y todo iOS, obligatoriamente hasta el DMA europeo)
• Servo → experimental en Rust, ahora en Ladybird browser

Engines de JavaScript hoy:

• V8 (Blink) — el más rápido en benchmarks generales, usa Ignition (interpreter) + TurboFan (optimizer JIT)
• SpiderMonkey (Gecko) — con WarpMonkey optimizer
• JavaScriptCore (WebKit) — 4 tiers: LLInt → Baseline → DFG → FTL

2. Ciclo completo de una request — desde teclear URL hasta ver la página

Cuando escribes https://ejemplo.com y presionas Enter:

Fase A — Resolución

1. Autocompletado: el browser sugiere del historial + búsquedas (usa un ML local)
2. DNS resolution (jerárquico):
   • Cache DNS del navegador → cache del SO → resolver del router → resolver del ISP → root/TLD/authoritative servers
3. TCP handshake (3-way) — o directamente QUIC si HTTP/3 (0-RTT con reanudación)
4. TLS handshake — negociación de cipher, verificación de certificado, key exchange

Fase B — Request/Response

5. HTTP request con headers (User-Agent, Cookies, Accept-*, etc.)
6. HTTP response: headers (Content-Type, Cache-Control, CSP, Set-Cookie…) + body

Fase C — Rendering (aquí ocurre la magia)

7. HTML parsing → construye el DOM (tree)
8. Preload scanner — mientras HTML se parsea, un scanner secundario busca subresources (<link>, <script>, <img>) y las empieza a fetchar en paralelo
9. CSS parsing → construye el CSSOM
10. JavaScript execution — puede modificar DOM/CSSOM (a menos que defer/async)
11. Style calculation → merge DOM + CSSOM → Render tree (solo elementos visibles)
12. Layout (reflow) → calcula geometría: posición, tamaño, box model
13. Paint → dibuja píxeles en capas
14. Compositing → combina capas en la GPU

3. El rendering pipeline en detalle

HTML bytes ──parse──► DOM tree ────┐
                                    ├──► Render tree ──► Layout ──► Paint ──► Composite
CSS bytes  ──parse──► CSSOM tree ──┘
                        ▲
                        │ (JS puede modificar DOM/CSSOM en cualquier momento)

Momentos clave que impactan performance (Core Web Vitals):

• FCP (First Contentful Paint): primer píxel de contenido en pantalla
• LCP (Largest Contentful Paint): elemento «importante» (usualmente imagen hero o bloque de texto grande)
• INP (Interaction to Next Paint): latencia de respuesta a interacción del usuario
• CLS (Cumulative Layout Shift): cuánto «saltó» el layout después del load inicial
• TTI (Time to Interactive): cuándo el main thread queda libre para responder

4. Multi-process architecture (por qué Chrome abre 20 procesos)

Chrome popularizó process-per-tab en 2008. Desde 2018 usa Site Isolation: un proceso por origin, no por tab.

Procesos típicos que abre Chrome ahora mismo:

Beneficios:

1. Aislamiento de crashes: si un tab crashea, no se lleva el browser
2. Sandbox de seguridad: renderer no puede tocar filesystem del host directamente — todo va via IPC al browser process
3. Paralelismo: aprovecha múltiples cores
4. Mitigación Spectre/Meltdown: procesos separados por site previenen exfiltración cross-origin via side-channel

Costo: consume mucha RAM (cada proceso tiene su V8, su heap). Es el trade-off por seguridad y estabilidad.

5. Modelo de seguridad

Same-Origin Policy (SOP)

La regla fundamental: código de origin A NO puede leer datos de origin B. Un origin = scheme + host + port.

• https://a.com ≠ http://a.com (scheme distinto)
• https://a.com ≠ https://a.com:8080 (port distinto)
• https://a.com/x == https://a.com/y (path no importa)

CORS (Cross-Origin Resource Sharing)

Mecanismo para relajar SOP con permiso explícito del servidor. Headers:

• Access-Control-Allow-Origin: https://otro.com
• Preflight OPTIONS para requests «no-simples»

CSP (Content Security Policy)

El servidor declara qué recursos puede cargar la página:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net

Previene XSS aunque el atacante logre inyectar HTML.

Sandbox del renderer

El proceso renderer corre con permisos mínimos: no puede abrir archivos, no puede hacer syscalls arbitrarios. Todo debe pasar por IPC al browser process, que valida.

Otros mecanismos

• HSTS: fuerza HTTPS
• Subresource Integrity: hash del recurso en <script integrity="sha384-...">
• HTTPS certificate validation: cadena de confianza contra root CA store del SO
• Permission API: notificaciones, geolocation, camera, etc. requieren permiso explícito

6. Networking layer

Los navegadores modernos hablan 3 protocolos HTTP:

QUIC es el diferenciador: al ir sobre UDP evita el head-of-line blocking del TCP (si un paquete se pierde, solo bloquea su stream, no toda la conexión).

Optimizaciones que el browser hace:

• Connection pooling (reuse de sockets)
• DNS prefetch (<link rel="dns-prefetch">)
• Preconnect (<link rel="preconnect">) — hace TCP+TLS anticipado
• Preload/Prefetch de recursos críticos
• Service Workers (proxy JS que intercepta requests, permite offline-first)

7. Storage layer

Un navegador maneja varios «backends» de storage:

8. JavaScript execution — dónde muere la performance

El JS engine hace varias fases:

1. Parsing → AST
2. Bytecode compilation (Ignition en V8)
3. Ejecución interpretada — código «frío»
4. Profiling en runtime — detecta código «caliente»
5. JIT optimización (TurboFan) — recompila hot code a machine code optimizado
6. Deoptimización — si una asunción de la optimización falla (ej. tipo de variable cambia), revierte al bytecode

El single-threaded event loop:

• 1 hilo principal para JS del renderer
• Callbacks entran a la queue (tasks + microtasks)
• Bloquear ese hilo = bloquear la UI
• Web Workers = hilos separados sin acceso al DOM
• Service Workers = threads especiales que persisten background

Por qué las apps modernas son lentas:

• Frameworks pesados (React/Angular/Vue) → mucho JS parsing + execution en el load inicial
• Cada component render puede triggerar reflow
• Third-party scripts (analytics, ads) — bloquean main thread

9. Un detalle raro pero fascinante

El browser NO tiene que esperar el HTML completo para empezar a pintar. Usa:

• Streaming HTML parsing: parsea a medida que llegan los bytes
• Speculative rendering: hace layout de lo que ya tiene con supuestos sobre lo pendiente
• Preload scanner: fetch de recursos declarados antes de que el parser llegue a ellos

Por eso una página bien optimizada puede mostrar el «First Contentful Paint» en <1s aunque el DOMContentLoaded completo tarde 5s.

10. Curiosidades que quizás no sabías

1. localhost tiene HTTPS gratis: navegadores tratan localhost como origin seguro sin certificado válido para APIs que requieren HTTPS
2. Third-party cookies están muriendo: Chrome las deprecates en 2026, Safari/Firefox ya bloquean por default
3. Cada <script> sincrónico bloquea el parser HTML: por eso defer/async importan
4. CSS bloquea el rendering pero NO el parsing: el browser sigue parseando HTML pero no puede paintar hasta tener CSSOM
5. Los iframes tienen su propio process bajo Site Isolation: por eso los sitios con muchos iframes de ads consumen tanta RAM
6. El GPU process no tiene memoria persistente — si crashea, todos los tabs pierden compositing por unos ms

Referencias para profundizar

Si quieres ir más al fondo:

• «How Browsers Work» (Tali Garsiel) — el clásico que todos citan
• web.dev de Google — Core Web Vitals + performance patterns
• HTML Living Standard (WHATWG) — la spec real, no HTML5
• V8 blog — cómo funciona el JIT interno
• Servo docs — arquitectura moderna en Rust