El presupuesto de viajes de ida y vuelta
Cómo contar los viajes de una carga real, cuántos caben dentro del objetivo de 2,5 segundos, y el método para recortarlos uno a uno.
Si la latencia domina, entonces el recurso escaso de una carga de página no son los bytes sino los viajes de ida y vuelta, y como cualquier recurso escaso se puede presupuestar. Contar viajes es un ejercicio de cinco minutos que produce una cifra más accionable que cualquier puntuación, porque cada viaje eliminado tiene un valor conocido en milisegundos.
- Contar los viajes de ida y vuelta de la ruta crítica de una página real.
- Calcular cuántos caben dentro del objetivo de LCP para una latencia dada.
- Priorizar los recortes por número de viajes eliminados.
- Reconocer los cuatro patrones que multiplican viajes sin que se note.
Contar los viajes
La cuenta se hace sobre la ruta crítica, es decir, la cadena de recursos que tiene que completarse antes de que el elemento LCP pueda renderizarse. Los recursos que se descargan en paralelo sin bloquear nada no cuentan.
Las reglas de conteo:
| Suceso | Viajes |
|---|---|
| Resolución de DNS de un origen nuevo | 0,3 a 1 |
| Saludo TCP | 1 |
| Negociación TLS 1.3 | 1 |
| Negociación TLS 1.2 | 2 |
| Petición y primer byte sobre conexión abierta | 1 |
| Cada 14 KB adicionales del primer recurso de una conexión | ~1 |
| Redirección al mismo origen | 1 |
| Redirección a otro origen | 3 a 4, cadena completa |
Aplicado a una página real, con el HTML propio, el CSS propio, una fuente de un dominio ajeno referenciada desde el CSS, y la imagen del hero:
Documento HTML
DNS del origen 1
TCP 1
TLS 1.3 1
Peticion y primer byte 1
Transferencia de 45 KB comprimidos 2 (excede la ventana inicial)
---
6
CSS, descubierto en el HTML, misma conexion
Peticion y transferencia de 20 KB 1
---
1
Fuente, descubierta en el CSS, otro origen
DNS 1
TCP 1
TLS 1.3 1
Peticion y transferencia 1
---
4
Imagen del hero, referenciada en el HTML, misma conexion
Peticion 1
Transferencia de 120 KB 3
---
4 (en paralelo con el CSS)
Cadena critica total ~11 viajes secuencialesCon un RTT de 100 milisegundos son 1,1 segundos de espera pura, sin contar proceso de servidor, parseo ni renderizado. Con el RTT de 150 milisegundos del perfil de referencia móvil, 1,65 segundos. El presupuesto de 2,5 segundos del LCP ya está casi consumido.
Cuántos viajes caben
Le damos la vuelta: dado un objetivo de LCP y una latencia, ¿cuántos viajes te puedes permitir?
Reservando alrededor de un 30% del presupuesto para proceso de servidor, parseo, ejecución y renderizado, queda esto:
| RTT | Viajes dentro de 2,5 s |
|---|---|
| 20 ms, fibra a una CDN cercana | ~87 |
| 50 ms, buena conexión móvil | ~35 |
| 100 ms, media razonable | ~17 |
| 150 ms, perfil de referencia móvil | ~11 |
| 300 ms, red móvil congestionada | ~5 |
La última fila es la que asusta y la que explica por qué un sitio puede ir bien para la mayoría y ser inutilizable para una minoría significativa. Con 300 milisegundos de RTT, cinco viajes es todo lo que tienes, y solo el establecimiento de una conexión HTTPS nueva se lleva tres o cuatro.
De ahí sale una regla de diseño que no admite excusas: para que un sitio funcione en redes malas, la ruta crítica tiene que caber en un solo origen y el documento tiene que caber en la ventana inicial. Cualquier otra cosa es inalcanzable.
Los cuatro multiplicadores ocultos
Cuatro patrones aumentan la cuenta sin que resulte evidente al mirar el código.
Cadenas de descubrimiento. Un recurso cuya URL solo se conoce después de descargar y procesar otro. Los casos habituales: la fuente referenciada dentro del CSS, la imagen de fondo dentro del CSS, el módulo importado por otro módulo, el script que inyecta otro script. Cada eslabón añade su cadena completa en serie, no en paralelo.
Redirecciones invisibles. La entrada por http:// que redirige a https://, la de sin www a con www, la de la URL antigua a la nueva. Cada una puede ser una cadena entera si cambia de origen, y suelen encadenarse.
Orígenes ocultos en terceros. Un gestor de etiquetas que carga cuatro proveedores es cuatro cadenas de establecimiento, iniciadas tarde y por tanto sin solaparse con nada. En el HTML solo se ve una etiqueta.
Documentos que exceden la ventana. Cada tramo de unos 14 KB por encima del primero cuesta un viaje. Un documento de 60 KB comprimidos son tres viajes solo de transferencia, y ocurre antes de que el navegador vea el final del <head>.
Ordena tus recursos por instante de inicio y busca los que empiezan justo cuando otro termina: eso son cadenas de descubrimiento. Cuenta los dominios únicos: eso son cadenas de establecimiento. Mira encodedBodySize del documento: si supera los 14.600 bytes, cuenta un viaje más por cada tramo. Los tres datos salen de la API de tiempos de recursos que ya has visto, y entre los tres suele explicarse la diferencia entre lo que crees que cuesta tu página y lo que cuesta.
Recortar por orden de rentabilidad
Cada recorte tiene un valor conocido en viajes, y por tanto en milisegundos. Esta es la lista ordenada.
Eliminar una redirección de entrada a otro origen: 3 a 4 viajes. El mayor recorte disponible y casi siempre es configuración pura. Si tu sitio responde en www pero la gente escribe el dominio desnudo, ese salto lo paga cada primera visita.
Consolidar un origen: 3 a 4 viajes. Servir la fuente, el script o la imagen desde tu propio dominio en lugar de uno ajeno.
Romper una cadena de descubrimiento: 1 a 4 viajes. Si el recurso está en tu origen, romperla ahorra 1 viaje porque el descubrimiento se adelanta. Si está en otro origen, ahorra la cadena entera si además lo consolidas, o la adelanta si usas preconnect.
Bajar el documento de la ventana inicial: 1 a 3 viajes. Reducir el HTML a menos de unos 14 KB comprimidos.
Migrar de TLS 1.2 a 1.3: 1 viaje por conexión nueva. Configuración, gratis, y se multiplica por el número de orígenes.
Servir desde el borde: no reduce viajes, reduce el valor de cada uno. Es multiplicativo con todo lo anterior, y por eso conviene hacerlo en algún momento, pero después de haber recortado los viajes evitables: acortar once viajes es mejor que acelerar diecisiete.
El ejercicio completo
Un método reproducible para cualquier página.
- Carga la página con la caché vacía y en modo incógnito, para no arrastrar conexiones.
- Recoge las entradas de tiempos de recursos y ordénalas por instante de inicio.
- Marca los recursos de la ruta crítica: el documento, todo lo que bloquee el renderizado, y el recurso del elemento LCP.
- Cuenta los orígenes distintos entre ellos y multiplica por 3 los que sean nuevos.
- Suma 1 por cada petición y 1 más por cada 14 KB del primer recurso de cada conexión.
- Identifica las cadenas: recursos que empiezan cuando otro termina.
- Multiplica el total por el RTT de tu percentil 75 de campo.
El número que sale es el suelo teórico de tu LCP. Si tu LCP medido está cerca de él, tu problema es de red y de arquitectura de recursos. Si está muy por encima, hay CPU o bloqueo de renderizado de por medio.
De todo lo que hemos visto, esta es la única cifra que se puede exigir antes de desplegar, sin medir nada, mirando solo el cambio. Añadir un dominio nuevo son tres o cuatro viajes; se ve en el diff. Referenciar una fuente desde el CSS en vez de desde el HTML es un eslabón de cadena; se ve en el diff. Que el HTML crezca por encima de la ventana inicial se ve con un comando. Ninguna métrica de laboratorio permite esto: todas exigen ejecutar, esperar y tener varianza. Por eso el presupuesto de viajes es lo que conviene poner como criterio en integración continua, y no un umbral de LCP simulado. La regla que mejor me ha funcionado en equipos es una frase corta en la guía de revisión: todo cambio que añada un origen nuevo a la ruta crítica necesita justificación explícita y una medida del coste. No prohíbe nada, obliga a que la decisión sea consciente, y elimina de un plumazo el patrón por el que un sitio acaba tocando nueve dominios sin que nadie recuerde por qué.