Cómo comprobar el tiempo de respuesta del servidor

Tiempo de respuesta, TTFB y carga de página no son el mismo número

Se usan indistintamente y responden a preguntas distintas:

• El tiempo de conexión es la resolución DNS más el saludo TCP más el saludo TLS. Es sobre todo distancia y calidad de red, y el propio código del servidor no tiene nada que ver.
• El tiempo hasta el primer byte (TTFB) es el momento en que llega el primer byte de la respuesta, medido desde el inicio de la petición. Incluye el tiempo de conexión más el procesamiento del servidor: enrutamiento, consultas a base de datos, renderizado de plantillas, cualquier llamada a una API aguas arriba.
• El tiempo de procesamiento del servidor es el TTFB menos el tiempo de conexión. Esta es la parte que puedes arreglar en tu aplicación.
• El tiempo de carga de la página es todo: el HTML, y luego cada imagen, hoja de estilos, script y fuente que obtiene el navegador, más el trabajo de renderizarlos. Una página puede tener un TTFB excelente y aun así tardar ocho segundos en cargar.

Confundirlos hace que la gente optimice lo que no toca. Comprimir imágenes no hace nada por una consulta de base de datos lenta, y una base de datos más rápida no hace nada por una página que carga cuatro megabytes de JavaScript.

Medirlo con curl

curl reporta cada fase por separado, lo que te deja separar el coste de conexión del coste de servidor en un solo comando:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Todos los valores son segundos desde el inicio de la petición, así que cada uno incluye a los anteriores. El procesamiento del servidor es ttfb menos tls, o menos connect en HTTP plano. Ejecútalo tres o cuatro veces: la primera petición puede pagar el coste de una caché fría o una conexión nueva, y una sola muestra no es una medición.

Dos cosas que conviene tener claras. Esto mide solo el documento HTML, no la página, así que siempre parecerá más rápido que una prueba de navegador. Y una página sin caché, con sesión iniciada o de búsqueda suele ser dramáticamente más lenta que la página de inicio, así que mide la URL que te importa en lugar de /.

Qué cuenta como normal

No hay un umbral universal. Estas franjas son una guía de trabajo razonable para una petición de documento medida desde una ubicación cercana a tus visitantes:

• Menos de 200 ms. Rápido. Típico de contenido estático, una caché caliente, o un borde de CDN que responde directamente.
• De 200 a 500 ms. Normal para una página dinámica que consulta una base de datos. Nadie lo nota.
• De 500 ms a 1 s. Perceptible. Normalmente una consulta que necesita un índice, una plantilla sin caché, o una llamada aguas arriba lenta.
• De 1 a 3 s. Los usuarios lo notan, y los buscadores lo miden. Merece tratarse como un defecto.
• Más de 3 s. Algo va mal: un servidor saturado, un bloqueo, un servicio aguas arriba que agota el tiempo de espera, o una petición haciendo mucho más trabajo del que debería.

La comparación mucho más útil es contigo mismo. Una página que respondía en 300 ms el mes pasado y responde en 900 ms hoy tiene una causa concreta introducida entre medias, y saber eso vale más que cualquier referencia publicada.

Por qué varía según la ubicación

La distancia cuesta tiempo y no se puede optimizar. Cada ida y vuelta entre cliente y servidor tarda al menos lo que permite el camino físico, y una conexión TLS necesita varias idas y vueltas antes de que pueda siquiera empezar el primer byte de la respuesta. Por eso el mismo servidor puede responder en 150 ms en local y en 700 ms desde otro continente haciendo exactamente el mismo trabajo.

El enrutamiento también importa, y es menos predecible que la distancia: el tráfico entre dos redes puede tomar un camino malo que añade latencia para una región y para nadie más. Si usas una CDN, algunas ubicaciones se sirven desde una copia en caché cercana mientras otras fallan la caché y pagan el viaje completo hasta el origen, lo que produce una dispersión amplia entre ubicaciones para la misma URL.

Así que mide desde donde están tus usuarios, no desde donde está tu servidor, y compara lo comparable. Un número sin una ubicación asociada no se puede comparar con nada.

Cuándo lento significa roto

Cierta lentitud es un aviso y no un problema de rendimiento:

• Un tiempo de respuesta que crece de forma constante bajo carga significa que el servidor está saturado. Termina en tiempos de espera agotados, no solo en páginas lentas.
• Tiempos agrupados exactamente en 30 o 60 segundos son tiempos de espera agotados, no lentitud. Algo aguas arriba no está respondiendo y un proxy está esperando a que se cumpla su límite antes de rendirse con un 504.
• Rápido la mayor parte del tiempo con picos enormes ocasionales normalmente señala un bloqueo, una tarea de cron, una copia de seguridad, o una caché que caduca y cada petición la reconstruye a la vez.
• Lento solo para usuarios con sesión iniciada significa que la caché está llevando el tráfico anónimo y ocultando una aplicación genuinamente lenta por debajo.
• Lento solo desde una región es un problema de red o de CDN, no de aplicación, y ninguna cantidad de trabajo en el backend lo va a arreglar.

Notar el día en que cambió

Una sola medición te dice qué pasó para una petición, desde un sitio, en un momento, y el tiempo de respuesta es exactamente el tipo de métrica que se desvía en lugar de romperse de golpe. Las comprobaciones programadas miden la misma URL desde las mismas ubicaciones de forma continua, guardan el historial para que puedas señalar el día en que cambió, y avisan cuando el tiempo cruza un umbral en lugar de cuando se queja un cliente. HostTracker ejecuta esas comprobaciones desde más de 300 puntos de control en 158 ciudades, así que una ralentización regional se ve como tal. Ejecuta una comprobación ahora con la herramienta de comprobación HTTP. Cuando el servidor es rápido y la página sigue sin serlo, el resto de la respuesta está en cómo comprobar la velocidad de un sitio web.