Tiempo de Respuesta de un Sitio Web: Qué Es, Cómo Medirlo y Cómo Mejorarlo

El tiempo de respuesta de un sitio web es el tiempo que pasa desde que un navegador (o cualquier cliente) envía una solicitud a tu web hasta que recibe la primera parte de la respuesta del servidor. Incluye encontrar tu servidor, conectarse a él, establecer el cifrado y esperar a que tu aplicación genere la página. Es una de las señales de salud más útiles que tiene una web, y a menudo se confunde con el tiempo de carga de la página.

Esta guía explica qué incluye el tiempo de respuesta, cómo medirlo, qué valor es bueno, cómo interpretar las cifras a lo largo del tiempo y qué mejoras marcan más la diferencia. ¿Quieres una cifra ahora mismo? Usa la herramienta gratuita de tiempo de respuesta web y vuelve para interpretar los resultados.

Qué incluye el tiempo de respuesta de un sitio web

Una sola solicitud a una página HTTPS pasa por varias fases. Cada una añade tiempo, y cada una tiene causas y soluciones distintas.

Desliza hacia el lado para ver el diagrama completo

El tiempo desde el inicio de la solicitud hasta que llega el primer byte de la respuesta se llama Time to First Byte (TTFB), o tiempo hasta el primer byte. En la práctica, "tiempo de respuesta del servidor" y TTFB se usan a menudo como sinónimos; los monitores de uptime suelen informar del tiempo hasta que llegan las cabeceras de la respuesta, que es prácticamente el mismo momento.

Conviene conocer dos detalles:

• Las visitas repetidas son más rápidas. Los navegadores guardan en caché las respuestas DNS y reutilizan las conexiones abiertas, así que el DNS, la conexión y el TLS suelen desaparecer en la segunda página que abre un visitante. Una primera visita, o una comprobación de monitoreo con una conexión nueva, paga todas esas fases.
• Las redirecciones multiplican el coste. Si http://example.com redirige a https://www.example.com/, el visitante paga dos solicitudes antes de ver nada.

Tiempo de respuesta frente a tiempo de carga de la página

El tiempo de respuesta y el tiempo de carga miden cosas distintas:

• El tiempo de respuesta te dice lo rápido que el servidor empieza a responder a la solicitud del documento HTML.
• El tiempo de carga de la página, y métricas centradas en el usuario como el Largest Contentful Paint (LCP), incluyen todo lo que ocurre después: descargar hojas de estilo, scripts, fuentes e imágenes, y renderizar la página.

Una página puede tener una respuesta rápida del servidor y aun así parecer lenta por imágenes o scripts pesados, y un front-end muy bien optimizado no puede ocultar un servidor que tarda tres segundos en responder. El tiempo de respuesta es la base: todas las demás métricas de carga empiezan después. Google documenta las métricas centradas en el usuario en web.dev/vitals. Comparamos las dos perspectivas en Uptime frente a rendimiento de un sitio web.

¿Cuál es un buen tiempo de respuesta para un sitio web?

No hay una única cifra correcta, porque el tiempo de respuesta depende de la distancia, del tipo de página y del hosting. Algunos puntos de referencia útiles:

• Las recomendaciones de Google sobre el Time to First Byte sugieren que la mayoría de los sitios aspiren a 0,8 segundos o menos y consideran deficientes los valores superiores a 1,8 segundos, medidos con usuarios reales.
• Las páginas estáticas o bien almacenadas en caché, servidas desde cerca, pueden responder en decenas de milisegundos.
• Las páginas dinámicas que consultan una base de datos suelen responder en unos cientos de milisegundos.
• Tardar sistemáticamente más de uno o dos segundos suele indicar algo que merece investigarse.

Más importante que cualquier objetivo absoluto es tu propia referencia. Si tu página de inicio suele responder en 250 ms y de repente tarda 1.500 ms, algo ha cambiado, aunque 1,5 segundos no sea catastrófico por sí solo.

Cómo medir el tiempo de respuesta de un sitio web

1. Usa una herramienta online de tiempo de respuesta

La opción más rápida es una herramienta que solicite tu página desde un servidor externo y desglose el resultado por fases. Nuestra herramienta gratuita de tiempo de respuesta web envía tres solicitudes con conexiones nuevas, muestra la mediana del tiempo hasta el primer byte y te dice cuánto tardaron el DNS, la conexión, el TLS y el procesamiento en el servidor, para que veas qué parte hay que arreglar.

2. Mídelo desde la línea de comandos con curl

