Qué es el tiempo de respuesta de un sitio web

El tiempo de respuesta contesta a una pregunta sencilla: cuando algo pide tu sitio web, ¿cuánto tarda en llegar la respuesta? Una herramienta de monitorización pregunta igual que un navegador, con una petición HTTP, y mide la espera.

Es uno de los pocos números que muestran un problema antes de que se convierta en una caída. Un sitio que responde en 300 milisegundos el lunes y en 2500 milisegundos el viernes sigue estando «activo», pero algo ha cambiado.

Qué ocurre durante una petición

Una sola petición pasa por varias etapas. Cada una consume tiempo y cada una puede ser lenta por un motivo distinto.

1. Consulta DNS. El nombre example.com se convierte en una dirección IP. Puede ser rápida cuando la respuesta está en caché cerca y lenta cuando no.
2. Conexión TCP. El cliente abre una conexión con esa dirección. El tiempo depende sobre todo de la distancia y de la calidad de la ruta de red.
3. Negociación TLS. En las direcciones https, ambas partes acuerdan el cifrado y el cliente comprueba el certificado del servidor. Esto añade unos cuantos viajes de ida y vuelta más.
4. Petición y procesamiento en el servidor. Se envía la petición. El servidor puede leer archivos, consultar una base de datos o ejecutar código de la aplicación antes de poder responder.
5. Primer byte. Llega la primera parte de la respuesta. El tiempo hasta este momento se llama tiempo hasta el primer byte (TTFB).
6. Resto de la respuesta. Se transfieren los datos restantes.

Las redirecciones se suman a esto. Si la dirección responde con una redirección, el cliente repite las etapas para la siguiente dirección. Una cadena de redirecciones multiplica el coste.

Tiempo hasta el primer byte y tiempo total

Se usan sobre todo dos números:

• El tiempo hasta el primer byte (TTFB) es la espera hasta que llega el primer byte de la respuesta. Desde dónde empieza a contar depende de la herramienta. La guía de rendimiento web de web.dev lo cuenta desde el inicio de la navegación, lo que incluye las redirecciones, la consulta DNS, el establecimiento de la conexión, la negociación TLS y la espera al servidor. Algunas herramientas miden solo desde el momento en que se envía la petición, lo que excluye las etapas de preparación. Al comparar números de herramientas distintas, comprueba qué definición usa cada una.
• El tiempo de respuesta total es el tiempo hasta que se ha recibido la respuesta completa. En una comprobación sencilla de una página, suma la transferencia de la respuesta al TTFB.

Un TTFB alto con etapas de conexión rápidas apunta al servidor o a la aplicación que hay detrás. Unas etapas de DNS o de conexión lentas apuntan al servidor de nombres o a la red.

Tiempo de respuesta y latencia

La latencia es el retraso que añade la propia red, principalmente el tiempo que necesita una señal para viajar. La distancia importa: una petición desde Singapur a un servidor en Fráncfort tarda más que una desde Berlín, aunque el servidor sea igual de rápido. El tiempo de respuesta incluye la latencia más el trabajo que hace el servidor.

El tiempo de respuesta no es el tiempo de carga de la página

Una comprobación de monitorización solicita una única dirección y mide la respuesta. No se comporta como un navegador que abre una página.

Un navegador también descarga imágenes, hojas de estilo, scripts y fuentes, ejecuta los scripts y dibuja la página. Las medidas de esa experiencia, como el Largest Contentful Paint o las Core Web Vitals, describen lo que ve un visitante y cuándo lo ve. Necesitan un navegador real.

Una página puede tener una respuesta rápida del servidor y aun así resultar lenta por scripts pesados o imágenes grandes. También puede ocurrir lo contrario. Por eso, el tiempo de respuesta HTTP se interpreta mejor como una medida del servidor y del camino hasta él, no de todo lo que experimenta un visitante. UptimeWire mide lo primero. No ejecuta un navegador y no informa de las Core Web Vitals.

Por qué cambia el tiempo de respuesta

• Tráfico. Más visitantes simultáneos compiten por los mismos recursos.
• Trabajo pesado en segundo plano. Las copias de seguridad, las importaciones o las tareas programadas pueden quitar capacidad a los visitantes.
• Consultas lentas a la base de datos. Una consulta que era rápida con pocos datos puede ralentizarse a medida que los datos crecen.
• Caché. Una página en caché puede ser muchas veces más rápida que una generada bajo demanda.
• Cambios en el sitio. Un lanzamiento, un plugin o una nueva llamada a un tercero pueden añadir tiempo de la noche a la mañana.
• La red. La congestión y los cambios de ruta afectan al tiempo de conexión y pueden variar según la hora del día.
• Desde dónde se ejecuta la comprobación. La distancia al servidor importa, como se ha descrito más arriba.

Comprobar desde distintos lugares

Una medición dice cómo responde el sitio desde un lugar. Los servicios que comprueban desde varias ubicaciones pueden mostrar si una respuesta lenta es global o regional. Un servidor que responde en 200 milisegundos cerca de su centro de datos y en 900 milisegundos desde el otro lado del mundo se comporta con normalidad. Un sitio que es lento en todas partes apunta al servidor.

Cuando compares números a lo largo del tiempo, mantén constantes el lugar y el intervalo. De lo contrario, un cambio en el número puede deberse al método y no al sitio.

Un ejemplo práctico

Una comprobación sobre una dirección https registra:

Leyendo el primer byte contado desde el inicio de la comprobación, la respuesta empezó a llegar a los 312 milisegundos, de los cuales 83 milisegundos se fueron en la preparación (18 + 24 + 41). Los 229 milisegundos restantes corresponden aproximadamente al viaje de la petición hasta el servidor, a la preparación de la respuesta por parte del servidor y a la vuelta del primer byte. Si la comprobación del día siguiente muestra 1180 ms hasta el primer byte con las etapas de preparación sin cambios, el tiempo extra está en el servidor, no en el DNS ni en la red.

Qué es un buen valor

No existe un único valor correcto. La guía de web.dev sobre el TTFB, pensada para páginas que los visitantes cargan en un navegador, usa 0,8 segundos o menos como referencia aproximada de «bueno» y más de 1,8 segundos como «malo». Tómalo como orientación y no como objetivo para todos los sitios. Una API a la que llaman otros sistemas puede necesitar responder mucho más rápido. Una página con mucho trabajo en el servidor puede tardar más con toda razón.

La comparación más útil es la del sitio con su propia normalidad: qué es lo habitual y en qué se diferencia hoy.

Tiempo de respuesta en UptimeWire

UptimeWire envía una petición HTTP a la dirección de cada sitio web que configuras y registra el tiempo que tarda, junto con el resultado. El primer byte se cuenta desde el inicio de la comprobación, así que incluye las etapas de preparación y las redirecciones, y el total abarca toda la comprobación.

El desglose por etapas forma parte del informe detallado de la comprobación, disponible desde el plan Starter. En el plan Free ves el tiempo de respuesta de cada comprobación, sin el desglose en etapas.