HTTP/2 vs HTTP/3: qué cambió realmente y qué significa para tu sitio

Por qué HTTP/1.1 tenía que irse

Una página moderna necesita docenas de recursos — HTML, CSS, scripts, imágenes, fuentes. HTTP/1.1 solo podía manejar una petición a la vez por conexión, así que los navegadores abrían unas seis conexiones paralelas por host y ponían el resto en cola. Cada conexión pagaba su propio handshake TCP y TLS, y una respuesta lenta retenía todo lo que hubiera en cola detrás en esa conexión. Los apaños de aquella época — sprite sheets, domain sharding, inlining — eran todos trucos para colar más recursos por demasiado pocas tuberías.

Qué arregló HTTP/2

HTTP/2 (2015) sustituyó las tuberías por una: una sola conexión que transporta muchos streams paralelos. Cualquier número de peticiones y respuestas se intercalan sin hacer cola unas detrás de otras en la capa HTTP; las cabeceras se comprimen en lugar de repetirse enteras en cada petición; el coste del handshake se paga una vez.

Para los sitios reales este fue el gran salto — desapareció el malabarismo de las seis conexiones, y las páginas con muchos recursos pequeños se volvieron dramáticamente más rápidas. Es el protocolo que la mayor parte de la web, y la mayoría de las CDNs, sirven hoy. Una nota al pie honesta: HTTP/2 bajó el problema del head-of-line una capa en lugar de eliminarlo. Todos esos streams paralelos siguen viajando por una sola conexión TCP, y TCP insiste en entregar los bytes en orden — así que un solo paquete perdido pausa *todos* los streams hasta que se retransmite. En redes limpias eso es raro; con una señal móvil débil es el impuesto que pagas.

Qué cambia HTTP/3 por debajo

HTTP/3 (2022) ataca ese impuesto restante reemplazando TCP con QUIC, un transporte construido sobre UDP con TLS 1.3 integrado. Tres cosas cambian de verdad. Los handshakes se abaratan: transporte y cifrado se negocian juntos, de modo que una conexión nueva cuesta un viaje de ida y vuelta en lugar de dos o tres — y reconectar con un servidor conocido puede costar cero. La pérdida de paquetes deja de ser contagiosa: QUIC sigue los streams de forma independiente, así que un paquete perdido detiene solo el stream al que pertenecía, no todo lo demás en vuelo. Y las conexiones sobreviven a los cambios de red: pasar de Wi-Fi a datos móviles migra la conexión en lugar de matarla.

Fíjate en el patrón — cada una de estas victorias trata de redes imperfectas. Ahí es exactamente donde brilla HTTP/3: enlaces de alta latencia, Wi-Fi con pérdidas, usuarios móviles en movimiento, largas distancias hasta el servidor.

El dimensionamiento honesto: cuánto vale cada paso

En una buena conexión cerca del servidor, HTTP/3 sobre HTTP/2 es típicamente una mejora pequeña de un solo dígito porcentual — real, medible e invisible para un humano. En un enlace móvil con pérdidas y a distancia, puede ser una diferencia grande y perceptible. El salto de HTTP/1.1 a HTTP/2, en cambio, fue grande para casi todo el mundo. Si tu tráfico es mayoritariamente móvil o lejano, HTTP/3 importa para tus latencias de cola; si es sobre todo escritorio en redes decentes, es un refinamiento.

Mientras tanto, las cosas que dominan el tiempo de carga no se han movido: lo cerca que está el contenido (caché en el edge), lo que pesa (imágenes, compresión) y cuánto de él bloquea el renderizado. Una página cacheada, comprimida con Brotli y con imágenes optimizadas sobre HTTP/2 gana a una página sin optimizar sobre HTTP/3 todas y cada una de las veces — los protocolos deciden milisegundos, la entrega decide segundos. Nuestro edge sirve HTTP/2 hoy, que es donde vive la ganancia de protocolo decisiva; las palancas de entrega por encima son donde va el resto de tu presupuesto de velocidad.

Comprueba qué habla tu sitio realmente

No hace falta adivinar. En el navegador, abre DevTools → Network, activa la columna Protocol y léela: h2 significa HTTP/2, h3 significa HTTP/3. Desde una terminal, curl responde en una línea. Ya que estás, mira también el estado de caché en las cabeceras de respuesta — una mejora de protocolo sobre un viaje al origen sin cachear es pulir la capa equivocada.

Inspecciona el protocolo negociado con curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

Un orden de operaciones sensato

Trata el protocolo como una palanca del tablero, no como el tablero. Primero consigue las victorias decisivas: sirve a través de una caché en el edge para que el contenido esté cerca, comprime el texto con Brotli, lleva las imágenes a WebP/AVIF en dimensiones honestas — eso mueve segundos y beneficia a todos los visitantes. La multiplexación de HTTP/2 es el estándar de mesa y ya transporta tus peticiones en paralelo. Después, si tus datos de campo muestran que las latencias de cola en móvil son donde te duele, los refinamientos de protocolo merecen atención — medidos contra tus propios números, no contra el benchmark de un proveedor.

La verdad incómoda de los debates de protocolos es que son divertidos y están mayormente zanjados, mientras que el peso de las imágenes y la tasa de aciertos de caché son aburridos y decisivos. Optimiza en ese orden.