El equipo concatena otros treinta archivos JavaScript "porque HTTP/1", a pesar de que nginx ya ha estado sirviendo HTTP/2 durante dos años. El paquete monolítico rompe el caché en cada parche. Al mismo tiempo, otro proyecto distribuye sus activos en static1, static2, static3: tres apretones de manos TLS, la multiplexación está cancelada por hábitos heredados de HTTP/1.
HTTP/2 multiplexa múltiples solicitudes a través de una única conexión TCP/TLS. No más cola de seis ranuras paralelas de HTTP/1.1, pero no más bloqueo de procesamiento de JavaScript ni imágenes de cuatro megabytes. Entender la multiplexación significa saber qué regula y qué deja intacto.
Multiplexación: lo que realmente cambia
Bajo HTTP/1.1, los navegadores limitaban las conexiones paralelas al mismo dominio, de ahí la fragmentación de dominios, los sprites CSS y la concatenación de archivos. HTTP/2 abre transmisiones independientes en una única conexión, con compresión de encabezado HPACK.
| HTTP/1 práctico | Bajo HTTP/2 |
|---|---|
| Fragmentación de dominio | Contraproducente |
| Sprites CSS | Menos necesario |
| Paquete individual grande | Módulos + caché por hash |
| Seis conexiones que mantienen viva la vida | Una rica conexión |
La multiplexación acelera el transporte, no el tamaño del archivo ni el orden de ejecución de JavaScript.
Un sitio que carga doce scripts sincrónicos en <head> permanece lento, HTTP/2 o no. La restricción de la red ha cambiado; la restricción de la ruta de renderizado crítica permanece.
Priorización, bloqueo al frente de la fila y límites
HTTP/2 sufrió un bloqueo de cabecera de cola a nivel de TCP: la pérdida de un paquete bloqueó todas las transmisiones. HTTP/3 (QUIC) mejora este punto sobre UDP. En la práctica, reducir la cantidad de scripts sincrónicos en <head> sigue siendo más impactante que ajustar las prioridades de transmisión en el lado de nginx.
Las prioridades de transmisión entre el navegador y el servidor tienen un efecto real modesto en comparación con la optimización de la imagen LCP o el aplazamiento de JavaScript no esencial. Mida LCP, TBT e INP, no solo el protocolo en los encabezados de respuesta.
Terminación y origen de CDN, TLS
La terminación HTTP/2 en la CDN (Cloudflare, etc.) a un origen HTTP/1.1 sigue siendo muy común: el cliente se beneficia de la multiplexación, el origen mantiene una pila más simple. Verificar la negociación ALPN con:
curl -I --http2 https://tu-sitio.ejemplo
En hosting compartido sin HTTP/2 nativo, una CDN gratuita delante del origen suele ser suficiente. Compare ofertas a través de nuestro directorio: la compatibilidad con ALPN h2 depende del servidor web y el certificado, no solo de un cuadro en el panel.
La inserción del servidor HTTP/2 está en gran medida obsoleta: Chrome la ha eliminado y la precarga a través de <link rel="preload"> ofrece un control más preciso sin desperdiciar ancho de banda en recursos ya almacenados en caché.
HTTP/3 y migración gradual
HTTP/3 se basa en QUIC (UDP) y mejora el rendimiento en redes móviles con pérdida de paquetes. La activación se produce gradualmente en el lado de la CDN: Cloudflare, Fastly y otros la activan sin rediseñar la aplicación. No es necesario cambiar su código PHP o Node.js; es la capa de red la que evoluciona.
Primero elimine las prácticas HTTP/1 que se han vuelto dañinas: fragmentación de dominios, paquetes monolíticos, sprites innecesarios. A continuación, habilite HTTP/3 si su CDN lo ofrece; es una ventaja, no un requisito previo.
Lista de verificación después de la activación HTTP/2
- Eliminar la fragmentación del dominio en activos estáticos.
- Dividir los paquetes de forma lógica (por ruta o por funcionalidad).
- Precargue la imagen LCP, difiera o asincronice el JavaScript no crítico.
- Mantenga la compresión Brotli o gzip: HTTP/2 no comprime los cuerpos de las respuestas.
- Alinear los encabezados de caché para que la ganancia de la red no se cancele por revalidaciones excesivas.
La cumbre: insignia HTTP/2, el sitio sigue lento
Esto es lo que no garantiza el protocolo mostrado en DevTools.
Comprender la multiplexación significa dejar de optimizar para HTTP/1 mientras continúa optimizando el contenido y la ruta crítica.
Decide y avanza sin puntos ciegos
Durante medio día, compruebe que HTTP/2 aporta beneficios reales:
- Confirme que HTTP/2 esté activo en el lado del cliente (
curl --http2o pestaña Protocolo en DevTools). - Eliminar la fragmentación de dominios en los activos: mida el LCP antes y después.
- Reemplace el paquete monolítico con módulos razonables con hash en el nombre.
- Active HTTP/3 a través de la CDN si está disponible, sin esperar a que se rediseñe la aplicación.
- Compare hosts con TLS y HTTP/2 a través del directorio y el comparador.
Si el sitio sigue lento después de HTTP/2, el cuello de botella está en otra parte: imágenes, JavaScript, base de datos. El blog técnico ofrece guías adicionales sobre el almacenamiento en caché y los formatos de imagen.
Preguntas frecuentes
¿HTTP/2 hace que la fragmentación de dominios sea inútil?
Sí, en principio. Una conexión multiplexada sirve varios archivos sin abrir nuevas conexiones TCP/TLS. La fragmentación recrea costosos apretones de manos y, a menudo, anula el beneficio de la multiplexación. Mantenga un origen HTTP/2 o CDN limpio.
¿Todavía necesitamos concatenar CSS/JS?
Menos que HTTP/1.1, pero un paquete enorme mantiene una granularidad de caché deficiente: cada modificación invalida todo el archivo. Apunte a módulos razonables, no cuarenta microarchivos sin caché.
¿Es útil la inserción del servidor HTTP/2?
En gran medida no. Chrome ha eliminado la compatibilidad y la precarga mediante la etiqueta <link> ofrece un control más preciso. No configure nginx push sin medir el impacto en el ancho de banda.
HTTP/2 en todas partes ¿qué requiere del lado del host?
TLS con ALPN h2, certificado válido, servidor web reciente (nginx, Apache, Caddy) o CDN con terminación HTTP/2. En compartido, consulta el soporte en el panel; de lo contrario, coloque una CDN delante de un origen HTTP/1.1.
HTTP/2 establece la cola de la red, no la cola de JavaScript.