¿Qué es HTTP/2?

HTTP/2 es la segunda versión mayor del protocolo de transferencia de hipertexto, finalizada como RFC 7540 en mayo de 2015. Fue la primera actualización significativa de HTTP desde que HTTP/1.1 se estandarizó en 1997, y abordó problemas de rendimiento fundamentales que habían afectado a la web durante casi dos décadas. Si tu sitio WordPress sigue sirviendo el contenido sobre HTTP/1.1, es probable que estés desaprovechando ganancias de rendimiento importantes.

El protocolo surgió a partir del protocolo experimental SPDY de Google, que se utilizaba desde 2012 y demostró que las ideas centrales de HTTP/2 (multiplexación, compresión de cabeceras, priorización) funcionaban bien en producción. Cuando el IETF estandarizó HTTP/2, SPDY se retiró y sus ideas se convirtieron en la base del nuevo estándar.

Mejoras clave respecto a HTTP/1.1

Para entender por qué HTTP/2 importa, primero hay que entender qué problemas tenía HTTP/1.1. Con el protocolo antiguo, cada conexión TCP solo podía atender una petición a la vez. Si tu navegador necesitaba cargar 40 recursos (una página WordPress típica), tenía que abrir varias conexiones (los navegadores suelen permitir 6 por dominio) y poner el resto en cola. Esto creaba cuellos de botella artificiales que ralentizaban cada carga de página.

HTTP/2 resuelve esto y mucho más:

Multiplexación: esta es la mejora más importante. HTTP/2 permite que varias peticiones y respuestas estén en curso simultáneamente sobre una única conexión TCP. Tu navegador puede solicitar tu archivo CSS, tres archivos JavaScript y diez imágenes a la vez, sobre una sola conexión. Sin esperas, sin colas, sin límites artificiales. El servidor envía las respuestas a medida que están disponibles y el navegador las ensambla. Solo este cambio puede reducir drásticamente los tiempos de carga de páginas en sitios WordPress con muchos recursos.

Compresión de cabeceras (HPACK): las cabeceras HTTP se envían en cada petición y respuesta. En HTTP/1.1, estas cabeceras son texto plano y a menudo repetitivas. Las mismas cookies, cadenas user-agent y cabeceras accept se envían una y otra vez. HTTP/2 utiliza un algoritmo de compresión llamado HPACK que mantiene una tabla compartida de campos de cabecera comunes entre cliente y servidor. Tras la primera petición, las cabeceras siguientes solo necesitan enviar las diferencias. En un sitio WordPress que carga más de 50 recursos por página, esto puede ahorrar decenas de kilobytes en cada carga.

Encuadre binario: HTTP/1.1 es un protocolo basado en texto, lo que significa que el parser tiene que buscar saltos de línea, gestionar diferentes codificaciones de texto y lidiar con varios casos límite. HTTP/2 utiliza una capa de encuadre binario que envuelve toda la comunicación en tramas bien definidas. Los datos binarios son más rápidos de parsear, menos propensos a errores y más compactos. Como usuario nunca lo notarás, pero reduce la sobrecarga de procesamiento tanto en el servidor como en el cliente.

Priorización de flujos: HTTP/2 permite al navegador indicar al servidor qué recursos son más importantes. Por ejemplo, el navegador puede señalar que el archivo CSS principal debe entregarse antes que las imágenes de fondo. El servidor puede entonces asignar el ancho de banda en consecuencia. En la práctica, las implementaciones de la priorización en los navegadores varían, y no todos los servidores la gestionan a la perfección, pero aun así aporta mejoras significativas en muchos sitios.

Server Push: esta función permite al servidor enviar recursos al navegador antes incluso de que este los solicite. Cuando el navegador pide una página HTML, el servidor puede enviar (push) los archivos CSS y JavaScript que sabe que el navegador necesitará a continuación. Esto elimina el retraso de ida y vuelta que supone que el navegador descubra que necesita un recurso y luego lo solicite. Sin embargo, Server Push ha tenido una adopción limitada en la práctica. Es complicado implementarlo correctamente (enviar recursos que el navegador ya tiene en caché desperdicia ancho de banda) y algunas CDNs han retirado el soporte. Chrome eliminó el soporte de Server Push en la versión 106 (2022). El concepto sobrevive en el mecanismo 103 Early Hints, que es más simple y práctico.

Por qué el domain sharding ya no es necesario

En la era de HTTP/1.1, los desarrolladores web utilizaban un truco llamado domain sharding para sortear el límite de 6 conexiones por dominio. Servían las imágenes desde img1.example.com, el CSS desde cdn.example.com y las fuentes desde otro subdominio. Esto multiplicaba el número de conexiones paralelas que el navegador podía abrir.

Con HTTP/2, el domain sharding no solo es innecesario, sino contraproducente. Como HTTP/2 multiplexa todas las peticiones sobre una única conexión, dividir los recursos entre varios dominios obliga al navegador a establecer conexiones TCP y handshakes TLS adicionales. Cada nueva conexión añade latencia. Un sitio WordPress optimizado con domain sharding para HTTP/1.1 debería consolidar sus recursos en menos dominios al pasar a HTTP/2.

De forma similar, concatenar archivos CSS y JavaScript en bundles únicos (otra optimización común de HTTP/1.1) deja de ser tan importante con HTTP/2. Enviar muchos archivos pequeños funciona de forma eficiente gracias a la multiplexación, y tiene la ventaja añadida de un mejor cacheo: cuando cambia un archivo pequeño, solo hay que volver a descargar ese archivo y no el bundle concatenado entero.

