Un buen tiempo de respuesta para una web, medido como tiempo hasta el primer byte de una página HTML, está aproximadamente por debajo de 200 milisegundos para una página en caché y por debajo de 600 milisegundos para una dinámica. Las recomendaciones de web.dev de Google consideran bueno un tiempo hasta el primer byte de 0,8 segundos o menos. A partir de un segundo, más o menos, los visitantes empiezan a notar la espera antes de que aparezca nada en pantalla. Estas cifras son orientativas, no límites estrictos: lo que más importa es que tu tiempo de respuesta sea estable y que te des cuenta cuando se desvía.
Esta guía explica qué mide el tiempo de respuesta, en qué se diferencia del tiempo de carga de la página, por qué tu monitor y tu navegador dan cifras distintas y cómo seguirlo para que las ralentizaciones se corrijan antes de convertirse en caídas.
El tiempo de respuesta no es el tiempo de carga
Los dos términos se confunden a menudo, pero miden cosas distintas.
El tiempo de respuesta es lo que tarda el servidor en responder a una sola petición. Para un monitor, suele ser el tiempo desde que se envía la petición hasta que llega la respuesta.
El tiempo de carga de la página es lo que tarda el navegador en mostrar una página utilizable. Incluye el tiempo de respuesta del documento HTML, más la descarga y ejecución de CSS, JavaScript, fuentes e imágenes, a menudo decenas de peticiones adicionales.
Una página puede tener un tiempo de respuesta rápido y una carga lenta, por ejemplo cuando el servidor responde en 150 milisegundos pero luego la página carga tres megabytes de JavaScript. Nuestros consejos para que tu web cargue más rápido tratan esa parte del front-end. También ocurre lo contrario: un frontend bien optimizado no puede ocultar un servidor que tarda cuatro segundos en generar el HTML. El tiempo de respuesta es la parte que controlan tu servidor y tu hosting. La carga de la página es la parte que controla tu frontend. Las dos importan, y requieren soluciones distintas. Para la carga de la página, la monitorización de velocidad de página de Uptimecheck ejecuta Google Lighthouse cada día en móvil y escritorio y te avisa cuando la puntuación móvil de una página baja de tu límite.
Qué incluye el tiempo hasta el primer byte
El tiempo hasta el primer byte, o TTFB, es el tiempo desde el inicio de la petición hasta que llega el primer byte de la respuesta. Se compone de varios pasos:
Consulta DNS: convertir el nombre de host en una dirección IP.
Conexión TCP: el viaje de ida y vuelta para abrir una conexión.
Handshake TLS: acordar el cifrado para HTTPS.
Procesamiento en el servidor: la aplicación se ejecuta, consulta la base de datos y construye la respuesta.
Primer byte en la red: el inicio de la respuesta en su viaje de vuelta.
Puedes ver cada paso de tu propio sitio con curl:
curl -o /dev/null -s -w «dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n» https://northwind.shop/
Los valores son acumulativos. Si tls es 0,12 segundos y ttfb es 0,95 segundos, el servidor ha tardado unos 0,8 segundos en generar la página. Esa es la cifra que hay que mejorar. Si los pasos de DNS o de conexión son grandes, el problema es la distancia, la red o el DNS, no tu aplicación. Uptimecheck divide el tiempo de respuesta de cada comprobación en las mismas fases: DNS, conexión, TLS, servidor y descarga.
Por qué los monitores y los navegadores dan cifras distintas
Es normal que tu monitor de uptime, las herramientas para desarrolladores de tu navegador y una herramienta de pruebas de rendimiento muestren tiempos de respuesta distintos para la misma página. Los motivos habituales:
Ubicación. Una comprobación desde otro continente añade viajes de ida y vuelta en cada uno de los pasos anteriores. Un servidor en Estocolmo responde más rápido a un visitante en Estocolmo que a una comprobación desde la costa este de EE. UU.
Reutilización de conexiones. Tu navegador mantiene las conexiones abiertas y las reutiliza. Una comprobación de monitorización suele abrir una conexión nueva cada vez, así que paga DNS, TCP y TLS en cada petición.
Caché. Puede que tu navegador tenga la página, o parte de ella, en caché, y una CDN puede servir una copia en caché a unas regiones y no a otras.
Qué se mide. Una herramienta indica el TTFB, otra el tiempo total de descarga de la respuesta completa y una tercera la carga de toda la página.
Cookies e inicios de sesión. Los usuarios con sesión iniciada suelen saltarse la caché de página, así que sus respuestas son más lentas que una comprobación anónima.
Ninguno de estos motivos hace que una cifra sea incorrecta. Lo que importa es comparar lo comparable: la misma comprobación, desde la misma ubicación, a lo largo del tiempo. Un monitor que mide la misma petición cada minuto te da una referencia constante, y lo que tienes que vigilar son los cambios respecto a esa referencia.
Objetivos razonables, a modo orientativo
Los rangos de abajo son orientativos para la respuesta del servidor de una página HTML o una llamada a una API, medida desde una ubicación razonablemente cercana a tu servidor. Son un punto de partida para tu propia referencia, no un estándar.
Tipo de respuestaCómodoConviene investigarPágina en caché o archivo estático a través de una CDNmenos de 100–200 msmás de 400 msPágina dinámica (CMS, tienda, aplicación)menos de 300–600 msmás de 1 sEndpoint de lectura sencillo de una APImenos de 100–300 msmás de 800 msBúsquedas, informes, consultas pesadasmenos de 1–2 smás de 3 s
Dos apuntes para leer la tabla. Primero, suma la distancia de red: una comprobación desde otro continente puede añadir unos cientos de milisegundos, y eso no es algo que tu aplicación pueda arreglar. Segundo, la columna que más importa es la que fijas tú. Si tu checkout responde normalmente en 350 ms y hoy responde en 900 ms, algo ha cambiado, aunque 900 ms siga pareciendo aceptable sobre el papel.
Qué ralentiza los tiempos de respuesta
Cuando el tiempo de respuesta sube, la causa casi siempre es una de estas:
Consultas lentas a la base de datos: un índice que falta, una consulta que crece con el tamaño de una tabla o un plugin que lanza decenas de consultas por página.
Sin caché de página ni de objetos: cada petición vuelve a construir la misma página desde cero.
Llamadas externas durante la petición: APIs de pago, envíos, búsqueda o analítica llamadas de forma síncrona mientras el visitante espera.
Muy pocos workers: las peticiones se ponen en cola unas detrás de otras cuando todos los workers de PHP-FPM, Node o del servidor de aplicaciones están ocupados.
Presión sobre los recursos: CPU al límite, memoria que tira de swap o E/S de disco saturada por copias de seguridad o escritura de logs.
Arranques en frío: las funciones serverless y los contenedores que han escalado a cero tardan en atender la primera petición.
Distancia: visitantes lejos del servidor sin una CDN de por medio.
Las colas son la razón por la que el tiempo de respuesta importa para la disponibilidad. Cuando las respuestas se vuelven más lentas, cada petición ocupa un worker durante más tiempo, el pool se llena y las peticiones nuevas esperan o se rechazan. Una ralentización que empieza como medio segundo de más puede acabar en un error 503 Service Unavailable en el siguiente pico de tráfico.
Sigue la tendencia, no una comprobación aislada
Una sola comprobación lenta significa poco. Un corte de red puntual, una pausa del recolector de basura o un fallo de caché pueden hacer que una petición sea lenta. Lo que indica que algo va mal es un patrón:
Un salto brusco: el tiempo de respuesta sube tras un despliegue, una actualización de un plugin o un cambio de hosting, y se queda ahí.
Una subida lenta: el tiempo de respuesta crece un poco cada semana a medida que crece una tabla o un log.
Un patrón diario: el tiempo de respuesta se dispara a la misma hora cada día, a menudo por una copia de seguridad, una importación o un cron job que compite por los recursos.
Una diferencia regional: una región va lenta mientras otra va bien, lo que apunta a una CDN, al enrutamiento o al DNS más que al servidor.
Uptimecheck guarda el tiempo de respuesta de cada comprobación de cada monitor de uptime y monitor de API, lo muestra en gráficos con la mediana y el percentil 95, y los informes semanales y mensuales por email incluyen el tiempo medio de respuesta junto al uptime. Ese historial es lo que te permite ver un salto brusco el mismo día en que se produce y no semanas después.
Alerta solo ante lentitud sostenida
Alertar de cada comprobación lenta genera ruido, y las alertas ruidosas acaban ignorándose. Alerta de la lentitud que se mantiene. Un enfoque práctico:
Mide tu referencia para cada endpoint importante durante una o dos semanas.
Fija el nivel de aviso claramente por encima de la variación normal, por ejemplo dos o tres veces el tiempo de respuesta habitual.
Alerta solo cuando la lentitud se mantenga durante varias comprobaciones o minutos seguidos.
Envía los avisos de lentitud a un canal del equipo y reserva las notificaciones push al móvil para los fallos completos.
Pon un tiempo de espera máximo a cada comprobación. Una respuesta que tarda 30 segundos es un fallo para el visitante, sea cual sea el código de estado.
En Uptimecheck fijas un límite de respuesta lenta por monitor. Cuando tres comprobaciones seguidas superan ese límite, recibes una alerta de lentitud, y otra cuando el monitor vuelve a ir rápido. El tiempo lento no cuenta como caída.
Los mismos principios valen para todas las alertas que configures. Nuestra guía para reducir las falsas alertas en la monitorización de uptime trata la confirmación y los umbrales con más detalle, y cómo elegir los umbrales de alerta del servidor explica cómo fijar límites de CPU, memoria y disco. Cuando los tiempos de respuesta suben, la monitorización de servidores junto a tus comprobaciones de uptime muestra si la causa es el servidor, para que no tengas que adivinar entre la base de datos, la red y el código.
Checklist del tiempo de respuesta
Mide el TTFB de tus páginas y endpoints clave con curl, desde cerca de tu servidor.
Monitoriza esas mismas páginas cada minuto y conserva el historial.
Apunta una referencia por endpoint y compara con ella, no con una cifra genérica.
Investiga los saltos bruscos tras los despliegues y las subidas lentas a lo largo de semanas.
Cachea lo que puedas, corrige las consultas lentas y saca las llamadas externas de la petición.
Alerta ante la lentitud sostenida y los tiempos de espera agotados, no ante comprobaciones lentas aisladas.
Resumen
Un buen tiempo de respuesta es el que es bajo para su tipo de página, está cerca de tu propia referencia y se mantiene estable en el tiempo. Como orientación, apunta a unos cientos de milisegundos para las páginas dinámicas y bastante menos para las que están en caché. Mídelo siempre de la misma forma, vigila la tendencia y trata una subida sostenida como un aviso temprano, porque la página lenta de hoy suele ser la caída de mañana.
Uptimecheck registra los tiempos de respuesta en cada comprobación, así que ves tanto las ralentizaciones como las caídas. Pruébalo gratis durante 14 días, sin tarjeta de crédito.