¿Qué es RTT y por qué es importante?
El tiempo de ida y vuelta (RTT) mide el recorrido de una señal hasta el otro extremo y su regreso. No equivale al tiempo de respuesta completo: DNS, conexión, trabajo del servidor y transferencia pueden añadir demora. Las solicitudes paralelas no suman necesariamente un RTT tras otro.
Cómo influye el RTT en Web Vitals
- LCP: el HTML y los recursos críticos lentos pueden retrasar el contenido principal.
- INP: mide hasta el siguiente fotograma, no hasta terminar una petición asíncrona. Los resultados pueden tardar aunque INP sea bueno; mida ambos tiempos.
- TTFB: incluye más que un RTT, por ejemplo procesamiento y conexión. No es un Core Web Vital.
- CLS: un recurso tardío puede desplazar el diseño si no se reservó espacio. Un RTT alto no implica por sí solo un desplazamiento.
Puntos problemáticos típicos de RTT
- Origen distante o saltos adicionales entre CDN y backend.
- Cadenas de solicitudes dependientes y redirecciones.
- Conexiones nuevas que podrían reutilizarse.
- Recursos críticos de terceros descubiertos tarde.
- Procesamiento lento del servidor que parece un problema de red en el tiempo total.
Cómo reducir el RTT en la práctica
- Compare regiones y valore un CDN o procesamiento cercano al público. Compruebe qué respuestas se sirven realmente en el borde.
- Pruebe HTTP/2 y HTTP/3 donde estén disponibles: no eliminan la distancia y HTTP/2 mantiene el bloqueo a nivel TCP.
- Guarde en caché recursos estáticos versionados; para HTML y API, respete privacidad y vigencia.
- Use
<link rel="preconnect">,dns-prefetcho preload de fuentes solo para recursos críticos confirmados. No acortan el RTT físico. - Elimine solicitudes innecesarias, aplace JavaScript no crítico y cargue de forma diferida contenido adecuado fuera de la primera pantalla; no aplace así la imagen LCP.
- Reduzca redirecciones y reutilice conexiones o sesiones TLS. Verifique 0-RTT y los ajustes de certificados para el entorno concreto.
Investigar el RTT con los resultados de Milten
- Compare RTT, latencia del servidor y transferencia por origen en las condiciones del análisis.
- Examine las indicaciones de recursos y la cascada, especialmente antes de LCP/FCP. Una indicación ausente es una hipótesis que investigar.
- Separe procesamiento del servidor y demora de transporte.
- Repita las pruebas tras los lanzamientos. Para comparar ubicaciones, confirme las regiones disponibles y mantenga condiciones equivalentes.
Lista breve de comprobaciones
- Identifique el origen lento y la cadena crítica.
- Compruebe el protocolo navegador–borde y, si existe, el tramo borde–origen.
- Añada solo indicaciones útiles de conexión o precarga.
- Reduzca redirecciones manteniendo la URL final prevista.
- Respete privacidad y vigencia al usar caché o stale-while-revalidate.
- Compare varias pruebas equivalentes y datos de visitas reales.
Empiece por medir
En milten.io, ejecute Speed Scanner, examine los hallazgos de red y elija un cuello de botella confirmado. Guarde las condiciones y el resultado inicial, haga un cambio concreto y vuelva a comparar.
