¿Qué son HTTP/2 y HTTP/3? Guía práctica para sitios WordPress

HTTP/2 y HTTP/3 son las dos versiones actuales del Hypertext Transfer Protocol, el lenguaje que los navegadores usan para solicitar páginas a los servidores web. HTTP/2 fue estandarizado en 2015 y está soportado por el 100% de los navegadores modernos. HTTP/3, finalizado como RFC 9114 en 2022, está soportado por todos los navegadores principales desde 2024. Ambos son actualizaciones sin fricción sobre HTTP/1.1: mismas URLs, mismo HTML, pero cargas de página significativamente más rápidas, especialmente en redes móviles y conexiones de alta latencia.

Respuesta rápida: ¿qué versión debería usar mi sitio WordPress?

En 2026, la respuesta correcta es "HTTP/3 con HTTP/2 como fallback". Cada navegador negocia la versión más alta que ambas partes soportan, así que no tienes que elegir. Si tu servidor habla HTTP/3, los navegadores modernos lo usan; los navegadores más antiguos caen a HTTP/2; los clientes muy antiguos caen a HTTP/1.1. No hay escenario en el que HTTP/2 o HTTP/3 sea más lento que HTTP/1.1 para una página WordPress real, así que la única pregunta es si tu stack de hosting lo soporta.

¿Qué problema resuelve HTTP/2 frente a HTTP/1.1?

HTTP/1.1, el protocolo que sostuvo la web de 1997 a 2015, tiene una falla fatal en un sitio moderno: abre una conexión TCP por recurso, y solo seis en paralelo por dominio. Una página WordPress típica carga entre 50 y 150 recursos (CSS, JS, imágenes, fuentes, scripts de tracking). Bajo HTTP/1.1, esos 100+ requests se serializan en una cola de seis conexiones, cada una esperando que termine la anterior. El navegador literalmente se queda quieto esperando a que se liberen huecos.

HTTP/2 resuelve esto con tres cambios:

Multiplexación. Una única conexión TCP transporta un número ilimitado de pares request/response paralelos (llamados streams). Los 150 recursos viajan por una sola conexión, entrelazados.
Compresión de cabeceras (HPACK). Las cabeceras HTTP (cookies, User-Agent, referer) suman a menudo varios KB por petición. HPACK las comprime y recuerda las cabeceras repetidas, reduciendo el overhead por petición de kilobytes a bytes.
Framing binario. HTTP/1.1 es basado en texto y ambiguo de parsear. HTTP/2 usa un formato binario de frames, más rápido de procesar para servidores y proxies, y elimina toda una clase de ataques de smuggling y parsing.

Efecto neto: una página WordPress que carga en 4 segundos sobre HTTP/1.1 carga normalmente en 1.5 a 2.5 segundos sobre HTTP/2, en el mismo servidor. La mejora es mayor en redes móviles porque el overhead de establecimiento de conexión se amortiza entre todas las peticiones.

¿Qué añade HTTP/3 sobre HTTP/2?

HTTP/3 mantiene todo lo que introdujo HTTP/2 (multiplexación, compresión de cabeceras, framing binario) pero reemplaza el transporte subyacente. En lugar de TCP, HTTP/3 corre sobre QUIC, un protocolo de transporte construido sobre UDP. Suena a detalle de implementación, pero arregla tres problemas reales de rendimiento:

Head-of-line blocking en la capa TCP. HTTP/2 multiplexa streams sobre una conexión TCP, pero TCP entrega los paquetes en orden. Si un paquete se pierde, todos los streams de esa conexión se quedan bloqueados hasta que llega la retransmisión. QUIC maneja la pérdida de paquetes por stream, así que un paquete perdido solo afecta al stream al que pertenece.
Configuración de conexión más rápida. Establecer una conexión HTTPS sobre TCP requiere tres viajes de ida y vuelta (handshake TCP, luego handshake TLS). QUIC los combina en un solo round trip para conexiones nuevas, y cero round trips para conexiones repetidas en pocos minutos (llamado 0-RTT). En una conexión móvil con 100ms de latencia, esto ahorra 200-300ms antes incluso de que empiece a cargar el primer byte de contenido.
Migración de conexión. Las conexiones QUIC se identifican por un connection ID, no por IP + puerto. Cuando un teléfono cambia de Wi-Fi a celular, la conexión QUIC sobrevive. Las conexiones TCP tendrían que reconectarse.

