Analizar la versión de HTTP de una web

Casi ninguna auditoría técnica empieza preguntando qué versión del protocolo HTTP sirve una web, y sin embargo es de las comprobaciones que mejor relación esfuerzo-beneficio tienen. Hay sitios funcionando hoy en HTTP/1.1 que podrían estar en HTTP/2 con un cambio de quince minutos y cero riesgo.

Vamos a ver qué versiones existen, cuánto se nota cada una, cómo comprobar de verdad cuál estás sirviendo y cómo activarlas en nginx, Apache, Plesk y cPanel.

Las tres versiones de los protocolos HTTP

• HTTP/1.1: Una petición por conexión TCP. El navegador abre varias conexiones paralelas por dominio y hace cola con el resto (generando cuellos de botella). Es decir, que cuando entra en la URL tiene que hacer una petición por recurso.
• HTTP/2: Multiplexación real sobre una única conexión TCP y cabeceras comprimidas. Es decir que puede pedir prácticamente todos los recursos a la vez. Lamentablemente. si se pierde un paquete de datos, toda la conexión se frena esperando su retransmisión.
• HTTP/3: Funciona sobre QUIC (UDP en lugar de TCP). Elimina el bloqueo de paquetes (un error solo frena su propio flujo), acelera la conexión y sobrevive a los saltos de red (pasar de Wi-Fi a datos) sin reconectar.

Normalmente me gusta poner en ponencias el ejemplo del camarero o de una carretera, para no saturar de ejemplos me quedo con el del camarero.

Para entender la alegoría entendamos que tu eres el cliente, cuando haces una petición al servidor (a cocina), lo haces por medio del protocolo (el camarero). Imaginemos que tienes claro lo que quieres y lo pides todo de golpe:

• HTTP 1: Es un camarero lento y sin herramientas. Cumple su función de traerte las cosas de cocina, pero tiene que hacer un viaje para cada cubierto, cada plato y cada bebida.
• HTTP 2: El camarero ha descubierto la maravillosa tecnología de la bandeja. Trae todo en un viaje, pero si tropieza y se le cae un plato, tiene que dejar la bandeja a un lado y limpiarlo todo hasta que te lo trae.
•  HTTP 3: Aquí el hostelero ha decidido invertir y no tienes un camarero, sino un equipo de camareros (con bandeja). Donde te traen la bebida y todo y aunque se cayese algo, la prioridad es servirte (los otros camareros no se paran a ayudar al que se le cae la sopa, te siguen sirviendo mientras tanto).

El reparto real de tráfico en la web está más o menos así:

El HTTP2 es el más común, sigue siendo decente pero es el mínimo que debe proveer cualquier hosting serio. El HTTP/3 ya ronda 1/5 parte de internet, pero curiosamente es casi el mismo porcentaje. (Fuente en la bibliografía)

Cuánto se nota

El salto grande es el de HTTP/1.1 a HTTP/2. El de HTTP/2 a HTTP/3 es más fino y se concentra donde hay pérdida de paquetes o cambios de red: conexiones móviles, wifis flojas, tráfico internacional. Si tu público está en fibra y escritorio, la diferencia entre h2 y h3 te va a costar verla; si tienes mucho móvil, es exactamente el escenario para el que se diseñó QUIC.

¿Es útil para SEO?

Los rastreadores de Google soportan HTTP/1.1 y HTTP/2, y eligen el que les dé mejor rendimiento de rastreo; no rastrean por HTTP/3.

Google además dice explícitamente que rastrear por h2 puede ahorrar recursos de CPU y RAM tanto a tu servidor como al suyo, pero que no hay ningún beneficio directo de posicionamiento por ello (esto no se debe confundir con que una página con HTTP/3 tenga problemas a la hora de ser rastreada por Google).

Así que el valor está en dos vías indirectas y muy reales: eficiencia de rastreo (menos conexiones abiertas, servidor menos saturado) y experiencia de usuario, que sí acaba tocando las Core Web Vitals. Es un cambio de bajo riesgo y coste casi nulo.

Es útil para la velocidad, y el cambio del protocolo HTTP/1.1 al HTTP/2 se nota una barbaridad. Además, si tienes la versión de HTTP/1 quiere decir que realmente tu hosting no te actualiza el servidor ni le importa darte un buen servicio.

Alt-Svc: h3=":443"; ma=86400

Cómo comprobar qué versión estás sirviendo

Un aviso previo: no te fíes de lo que te diga un crawler. Herramientas como Screaming Frog reportan la versión con la que ellas se han conectado, que no tiene por qué coincidir con la que negocia un navegador con tu servidor. Para esto, mide como mide el usuario.

Inspector de elementos

La vía más rápida. Pestaña Red del inspector de Chrome (o de Firefox, donde viene por defecto), click derecho sobre la cabecera de la tabla y activas la columna Protocolo. Ahí lo tienes recurso por recurso.

http/1.1 es obvio, h2 es HTTP/2 y h3 es HTTP/3. En el ejemplo uso Blablacar porque carga muchos recursos externos y se aprecian las tres opciones a la vez.

