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:
| Subsistema | Responsabilidad |
|---|---|
| UI layer | Barra de URL, botones, tabs, menús |
| Browser process (main) | Coordina TODO: gestiona ventanas, procesos hijos, permisos |
| Rendering engine | Convierte HTML+CSS en píxeles: Blink, Gecko, WebKit |
| JavaScript engine | Compila y ejecuta JS: V8, SpiderMonkey, JavaScriptCore |
| Networking stack | HTTP/S, DNS, WebSocket, QUIC |
| GPU process | Compositing acelerado por hardware |
| Storage layer | Cookies, localStorage, IndexedDB, caché HTTP |
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
- Autocompletado: el browser sugiere del historial + búsquedas (usa un ML local)
- DNS resolution (jerárquico):
- Cache DNS del navegador → cache del SO → resolver del router → resolver del ISP → root/TLD/authoritative servers
- TCP handshake (3-way) — o directamente QUIC si HTTP/3 (0-RTT con reanudación)
- TLS handshake — negociación de cipher, verificación de certificado, key exchange
Fase B — Request/Response
- HTTP request con headers (User-Agent, Cookies, Accept-*, etc.)
- HTTP response: headers (Content-Type, Cache-Control, CSP, Set-Cookie…) + body
Fase C — Rendering (aquí ocurre la magia)
- HTML parsing → construye el DOM (tree)
- Preload scanner — mientras HTML se parsea, un scanner secundario busca subresources (
<link>,<script>,<img>) y las empieza a fetchar en paralelo - CSS parsing → construye el CSSOM
- JavaScript execution — puede modificar DOM/CSSOM (a menos que
defer/async) - Style calculation → merge DOM + CSSOM → Render tree (solo elementos visibles)
- Layout (reflow) → calcula geometría: posición, tamaño, box model
- Paint → dibuja píxeles en capas
- 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:
| Proceso | Cantidad típica | Función |
|---|---|---|
| Browser (main) | 1 | Coordina todo |
| Renderer | 1 por origin abierto | Parsing + JS + Layout de ese sitio |
| GPU | 1 | Compositing acelerado |
| Network | 1 | Conexiones HTTP |
| Storage | 1 | Cookies, IndexedDB, cache |
| Utility (multiples) | varios | Audio, video decoding, spelling, etc. |
| Extension | 1 por extension activa | Sandboxed |
| Plugin | 1 por plugin (raro hoy) | Legacy Flash/PDF |
Beneficios:
- Aislamiento de crashes: si un tab crashea, no se lleva el browser
- Sandbox de seguridad: renderer no puede tocar filesystem del host directamente — todo va via IPC al browser process
- Paralelismo: aprovecha múltiples cores
- 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
OPTIONSpara 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:
| Versión | Transport | Multiplexing | Uso hoy |
|---|---|---|---|
| HTTP/1.1 | TCP | No (head-of-line blocking) | Fallback |
| HTTP/2 | TCP + TLS | Sí (multiplexed streams) | Mayoritario |
| HTTP/3 | QUIC (UDP) + TLS 1.3 | Sí (sin HoL blocking real) | Adopción creciente |
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:
| Backend | Cuota típica | Persistencia | Sync? |
|---|---|---|---|
| Cookies | 4 KB/cookie | Configurable expire | Sí (bloquea) |
| localStorage | 5-10 MB por origin | Persiste | Sí (bloquea) |
| sessionStorage | 5-10 MB por origin | Solo la sesión (tab) | Sí (bloquea) |
| IndexedDB | GB (configurable) | Persiste | Async |
| Cache Storage | GB | Persiste | Async |
| File System Access | Filesystem real | Persiste | Async |
| HTTP Cache | Configurable | Persiste hasta expiration | Transparente |
8. JavaScript execution — dónde muere la performance
El JS engine hace varias fases:
- Parsing → AST
- Bytecode compilation (Ignition en V8)
- Ejecución interpretada — código «frío»
- Profiling en runtime — detecta código «caliente»
- JIT optimización (TurboFan) — recompila hot code a machine code optimizado
- 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
localhosttiene HTTPS gratis: navegadores tratanlocalhostcomo origin seguro sin certificado válido para APIs que requieren HTTPS- Third-party cookies están muriendo: Chrome las deprecates en 2026, Safari/Firefox ya bloquean por default
- Cada
<script>sincrónico bloquea el parser HTML: por esodefer/asyncimportan - CSS bloquea el rendering pero NO el parsing: el browser sigue parseando HTML pero no puede paintar hasta tener CSSOM
- Los iframes tienen su propio process bajo Site Isolation: por eso los sitios con muchos iframes de ads consumen tanta RAM
- 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
Deja una respuesta