Ganancia real frente a HTTP/2: normalmente 5-15% más rápido en primeras cargas, más en redes móviles con pérdida, menos en una conexión cableada estable.

¿Cómo compruebo qué versión HTTP usa actualmente mi sitio WordPress?

Cuatro métodos fiables, del más rápido al más autoritativo:

Reporte de InspectWP. La sección de Performance de cualquier reporte de InspectWP lista la versión HTTP negociada para el documento principal. Una línea, sin configuración.
DevTools de Chrome. Abre DevTools (F12), pestaña Network, recarga la página, clic derecho en cualquier cabecera de columna y habilita "Protocol". La columna muestra h2 para HTTP/2 y h3 para HTTP/3 (también llamado http/3 en algunas versiones de Chrome).
Línea de comandos con curl. Ejecuta curl -I --http2 https://tusitio.com para HTTP/2 o curl -I --http3 https://tusitio.com para HTTP/3 (se necesita curl 7.66+). La línea de respuesta muestra HTTP/2 200 o HTTP/3 200.
Herramientas públicas. https://http3check.net testea específicamente el soporte HTTP/3. https://tools.keycdn.com/http2-test testea el soporte HTTP/2. Ambos devuelven la versión negociada y la cabecera Alt-Svc (que anuncia el soporte HTTP/3).

Un detalle: un sitio puede anunciar HTTP/3 en su cabecera Alt-Svc sin que HTTP/3 realmente funcione. La cabecera le dice al navegador "la próxima vez, prueba HTTP/3 en el puerto UDP 443", pero si UDP está bloqueado en algún punto del camino, el navegador cae silenciosamente a HTTP/2. Verifica siempre con un request real, no solo con la cabecera Alt-Svc.

¿Cómo habilito HTTP/2 o HTTP/3 en un sitio WordPress?

Las versiones HTTP se negocian a nivel de servidor web. WordPress en sí no tiene nada que ver con esto; la elección se hace entre tu stack de hosting y el navegador. Tres escenarios cubren casi todos los sitios:

Escenario 1: hosting WordPress gestionado

Casi todos los hosts WordPress gestionados (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) llevan HTTP/2 por defecto desde 2018. El soporte HTTP/3 está muy extendido pero no es universal en 2026. Kinsta, Cloudways, SiteGround, Raidboxes y Pressable tienen HTTP/3 activado por defecto. WP Engine lo ofrece como toggle. Si tu host no está en esta lista, pregunta al soporte; suele ser un cambio de un clic.

Escenario 2: hosting compartido con cPanel o Plesk

Los hosts con cPanel (IONOS, Hostinger, muchos revendedores) normalmente llevan HTTP/2 por defecto y HTTP/3 en cuentas más nuevas. Comprueba habilitando EasyApache 4 con el módulo mod_http2 si no está ya presente. HTTP/3 en Apache requiere el módulo mod_http3 que aún se considera experimental. El camino pragmático en hosting compartido es poner Cloudflare por delante (el plan gratuito basta) y dejar que Cloudflare termine HTTP/3, que es su default desde 2019.

Escenario 3: VPS o servidor dedicado autogestionado

La configuración depende de tu servidor web:

nginx. HTTP/2 necesita nginx 1.9.5+ y la directiva http2 en la línea listen: listen 443 ssl http2;. HTTP/3 necesita nginx 1.25+ compilado con soporte QUIC: listen 443 quic reuseport; listen 443 ssl; más add_header Alt-Svc 'h3=":443"; ma=86400';. El flag reuseport es crítico o HTTP/3 falla en arrancar silenciosamente.
Apache. HTTP/2 necesita mod_http2 habilitado y la directiva Protocols h2 h2c http/1.1 en tu virtual host. HTTP/3 en Apache sigue siendo experimental; la mayoría de instalaciones Apache en producción se quedan en HTTP/2 y ponen nginx, Caddy o Cloudflare por delante para HTTP/3.
Caddy. HTTP/3 está habilitado por defecto desde Caddy 2.6. Nada que configurar; si HTTPS funciona, HTTP/3 funciona.
LiteSpeed y OpenLiteSpeed. Ambos llevan HTTP/3 por defecto. Una de las razones por las que LiteSpeed ha ganado cuota en el mercado de hosting WordPress.

Un requisito que se pasa por alto en setups autogestionados: HTTP/3 requiere el puerto UDP 443 abierto en tu firewall. Muchas configuraciones de servidor por defecto solo abren TCP 443. En Ubuntu, sudo ufw allow 443/udp; en otros firewalls, el equivalente.

