Qué cambia en la práctica para un sitio real

Después de tres lecciones de protocolo, la pregunta operativa es qué haces tú el lunes. La respuesta corta: comprobar qué versión están recibiendo tus usuarios de verdad, que casi nunca es la que crees, y revisar las decisiones de arquitectura que tomaste bajo restricciones que ya no existen. La ganancia de cambiar de protocolo es modesta; la de desmontar las optimizaciones caducadas es grande.

Comprobar qué protocolo se usa de verdad

Hay tres niveles de comprobación, de menos a más informativo.

En la línea de comandos, para saber qué ofrece el servidor:

# Version negociada por ALPN sobre TLS.
curl -sI --http2 https://ejemplo.com | head -1

# Forzar HTTP/3. Requiere un curl compilado con soporte.
curl -sI --http3 https://ejemplo.com | head -1

# Ver el anuncio de servicio alternativo.
curl -sI https://ejemplo.com | grep -i '^alt-svc'

# Comprobar si hay registro DNS de tipo HTTPS.
dig +short ejemplo.com type65

En el navegador, para una carga concreta. La columna de protocolo del panel de red la muestra por recurso, y desde JavaScript se obtiene igual:

const porProtocolo = performance.getEntriesByType('resource')
  .reduce((acc, r) => {
    const p = r.nextHopProtocol || 'desconocido';
    acc[p] = (acc[p] || 0) + 1;
    return acc;
  }, {});

console.table(porProtocolo);

En campo, que es lo único que refleja la realidad. Envía nextHopProtocol del documento principal junto con tus métricas y agrégalo por país y por tipo de red. Aquí es donde aparecen las sorpresas.

La lista de revisión tras migrar

Migrar el protocolo es cambiar una configuración. Lo que produce la ganancia es esta lista, y conviene recorrerla entera.

Eliminar el sharding de dominios. Si tus estáticos están repartidos en varios subdominios, consolídalos en uno. Con multiplexación, repartir fragmenta la conexión, multiplica los establecimientos, multiplica los arranques lentos y rompe la priorización. Efecto: alto.

Revisar la concatenación. Un único archivo de JavaScript de trescientos kilobytes se invalida entero cada vez que cambia una línea. Con multiplexación, veinte módulos separados se sirven casi al mismo coste y se cachean por separado, así que un cambio pequeño solo invalida un archivo. Cuidado con pasarse: cientos de módulos minúsculos añaden sobrecarga de cabeceras y cadenas de dependencias. El equilibrio razonable está en decenas de archivos, agrupados por frecuencia de cambio.

Eliminar los sprites de imágenes. Con peticiones baratas ya no compensan, y tienen el mismo problema de invalidación: cambiar un icono invalida la hoja entera.

Revisar las URL de datos incrustadas. Una imagen incrustada como URL de datos dentro del CSS engorda la hoja, no se cachea por separado, y añade un coste de decodificación en base 64. Casi siempre es mejor como archivo aparte.

Comprobar el tiempo de espera de conexión inactiva. Con una sola conexión multiplexada, mantenerla viva vale más que antes. Un tiempo de espera de cinco segundos obliga a reconectar constantemente a usuarios que leen.

Publicar el registro DNS de servicio. Si sirves HTTP/3, este registro permite usarlo desde la primera conexión en lugar de desde la segunda. Es un cambio de DNS y elimina la penalización de la primera visita.

Sustituir el envío desde el servidor por la cabecera de enlace. Si tenías configurado el envío anticipado de HTTP/2, ya no funciona en Chrome. La cabecera Link con rel=preload en la respuesta consigue casi lo mismo respetando la caché del cliente.

La ganancia realista

Con números, para calibrar expectativas antes de vender el trabajo.

Fíjate en la última fila, porque contiene la lección del nivel: consolidar orígenes rinde más que cualquier cambio de versión de protocolo. El protocolo mejora cómo se usa una conexión; consolidar elimina conexiones enteras.

El orden de trabajo

Con todo lo anterior, el orden que maximiza el retorno es este.

1. Mide qué protocolo reciben tus usuarios de verdad, segmentado. Si hay degradaciones, averigua a quién le pasan antes de tocar nada.
2. Cuenta tus orígenes en la ruta crítica y consolida los que puedas. Es la palanca más grande y es independiente del protocolo.
3. Verifica que tienes TLS 1.3. Es configuración y quita un viaje por conexión nueva.
4. Activa HTTP/2 si no lo tienes, y a continuación desmonta las optimizaciones de HTTP/1.1. Los dos pasos van juntos: el segundo es el que produce la ganancia.
5. Activa HTTP/3 y publica el registro DNS. Evalúa el resultado en la cola de la distribución, no en el percentil 75.
6. Considera el 0-RTT solo si tu tráfico es mayoritariamente de lectura y has revisado el riesgo de repetición.

Los pasos 2 y 4 son los que mueven la aguja. Los demás son mejoras honestas de menor magnitud.