El director técnico marca "Habilitar HTTP/3" en la CDN. Lighthouse gana tres puntos. El servidor TTFB no se movió: 890 ms en la página de la cesta. La dirección concluye que “el alojamiento es lento”. En realidad, HTTP/3 optimiza principalmente el transporte, no la generación de PHP o una base de datos sobrecargada.
HTTP/3 se basa en QUIC (UDP) en lugar de TCP. Reduce el intercambio de contactos, resiste mejor la pérdida de paquetes en el móvil y los cambios de red (Wi‑Fi → 4G). Este es un desarrollo útil, no una varita mágica para WordPress sin caché.
Qué mejora HTTP/3 y qué ignora
| Capa | ¿HTTP/3 funciona? | Ejemplo |
|---|---|---|
| Apretón de manos TLS + transporte | Sí | Conexión más rápida en 4G inestable |
| Solicitudes de multiplexación | Sí (como h2) | Muchos pequeños activos |
| PHP/SQL | No | Página dinámica lenta |
| Imágenes de peso / JS | No | Alto PCC |
| DNS lento | No | Resolución incluso antes de QUIC |
En un sitio estático servido desde una CDN cercana, con muchas conexiones cortas, HTTP/3 puede eliminar entre 50 y 150 ms de latencia percibida. En una API con POST grande o un administrador de WordPress de origen lento, el efecto es invisible.
Al habilitarlo tiene sentido
Sí, habilítelo si:
- El origen TTFB ya es aceptable (< 400 ms de caché dinámica o efectiva).
- Tráfico móvil significativo, audiencia internacional.
- CDN gestiona QUIC sin una configuración compleja del servidor.
- Se mide con RON antes/después.
Informe si:
- OPcache desactivado, sin caché de página, consultas SQL lentas.
- Aún no has corregido Core Web Vitals en el lado LCP/CLS.
- El host anuncia HTTP/3 pero fuerza un proxy mal configurado (bucles, encabezados inconsistentes).
Implementación típica: CDN versus origen
La mayoría de los sitios activos en HTTP/3 pasan por un CDN:
- Visitante ↔ edge QUIC (HTTP/3)
- Borde ↔ origen a menudo sigue siendo HTTP/1.1 o HTTP/2
El host "admite HTTP/3" a través de su socio CDN, no necesariamente en el VPS simple. Verifique el contrato: terminación de TLS donde, certificados, reglas de caché.
Pruebas mínimas:
curl --http3-only -sI https://example.com | cabeza -5
Compare --http2 y --http1.1 en el mismo recurso estático.
La cumbre: optimizar el protocolo antes de la aplicación
Al marketing de CDN le encanta el término "preparado para HTTP/3". No reemplaza OPcache, índices SQL o compresión de imágenes.
Decide y avanza sin puntos ciegos
- Mida TTFB original y LCP actual.
- Reparar PHP, caché y activos si TTFB > 600 ms o LCP rojo.
- Habilitar HTTP/3 a través de CDN; comparar RON móvil 7 días.
- Documente protocolo de borde versus origen para soporte.
Compare hosts y CDN compatibles a través del directorio y la comparación.
Preguntas frecuentes
¿HTTP/3 es obligatorio en 2026?
No: priorice TTFB y el contenido antes que QUIC si el servidor es el cuello de botella.
Mi proveedor compartido ofrece HTTP/3: ¿debería activarlo?
Sí en alternar sin riesgo con medida; no, si esto evita un verdadero diagnóstico original.
¿HTTP/3 sin CDN?
Posible originalmente (Nginx/Caddy), pero poco común en la práctica: la mayoría usa CDN perimetral.
¿Cómo probar HTTP/3?
Protocolo DevTools h3 o curl: solo http3; comparar con h2.
Antes de celebrar HTTP/3, una pregunta: ¿el TTFB original ya está verde? De lo contrario, estás acelerando principalmente una cola de PHP, no la red.