Qué soporta cada servidor

• nginx: HTTP/2 desde hace años. HTTP/3 disponible desde la versión 1.25.0 y consolidado en la rama estable 1.26 (23 de abril de 2024). Necesita el módulo ngx_http_v3_module compilado y una librería SSL con soporte QUIC.
• LiteSpeed y OpenLiteSpeed: HTTP/3 nativo desde casi el principio. Es el motivo por el que casi todos los hostings «con QUIC» son en realidad hostings con LiteSpeed.
• Caddy: HTTP/3 activado por defecto.
• Apache httpd: aquí está la mala noticia. No tiene soporte HTTP/3 en producción. La rama estable incluye mod_http2 pero no existe un mod_http3 oficial. Hay un módulo externo experimental y trabajo en curso en el proyecto para adaptar los MPM a conexiones QUIC, pero nada que yo pondría hoy en un cliente.

De ahí la arquitectura que ves en casi todos los paneles: nginx delante de Apache como proxy inverso. Apache sigue procesando el PHP y nginx es quien habla HTTP/3 con el navegador.

Si te preguntas como implementar cualquiera de estos protocolos mi recomendación es que si no tienes mucho conocimiento, realmente contactes con tu hosting y pongas a prueba el soporte, si es un hosting serio como Raiola te lo activarán sin coste extra.

Cualquier hosting debería hacerte el cambio como mínimo a HTTP/2 por decencia.

Pero aun así entiendo que puedes necesitar hacerlo tú por algún motivo, así que aunque no sea Carlos GPT te hago mi propio tutorial. Si bien es cierto que en el máster de SEO Técnico profundizo mucho más para que además lo entiendas mejor., aquí te dejo una pequeña guía.

Cómo activar HTTP3

El HTTP3 tiene sus complicaciones, entonces te enseño pasos sencillos para implementarlo. Sobre todo lo he hecho con Plesk, así que es donde más te puedo ayudar.

Estas recomendaciones son para un VPS o similares, si tienes un plan de hosting compartido, solo te puedo recomendar que envíes un ticket.

En Plesk

Plesk soporta HTTP/3 desde Obsidian 18.0.61, y desde la 18.0.71 se puede activar o desactivar por dominio. El soporte se apoya en nginx, así que solo funciona si el sitio lo sirve nginx, solo o en combinación con Apache. Si el componente de nginx no está instalado y sirve únicamente Apache, no hay HTTP/3 posible.

Primero, a nivel de servidor, por línea de comandos como root (en muchas ocasiones está activado por defecto y este paso no es necesario):

plesk bin http3_pref --enable

Después, por dominio: Sitios web y dominios > el dominio > Configuración de Apache y nginx, y ahí, en el bloque «configuración nginx», marcas la casilla de soporte de HTTP/3.

Comprueba que Modo proxy esté activo (es la pieza que pone nginx delante de Apache).

Si no ves la casilla en el dominio, casi siempre es que falta habilitarlo antes a nivel de servidor con el comando de arriba. Hay casos específicos donde no se puede, por ejemplo si tu servidor es Windows.

Recuerda que la función aparece como experimental. Como siempre recomiendo hacer todas las pruebas primero en un entorno de prueba como su nombre indica.

En cPanel

El servidor web por defecto es Apache, pero cPanel distribuye nginx de forma oficial mediante el paquete ea-nginx, y lo gestionas desde WHM > Software > NGINX Manager o desde EasyApache 4. En muchas ocasiones el hosting te viene con esta configuración ya por defecto.

También existe el modo ea-nginx-standalone, donde nginx es el único servidor web y Apache desaparece de la ecuación.

En Cpanel a diferencia de con Plesk no hay interruptor. cPanel no distribuye un paquete equivalente de HTTP/3 ni una casilla en NGINX Manager, así que no es un cambio de dos clics como en Plesk. Si ya tienes ea-nginx corriendo, el camino es este:

1. Comprobar si el binario que te instala cPanel trae el módulo compilado, con nginx -V y buscando --with-http_v3_module. Si no está, no hay nada que configurar.
2. Añadir la configuración de QUIC mediante archivos include, que es el mecanismo soportado. El .conf que cPanel genera para cada usuario en /etc/nginx/conf.d/users/ se regenera solo y no debe editarse a mano; los includes propios van en el directorio del usuario (o en el del dominio concreto) y sobreviven a las regeneraciones.
3. Abrir el UDP 443 en el firewall y vigilar el reuseport: si lo metes en un include que se aplica a varios usuarios, lo estarás declarando más de una vez sobre el mismo puerto y romperás nginx.

Es viable, pero es artesanía, y cada actualización de ea-nginx merece una comprobación. Desde mi punto de vista o te da soporte el hosting o no te compensa mantenerlo. Tampoco es tan crítico tener HTTP3 si tienes HTTP2 pero si aun así por cabezonería quieres lo mejor puedes hacer lo siguiente:

