h2 vs HTTP/1.1
h2 vs HTTP/1.1 · test HTTP/2 · comprobador HTTP/2
Qué significan h2 y HTTP/1.1 para rendimiento, compatibilidad y depuración de sitios modernos.
Por DN01 Network Team
h2 vs HTTP/1.1 es una comprobación sencilla de formular, pero muy fácil de interpretar mal. El objetivo no es ver una etiqueta bonita en un panel, sino confirmar separar la etiqueta de protocolo de efectos reales como multiplexación, compresión de cabeceras, reutilización de conexión y cuellos de botella. Use /es/http2-tester como punto de partida: introduzca el host público, ejecute la prueba y conserve el resultado junto con la hora, la región y cualquier cambio reciente de infraestructura.
HTTP/2 normalmente aparece unido a TLS, ALPN, CDN, balanceadores y cabeceras. Por eso conviene leer el resultado como una señal de ruta completa. Si el test muestra h2, todavía debe revisar certificados en /es/ssl-certificate-checker y cabeceras en /es/http-header-checker; si cae a HTTP/1.1, no culpe automáticamente a la aplicación. El fallo puede estar en un proxy, una política del CDN o una negociación TLS incompleta.
Esta guía se centra en h2 vs HTTP/1.1 para equipos que necesitan una respuesta indexable, compartible y útil en tickets. También enlaza con /es/articles/problemas-http2-cdn-proxy, /es/articles/desajuste-http2-navegador-servidor para que pueda seguir investigando sin saltar entre herramientas inconexas. Compare resultados antes y después de reglas CDN, upgrades del servidor o cambios de política TLS.
Qué debe demostrar la prueba
Una prueba de HTTP/2 debe responder una pregunta concreta: ¿qué versión del protocolo recibe un cliente real al conectar con este host? Para h2 vs HTTP/1.1, anote si el resultado muestra h2, HTTP/1.1 o un error de negociación. Añada el nombre exacto probado, porque example.com, www.example.com y un subdominio de assets pueden pasar por rutas diferentes.
No mezcle esa respuesta con promesas de rendimiento. HTTP/2 habilita multiplexación, compresión de cabeceras y una relación distinta entre conexiones y recursos, pero no corrige por sí solo un TTFB alto, imágenes pesadas ni caché ausente. El valor operativo está en detectar una regresión de protocolo justo después de un deploy, cambio de certificado o ajuste de CDN.
El error más común es perseguir problemas de frontend cuando el borde abre demasiadas conexiones HTTP/1.1 o culpar a HTTP/2 por un origen lento. Para evitarlo, pruebe siempre el endpoint público desde DN01 y compare con la configuración interna. Si ambos lados discrepan, ya tiene una pista: algún componente intermedio está reescribiendo, terminando TLS o sirviendo otra política.
Flujo recomendado en DN01
Empiece en /es/http2-tester. Pegue el host sin ruta larga, porque la negociación del protocolo ocurre antes de que una URL profunda importe. Si trabaja con varios nombres, pruebe dominio raíz, www y el host de assets por separado. Copie el resultado en el ticket antes de tocar la configuración; esa línea base evita debates cuando el cambio parece funcionar para una persona y fallar para otra.
Después abra /es/ssl-certificate-checker. HTTP/2 en navegadores modernos depende de TLS correcto y ALPN; certificados caducados, cadenas incompletas o SNI mal configurado pueden hacer que el síntoma parezca de HTTP/2 cuando en realidad es de seguridad. Finalmente use /es/http-header-checker para revisar HSTS, caché, compresión, cookies y cabeceras que influyen en cómo se percibe el sitio.
Cuando el resultado cambie, repita el mismo orden. Prueba HTTP/2, certificado, cabeceras. Este patrón crea evidencia comparable y permite detectar si un proveedor arregló el borde CDN pero dejó roto el origen, o si el certificado se renovó correctamente pero el proxy dejó de anunciar h2.
Cómo interpretar discrepancias
Si DN01 muestra HTTP/2 y su script local muestra HTTP/1.1, revise la versión de curl, soporte ALPN, SNI y si está forzando una IP concreta. Muchas falsas alarmas nacen de clientes antiguos o pruebas contra una dirección que no representa la ruta pública. El comprobador online ayuda porque simula una observación externa y compartible.
Si ocurre lo contrario, busque diferencias regionales, reglas del CDN o despliegues graduales. Algunos proveedores activan HTTP/2 por zona, plan, certificado o política de borde. También puede haber rutas separadas para IPv4 e IPv6. Documente cada host y familia de dirección antes de abrir una incidencia con soporte.
No ignore las cabeceras. Cookies muy grandes, redirect chains, HSTS inconsistente o caché contradictoria pueden esconder la mejora esperada de HTTP/2. La versión del protocolo es una pieza; la experiencia final combina negociación, TLS, headers y comportamiento de la aplicación.
Cuándo volver a comprobar
Repita h2 vs HTTP/1.1 después de renovar certificados, cambiar de CDN, mover tráfico entre balanceadores, actualizar Nginx, Apache, Envoy o Caddy, y antes de lanzamientos donde rendimiento o SEO importan. También conviene añadirlo a la checklist de incidentes cuando usuarios reportan lentitud solo en ciertas regiones o navegadores.
Para monitorización, una muestra aislada no basta. Compare el protocolo con estado TLS y cabeceras para evitar alertas ruidosas. Si su equipo usa API o jobs programados, guarde el host, resultado esperado, hora y versión de infraestructura. Un diff pequeño después de un deploy suele revelar más que capturas manuales sin contexto.
Mantenga esta guía y /es/http2-tester en el runbook. Los equipos que prueban HTTP/2 de forma repetible encuentran más rápido la diferencia entre una regresión real, una configuración parcial y una expectativa incorrecta sobre lo que HTTP/2 puede solucionar.
| Señal | Qué indica | Herramienta relacionada |
|---|---|---|
| h2 negociado | El cliente público puede usar HTTP/2 en ese host | /es/http2-tester |
| ALPN o TLS falla | La negociación segura bloquea HTTP/2 | /es/ssl-certificate-checker |
| Cabeceras pesadas | HTTP/2 ayuda, pero no elimina mala higiene HTTP | /es/http-header-checker |
| Resultado por host | CDN, www y assets pueden tener rutas distintas | /es/articles/problemas-http2-cdn-proxy |
Preguntas frecuentes
- ¿HTTP/2 garantiza que mi sitio será más rápido?
No. HTTP/2 mejora la forma de transportar múltiples recursos, pero rendimiento real también depende de TTFB, caché, tamaño de assets, TLS y código de aplicación.
- ¿Por qué mi servidor dice HTTP/2 activado y DN01 muestra HTTP/1.1?
Normalmente hay un CDN, balanceador o proxy terminando TLS con otra política. Pruebe el host público y revise ALPN, certificado y configuración del borde.
- ¿Debo comprobar cabeceras además del protocolo?
Sí. Use /es/http-header-checker para revisar HSTS, caché, cookies y cabeceras de seguridad; muchas incidencias atribuidas a HTTP/2 viven en esa capa.
- ¿Qué hago si solo falla en algunos usuarios?
Compare región, IPv4/IPv6, CDN y navegador. Guarde resultados repetibles antes de escalar al proveedor.