HTTP/2 requiere HTTPS en la práctica

La especificación de HTTP/2 no requiere técnicamente cifrado. Puedes tener HTTP/2 sobre TCP sin cifrar (llamado h2c, por HTTP/2 cleartext). Sin embargo, todos los navegadores principales (Chrome, Firefox, Safari, Edge) han decidido implementar HTTP/2 únicamente sobre TLS (llamado h2). Esto significa que, a efectos prácticos, necesitas un certificado SSL/TLS para usar HTTP/2.

Hoy en día esto ya no es realmente una limitación. Los certificados gratuitos de Let's Encrypt han hecho que HTTPS sea accesible para todo el mundo y la mayoría de proveedores de hosting WordPress incluyen certificados SSL en sus planes. Si tu sitio WordPress sigue en HTTP, pasar a HTTPS es un requisito previo para HTTP/2 y aporta sus propios beneficios de seguridad.

HTTP/3 y QUIC: el siguiente paso

HTTP/3 (RFC 9114, finalizado en junio de 2022) es la siguiente evolución. Mientras que HTTP/2 funciona sobre TCP, HTTP/3 sustituye TCP por completo con un nuevo protocolo de transporte llamado QUIC. QUIC se basa en UDP e incorpora directamente cifrado TLS 1.3 en la capa de transporte. Las ventajas clave de HTTP/3 sobre HTTP/2 son:

• Establecimiento de conexión más rápido: QUIC combina el handshake TCP y el handshake TLS en un único viaje de ida y vuelta, reduciendo el tiempo de configuración de la conexión. Para los visitantes que regresan, incluso puede lograr una reanudación de conexión sin viajes de ida y vuelta.
• Sin head-of-line blocking: en HTTP/2 sobre TCP, si se pierde un único paquete, todos los flujos de esa conexión se bloquean hasta que se retransmite el paquete. QUIC gestiona la pérdida de paquetes por flujo, así que un paquete perdido solo retrasa el flujo afectado y no todo lo demás.
• Mejor rendimiento en móvil: QUIC gestiona los cambios de red (como pasar de WiFi a datos móviles) de forma más elegante porque las conexiones se identifican mediante un ID de conexión y no por dirección IP y puerto.

Los principales proveedores de CDN como Cloudflare y Fastly ya soportan HTTP/3. La mayoría de proveedores de hosting están todavía en proceso de adoptarlo. Para los propietarios de sitios WordPress, el soporte de HTTP/3 es principalmente una cuestión del lado del servidor; no necesitas cambiar nada en el propio WordPress.

Cómo comprobar si tu hosting soporta HTTP/2

Hay varias formas de verificar si tu sitio WordPress se sirve sobre HTTP/2:

• DevTools del navegador: abre la pestaña Network en las DevTools de Chrome, haz clic derecho en las cabeceras de columna y activa la columna "Protocol". Deberías ver h2 en las peticiones HTTP/2.
• Herramientas online: sitios como el test HTTP/2 de KeyCDN o el comprobador HTTP/2 en tools.keycdn.com pueden verificar el soporte HTTP/2 para cualquier URL.
• Línea de comandos: ejecuta curl -I --http2 -s https://yoursite.com y busca HTTP/2 200 en la respuesta.
• InspectWP: el informe incluye la versión HTTP detectada en tu sitio WordPress.

Si tu hosting no soporta HTTP/2, colocar una CDN como Cloudflare delante de tu sitio puede proporcionar soporte HTTP/2 (y HTTP/3) aunque tu servidor de origen solo hable HTTP/1.1. La CDN gestiona la conexión HTTP/2 con el navegador del visitante y se comunica con tu servidor de origen mediante el protocolo que este admita.

Implicaciones para el rendimiento de WordPress

Una página WordPress típica carga entre 20 y 80 recursos individuales: hojas de estilo de la plantilla y los plugins, archivos JavaScript, fuentes web, imágenes y a veces recursos externos de CDNs y servicios de terceros. Bajo HTTP/1.1, cargar todos estos recursos era el factor que más contribuía al tiempo de carga de la página debido a las limitaciones de conexión y de cola.

Tras pasar a HTTP/2, la mayoría de sitios WordPress experimentan mejoras notables en el Time to First Contentful Paint y en el tiempo de carga global. La mejora exacta depende de cuántos recursos cargue tu sitio, pero es habitual ver reducciones del 20-50 % en el tiempo de carga en sitios que antes estaban en HTTP/1.1. Los sitios con muchos recursos pequeños (algo típico en WordPress con varios plugins activos) son los que más se benefician.

Ten en cuenta que HTTP/2 no sustituye otras optimizaciones de rendimiento. Sigues necesitando una caché adecuada, optimización de imágenes y código eficiente. Pero HTTP/2 elimina un cuello de botella significativo a nivel de infraestructura que ninguna optimización por plugin de WordPress puede solucionar.

Qué comprueba InspectWP

InspectWP detecta la versión del protocolo HTTP utilizada por tu sitio WordPress examinando las cabeceras de respuesta. Si tu sitio se sirve sobre HTTP/1.1, el informe lo marca como un problema de rendimiento y recomienda actualizar a HTTP/2. Si se detecta HTTP/2 o HTTP/3, se reporta como un hallazgo positivo. La versión HTTP se muestra en la sección de rendimiento del informe, junto con otras métricas a nivel de servidor como la compresión y las cabeceras de respuesta.