¿Qué papel juegan Cloudflare y otros CDNs?

Un CDN colocado delante de tu servidor origen normalmente termina el protocolo moderno en el edge, y luego habla con tu origen sobre HTTP/1.1 o HTTP/2. Desde la perspectiva del visitante, la conexión al nodo edge del CDN (a menudo 20-50ms de distancia) es HTTP/3, rápida y moderna. El enlace del CDN al origen ocurre servidor a servidor en redes de datacenter donde el protocolo importa mucho menos. Por eso poner Cloudflare delante de un host compartido que solo ejecuta HTTP/1.1 sigue dando la mayor parte del beneficio de velocidad. El visitante nunca toca directamente tu origen.

La trampa: si tu origen devuelve una cabecera cache-busting (no-cache, no-store) o tu contenido es no cacheable (páginas WordPress logueadas, carrito WooCommerce), el CDN tiene que ir al origen en cada petición, y el lento salto origen-a-CDN se vuelve el cuello de botella. Para esos casos, el protocolo en el origen sigue importando.

Errores comunes y cómo evitarlos

Tratar HTTP/2 como bala mágica para sitios lentos. HTTP/2 arregla el overhead de conexión. No arregla PHP lento, queries no optimizadas, imágenes hero de 5MB, ni JavaScript que bloquea el render. Si tu TTFB (time to first byte) es de 2 segundos, cambiar a HTTP/3 te ahorra 200ms. Los otros 1800ms siguen siendo PHP y base de datos.
Olvidar mantener HTTP/1.1 habilitado. Los crawlers de motores de búsqueda, las herramientas de monitorización y las librerías cliente antiguas a veces solo hablan HTTP/1.1. Deshabilitar HTTP/1.1 por completo las rompe. Los servidores web modernos negocian automáticamente la versión más alta soportada mutuamente; mantén las tres (h3, h2, http/1.1) habilitadas.
Concatenar e inlinear assets por costumbre de HTTP/1.1. Bajo HTTP/1.1, combinar 30 archivos CSS en uno era una gran victoria por el límite de conexiones. Bajo HTTP/2 y HTTP/3 esa optimización deja de importar y puede incluso perjudicar (un único bundle grande invalida la caché ante cualquier cambio; 30 archivos pequeños solo invalidan los que cambiaron). La mayoría de plugins de rendimiento WordPress aún ponen "combinar todo" por defecto porque los usuarios lo esperan, pero ya no es el default correcto en 2026.
Asumir que Alt-Svc significa que HTTP/3 funciona. La cabecera anuncia soporte HTTP/3; no garantiza que la conexión realmente se establezca. Verifica siempre con curl o DevTools.
Bloquear UDP en el firewall. Una causa común de que HTTP/3 no funcione silenciosamente. Comprueba tanto el firewall del servidor como el firewall de red (security group del proveedor cloud, filtrado a nivel ISP en conexiones de consumidor).

HTTP/2, HTTP/3 y Core Web Vitals

Los Core Web Vitals de Google miden Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). De los tres, LCP es el más afectado por la versión HTTP. El elemento LCP (normalmente la imagen hero o el mayor bloque por encima del pliegue) tiene que descargarse completamente antes de poder reportar LCP, y la velocidad de descarga es exactamente lo que HTTP/2 y HTTP/3 mejoran. Los sitios que pasan de HTTP/1.1 a HTTP/2 ven LCP bajar 300-800ms de media. El salto de HTTP/2 a HTTP/3 es menor, normalmente 50-200ms, pero en redes móviles con pérdida de paquetes puede ser mayor.

Qué verifica InspectWP

La sección de Performance de cada reporte InspectWP muestra qué versión HTTP se negoció para el documento principal, más la codificación de contenido (gzip, Brotli) y el tamaño total del HTML. Si tu sitio aún está en HTTP/1.1 en 2026, el reporte lo marca como advertencia, porque es una de las mejoras de rendimiento de mayor impacto y menor esfuerzo disponibles, normalmente un único interruptor en el panel del hosting. Si estás en HTTP/2 pero no en HTTP/3, eso aparece como informativo; HTTP/3 es el default moderno pero HTTP/2 sigue siendo perfectamente aceptable. La versión que ve tu navegador es la versión que reciben tus visitantes, así que el reporte refleja el rendimiento real, no la configuración teórica.