curl puede mostrar tiempos detallados. Guarda este formato en un archivo llamado curl-format.txt:

    dns lookup:  %{time_namelookup}s
       connect:  %{time_connect}s
   tls (total):  %{time_appconnect}s
 first byte at:  %{time_starttransfer}s
         total:  %{time_total}s

Luego ejecuta:

curl -o /dev/null -s -w "@curl-format.txt" https://example.com/

Ten en cuenta que curl informa de tiempos acumulados: cada valor se mide desde el inicio de la solicitud. Para obtener la duración de una sola fase, resta el valor anterior. Por ejemplo, el procesamiento en el servidor es aproximadamente time_starttransfer − time_appconnect.

3. Usa las herramientas para desarrolladores del navegador

Abre las herramientas para desarrolladores, ve a la pestaña Red, recarga la página y selecciona la primera solicitud (el documento HTML). La vista de tiempos muestra la consulta DNS, la conexión inicial, el SSL, la "espera de la respuesta del servidor" (TTFB) y la descarga del contenido. Recuerda que tu propio navegador puede reutilizar el DNS en caché y las conexiones abiertas.

4. Monitoréalo de forma continua

Una sola medición es una foto fija. El tiempo de respuesta cambia con el tráfico, la hora del día, las tareas en segundo plano y el crecimiento gradual de los datos. Un monitor de uptime registra el tiempo de respuesta en cada comprobación, lo que convierte las fotos fijas en una tendencia. UptimeStats guarda el tiempo de respuesta de cada comprobación, cada 5 minutos, y muestra gráficos de 24 horas y de 7 días en la página de cada sitio web.

Cómo interpretar los datos de tiempo de respuesta

Fíjate en las tendencias, no en valores sueltos

Las comprobaciones individuales varían por las condiciones de la red. Una comprobación lenta rara vez significa algo. Mira el gráfico a lo largo de horas y días: ¿la línea es plana, sube poco a poco o tiene picos a ciertas horas? Las medianas y las medias de un periodo son más fiables que los valores individuales.

Patrones y lo que suelen significar

• Aumento gradual durante días o semanas: tablas de la base de datos que crecen sin índices adecuados, datos que se acumulan, un disco que se llena o un tráfico que crece.
• Picos a la misma hora cada día: tareas programadas, como copias de seguridad, importaciones o generación de informes, que compiten por los recursos.
• Un salto repentino: un despliegue, la actualización de un plugin, un cambio de configuración o un cambio de hosting.
• Tiempos de respuesta en aumento seguidos de tiempos de espera agotados: el servidor se está quedando sin capacidad, un aviso temprano de una caída. Consulta ¿Qué provoca que una web se caiga?
• Conexión y TLS lentos pero procesamiento rápido en el servidor: el servidor está lejos del punto de medición, o la ruta de red está congestionada.

La distancia importa

El tiempo de respuesta medido desde un servidor de monitoreo depende de la distancia entre ese servidor y el tuyo. Un monitor en otro continente siempre ve cifras más altas que uno cercano. Compara mediciones hechas desde la misma ubicación a lo largo del tiempo, y recuerda que la experiencia de tus visitantes depende de dónde estén ellos.

Cómo mejorar el tiempo de respuesta de un sitio web

Empieza por la fase que más tarda. El desglose de la herramienta de tiempo de respuesta o de curl te dice cuál es.

Si el procesamiento en el servidor es lento

Es el cuello de botella más habitual y normalmente la mayor oportunidad.

• Almacena en caché páginas completas. La respuesta más rápida es la que el servidor no tiene que calcular. La caché de página completa sirve HTML ya generado a los visitantes anónimos; la mayoría de los gestores de contenido tienen plugins o módulos de caché maduros.
• Usa una caché de objetos. Un almacén en memoria evita repetir consultas y cálculos costosos en cada solicitud.
• Optimiza las consultas a la base de datos. Activa el registro de consultas lentas, añade índices para las búsquedas frecuentes, carga solo los datos que necesita cada página y elimina consultas que se ejecutan en cada solicitud sin necesidad.
• Revisa los plugins y las extensiones. Cada uno puede añadir trabajo a todas las solicitudes. Quita lo que no uses y mide después de cada cambio.
• Mantén el software al día. Las versiones nuevas de los lenguajes, los servidores web y las bases de datos suelen traer mejoras de rendimiento importantes, además de correcciones de seguridad.
• Saca el trabajo lento de la solicitud. Enviar correos, generar miniaturas o llamar a APIs externas lentas puede hacerse en tareas en segundo plano.
• Dimensiona bien el servidor. Si la CPU o la memoria están siempre cerca del límite, la optimización tiene un techo; puede que hagan falta más recursos o más servidores.