• Cambiar Apache por LiteSpeed Enterprise, que se integra con cPanel y trae QUIC de serie. Es la opción limpia si el rendimiento es prioridad y hay presupuesto de licencia.
• CDN, no todos los CDNs soportan http3, y debes servir el contenido (no solo el multimedia) por medio del CDN. El navegador habla h3 con la CDN y la CDN habla h2 o h1.1 con tu origen. Para el usuario el beneficio es prácticamente el mismo, y es la vía con menos mantenimiento de las tres. Aunque si tu web ya usa un CDN como Weglot (para los idiomas) no lo tienes sencillo.

Y si estás en hosting compartido, esto no lo decides tú: abre un ticket y pregunta. La respuesta que quieres oír es «h2 activo por defecto»; lo demás, para nota.

En LiteSpeed y OpenLiteSpeed

Es el caso más cómodo de los tres: aquí no hay que compilar módulos ni montar nginx delante de nada. QUIC y HTTP/3 vienen de serie en el propio servidor web, tanto en la versión de pago (LiteSpeed Enterprise) como en la gratuita (OpenLiteSpeed), y en las versiones recientes está activo por defecto en el listener SSL.

Si tu hosting usa LiteSpeed y no estás sirviendo h3, casi siempre es por una de estas tres cosas: el listener no tiene QUIC habilitado, el puerto UDP 443 está cerrado, o hay una CDN por delante que está terminando la conexión antes de llegar a tu servidor.

Activarlo desde la consola de administración

1. Entra en la WebAdmin Console (normalmente en el puerto 7080 de tu servidor).
2. Ve a Configuration > Listeners y selecciona el listener que sirve el 443.
3. En la pestaña SSL, busca el bloque de QUIC y ponlo en Yes. Si el valor está en Not Set, se hereda la configuración global del servidor, que en instalaciones modernas ya viene habilitada.
4. Haz un graceful restart desde la propia consola. No hace falta parar el servicio.

Abrir el UDP 443

El HTTP/3 no viaja por TCP, así que tener el 443 abierto en TCP no sirve de nada: hay que abrirlo también en UDP. Con firewall sería algo así:

firewall-cmd --permanent --add-port=443/udp && firewall-cmd --reload

Si usas CSF, la línea equivalente va en UDP_IN dentro de /etc/csf/csf.conf. Y si estás en un VPS de un proveedor cloud, revisa también el grupo de seguridad del panel: muchos filtran UDP antes de que el paquete llegue a tu firewall.

Si estás en cPanel con LiteSpeed Enterprise

LiteSpeed Enterprise sustituye a Apache manteniendo la compatibilidad con sus configuraciones, así que cPanel sigue funcionando igual. La gestión la haces desde WHM > Plugins > LiteSpeed Web Server, que te lleva a la misma consola de administración de antes. Es la vía limpia para tener HTTP/3 en cPanel sin la artesanía de los includes de nginx que he contado más arriba.

Comprobar que está funcionando

Lo primero que debe aparecer es la cabecera que anuncia el servicio alternativo:

Alt-Svc: h3=":443"; ma=2592000

Ojo con esto: esa cabecera solo dice que el servidor ofrece HTTP/3, no que se esté usando. La primera visita siempre se negocia por HTTP/2; el navegador guarda el anuncio y salta a h3 en la siguiente. Por eso, si recargas y sigues viendo h2 en el inspector, prueba a recargar otra vez antes de dar por hecho que no funciona.

Para verificarlo sin depender del navegador:

curl -I --http3 https://tudominio.com

Y recuerda lo que decía antes sobre las CDN: si tienes Cloudflare u otra CDN en modo proxy, el h3 que ves puede ser suyo y no tuyo. Para saber qué sirve realmente tu origen, mide contra la IP del servidor saltándote la CDN.

Un apunte que confunde a mucha gente: el plugin LiteSpeed Cache de WordPress no tiene nada que ver con esto. El HTTP/3 lo activa el servidor, no el plugin, y funciona igual aunque no lo tengas instalado. El plugin es más para configurar el caché.

¿Cuándo merece la pena mejorar el protocolo HTTP?

Mínimo debes tener HTTP/2, si al revisar tu web, las fuentes propias o el HTML inicial tiene HTTP/1.1 es un problema de usabilidad que se soluciona muy rápido y se nota mucho.

Respecto al HTTP/3 merece la pena si tienes un tráfico que viene mucho por medio de móvil (por ejemplo una web de festivales o de casas rurales), debido a que la conexión puede ser muy variable y esto mejora la experiencia. Pero aunque hay mejora respecto al HTTP/2 la implementación como has podido leer tiene más follón, entonces hay que evaluar coste/oportunidad.

Es uno de los aspectos de una web que veo muy infravalorado y que merece muchísimo la pena mejorar. Además de que es un indicador claro de si el hosting donde está la web no merece la pena.

Bibliografía

• La velocidad de HTTP3
• Soporte de QUIC y HTTP/3 en nginx (documentación oficial)
• Soporte de HTTP/3 en Plesk
• Protocolos soportados por los rastreadores de Google
• Petición de soporte HTTP/3 en Apache httpd
• Habilitar HTTP2
• Porcentajes de uso de los protocolos
• Changelog de implementación de http3 en nginx