Si la conexión y el TLS son lentos

• Sirve la web más cerca de tus visitantes. Elige una región de hosting cercana a tu público principal, o pon una CDN delante del sitio para que las conexiones terminen cerca de ellos.
• Activa TLS 1.3. Necesita menos viajes de ida y vuelta en el handshake que las versiones anteriores.
• Activa HTTP/2 o HTTP/3 para reducir el coste de conexión de los recursos que llegan después del HTML.
• Sirve una cadena de certificados compacta y completa y activa el OCSP stapling. Revisa tu certificado con la herramienta para comprobar el certificado SSL.

Si el DNS es lento

• Usa un proveedor de DNS rápido y fiable, con servidores cerca de tu público.
• Evita las cadenas largas de registros CNAME, en las que cada uno requiere otra consulta.
• Usa TTL razonables para que los resolvedores puedan guardar las respuestas en caché. Revisa tus registros con la herramienta de consulta DNS y lee cómo afectan los problemas de DNS a la disponibilidad.

Si las redirecciones añaden tiempo

Enlaza directamente a las URLs finales, actualiza los enlaces internos tras las migraciones y deja las redirecciones necesarias en un solo salto, por ejemplo directamente de http://example.com a https://example.com/. La herramienta para comprobar el estado HTTP muestra las cadenas de redirecciones, y nuestra guía de códigos de estado HTTP explica la diferencia entre 301 y 302.

Errores habituales al medir el tiempo de respuesta

• Probar solo desde tu propio ordenador. Tu navegador reutiliza conexiones y el DNS en caché, y puede que estés cerca del servidor.
• Juzgar por una sola medición. Usa varias muestras y fíjate en la mediana.
• Medir solo una página en caché. La página de inicio puede estar en caché mientras las páginas de producto, búsqueda o cuenta se generan en cada solicitud. Prueba las páginas que importan.
• Confundir tiempo de respuesta con tiempo de carga. Un TTFB rápido no garantiza una página rápida, y la solución de cada uno es distinta.
• Ignorar la tendencia. Unos tiempos de respuesta que suben poco a poco son uno de los mejores avisos tempranos que puedes tener.

Preguntas frecuentes

¿Qué diferencia hay entre tiempo de respuesta y TTFB?

El TTFB es el tiempo hasta que llega el primer byte de la respuesta. "Tiempo de respuesta del servidor" se usa a menudo para decir lo mismo. Algunas herramientas llaman "tiempo de respuesta" a la descarga completa de la respuesta, así que comprueba cómo lo define cada herramienta.

¿El tiempo de respuesta de una web afecta al SEO?

El tiempo de respuesta es la primera parte de cada carga de página, así que influye en métricas centradas en el usuario como el Largest Contentful Paint, que forman parte de cómo valoran los buscadores la experiencia en la página. La relevancia y la calidad del contenido importan mucho más, pero un servidor lento hace que todo lo demás vaya más lento. Las respuestas muy lentas o fallidas también afectan a la eficiencia con que los buscadores rastrean tu web.

¿Por qué mi tiempo de respuesta cambia cada vez que lo pruebo?

Las condiciones de la red, la carga del servidor, la caché y las tareas en segundo plano varían. Por eso las buenas herramientas toman varias muestras e informan de la mediana, y por eso monitorear a lo largo del tiempo aporta más que una sola prueba.

¿Con qué frecuencia debo comprobar el tiempo de respuesta?

De forma continua, mediante el monitoreo. Las comprobaciones cada pocos minutos te dan una tendencia fiable sin añadir una carga relevante a tu servidor.

Resumen

• El tiempo de respuesta de un sitio web es lo que tarda el servidor en empezar a responder, incluidos el DNS, la conexión, el TLS y el procesamiento en el servidor.
• Google sugiere aspirar a un TTFB de 0,8 segundos o menos; tu propia referencia y la tendencia importan todavía más.
• Mídelo con un desglose por fases para saber qué arreglar: una herramienta online, curl o las herramientas para desarrolladores del navegador.
• La caché y unas consultas eficientes a la base de datos arreglan la mayoría de los servidores lentos; las CDN, TLS 1.3 y menos redirecciones atacan los retrasos de red.
• Monitorea el tiempo de respuesta de forma continua para detectar la lentitud antes de que se convierta en una caída.

Prueba tu web ahora con la herramienta gratuita de tiempo de respuesta, o empieza a monitorear gratis para seguir el tiempo de respuesta cada 5 minutos.