# Cómo mejorar el TTFB: diagnóstico de una respuesta lenta > Cómo mejorar el TTFB: mide en campo y laboratorio, separa conexión y espera, compara aciertos y fallos de caché y rastrea el trabajo del servidor. Canonical: https://www.getdexseo.com/es/blog/rendimiento-web/mejorar-ttfb/ Author: Dex SEO, Editorial team Published: Oct 24, 2026 · Updated: Oct 24, 2026 ## Key takeaways - Mide el TTFB con pruebas repetidas y condiciones anotadas. - Separa la conexión de la espera de la respuesta. - Compara aciertos y fallos de caché. - Elige el arreglo según el rastreo del servidor. Para mejorar el TTFB, primero averigua dónde ocurre la espera antes de cambiar de hosting o de caché. Compara el mismo documento en pruebas repetidas, desde distintos lugares y con distintos estados de caché. Después pide al responsable del servidor que rastree el trabajo que sigue siendo lento. El objetivo es encontrar una causa que se pueda probar, no comprar un plan más rápido a ciegas. Esta guía forma parte de la guía de [rendimiento web](https://www.getdexseo.com/es/blog/rendimiento-web/). ## ¿Qué es el TTFB y qué indica un valor lento? El TTFB (Time to First Byte, tiempo hasta el primer byte) mide cuánto tarda en llegar el primer byte de la respuesta después de pedir una página. Es una etapa temprana de la carga y puede incluir más que el trabajo del servidor: la conexión, la distancia, las redirecciones y la caché también influyen. Comprueba qué definición y qué petición usa tu herramienta. La guía de Google para [optimizar el tiempo hasta el primer byte](https://web.dev/articles/optimize-ttfb?hl=es-419) propone, como referencia aproximada, un TTFB de 0,8 segundos o menos para la mayoría de los sitios. El TTFB no es una de las Core Web Vitals, pero un valor alto retrasa todo lo que viene después, incluido el LCP. Escribe un síntoma claro: “la página de servicio espera antes de recibir el documento en estas pruebas”. Guarda la URL y las condiciones junto a esa frase. Evita decir “el servidor va mal” hasta tener evidencia que acote la causa. ## Cómo medir el TTFB: campo y laboratorio Los datos de campo reflejan visitas reales desde muchos lugares y redes. Las pruebas de laboratorio usan condiciones fijas. Una prueba cerca de tu servidor puede no representar a un lector lejano. Google recomienda usar la cabecera `Server-Timing`, cuando la aplicación la ofrece, para ver qué trabajo del servidor ocurre antes de la respuesta. Elige varios tipos de página reales: una página de servicio, un artículo y una página con más trabajo de datos. Prueba las versiones públicas con el mismo estado de sesión. Anota el dispositivo, la conexión, la región, la herramienta y la hora. Repite cada caso más de una vez y guarda el rango, no solo un valor típico. Si una prueba es mucho más lenta, no la borres: busca su contexto. ## Separa la conexión de la espera de la respuesta Abre la petición del documento en el panel Red del navegador y revisa su desglose de tiempos. Anota el tiempo de conexión y el tiempo de espera de la respuesta. Guarda la cadena de redirecciones si la visita pasa por más de una URL: cada redirección añade una espera. Si la espera cambia según el lugar, pide al equipo de entrega que compare las rutas. Si solo un tipo de página es lento, pregunta al responsable de la aplicación qué construye esa página. Son pistas, no pruebas. El tiempo de espera del navegador no dice cuánto tardó una consulta a la base de datos; para eso hace falta evidencia del servidor. ## Compara aciertos y fallos de caché Sigue los pasos para [comprobar si la caché funciona](https://www.getdexseo.com/es/blog/rendimiento-web/comprobar-cache-web/) antes de comparar tiempos. Etiqueta las peticiones con las señales de tu servicio de entrega, incluidas las exclusiones previstas para páginas con sesión o personales. Si un acierto es rápido y un fallo es lento, revisa el trabajo necesario para construir la respuesta sin caché. Si los dos son lentos, revisa desde dónde se sirve la petición y su ruta. No metas páginas privadas en una caché compartida para esconder una espera. Comprueba también que la prueba refleja una visita habitual: una URL poco usada o un parámetro especial pueden seguir otra regla de caché. ## Rastrea el trabajo del servidor en el caso lento Da al desarrollador un grupo pequeño de peticiones lentas y repetibles. Pregunta qué trabajo ocurre antes de enviar los primeros bytes: acceso a datos, renderizado, un servicio externo o una cola. Deja que el rastreo decida dónde centrarse. No sumes todas las duraciones sin saber cómo se midieron ni si se solapan. En WordPress, si un plugin es una causa posible, usa una [prueba controlada de plugins](https://www.getdexseo.com/es/blog/rendimiento-web/plugins-lentos-wordpress/) en una copia segura. El número de plugins no es un rastreo. Confirma que la mejora se mantiene en pruebas repetidas y que las funciones necesarias siguen funcionando. ## Cómo reducir el TTFB según la evidencia La guía de web.dev agrupa las mejoras habituales: un hosting adecuado, una CDN, servir contenido desde la caché cuando se pueda, evitar varias redirecciones y enviar el HTML al navegador por partes. Úsala como lista de opciones, no como receta. Pide una propuesta corta con causa, responsable, prueba y plan de vuelta atrás: - Si el rastreo muestra trabajo de datos repetido, prueba un cambio en ese trabajo. - Si la ruta tiene redirecciones evitables, revisa la ruta. - Si las páginas sin caché son lentas, revisa qué se puede guardar sin servir contenido equivocado. - Si el hosting no tiene recursos bajo carga, reúne esa evidencia antes de cambiar de plan. Haz un cambio útil cada vez y mantén las mismas páginas y condiciones. Una prueba más rápida después de varios cambios sin relación no dice cuál ayudó. No saques contenido importante de la primera respuesta solo para mejorar el número: una página que empieza rápido pero deja al lector esperando su respuesta sigue siendo mala. ## Ejemplo: diagnóstico en una web de servicios _Ejemplo ficticio._ En una empresa local, la página de servicio es lenta y la página de contacto es rápida. Es un ejemplo de método, no un resultado medido. Quien revisa prueba las dos con el mismo navegador y anota si cada petición usa una respuesta guardada. El desarrollador rastrea la página lenta en una copia de prueba. Investiga una llamada a un servicio externo porque aparece en la ruta de esa respuesta. El equipo prueba un cambio acotado, restaura la versión anterior para comparar y revisa el formulario de reserva antes de publicar. La nota final dice qué se observó, qué cambió y qué sigue sin estar claro. ## Revisa el resto de la página después Un mejor TTFB resuelve solo una parte. Revisa qué [imágenes cargan primero](https://www.getdexseo.com/es/blog/rendimiento-web/lazy-loading-imagenes/) para que el contenido principal llegue a tiempo, y la [carga de fuentes](https://www.getdexseo.com/es/blog/rendimiento-web/optimizar-fuentes-web/) para que el texto se vea pronto. Comprueba el espacio de los medios con la guía para [reducir el CLS](https://www.getdexseo.com/es/blog/rendimiento-web/reducir-cls-imagenes/) y usa una grabación aparte para el [JavaScript lento](https://www.getdexseo.com/es/blog/rendimiento-web/tiempo-ejecucion-javascript/). Esos problemas pueden seguir aunque el documento responda rápido. DEX conecta la investigación de búsquedas, la planificación de contenido, la redacción de artículos y la publicación en el sitio conectado. DEX Health ofrece una revisión SEO de la página, también en el plan gratuito. Úsalo junto a la evidencia de tiempos: no sustituye a un rastreo del servidor ni prueba una mejora del TTFB. Repite las mismas rutas tras publicar y guarda el registro para la próxima revisión. ## FAQ ### ¿El TTFB es el tiempo total de carga? No. Mide solo la espera hasta el primer byte de la respuesta. ### ¿Un TTFB lento prueba que el hosting es el problema? No. Influyen la conexión, las redirecciones, la caché y el trabajo de la aplicación. ### ¿Debo mover contenido al navegador para bajar el TTFB? No. El lector seguiría esperando su respuesta. ## Sources - [Optimiza el tiempo hasta el primer byte](https://web.dev/articles/optimize-ttfb?hl=es-419) — web.dev (Google) - [Evita solicitudes de red innecesarias con la caché HTTP](https://web.dev/articles/http-cache?hl=es-419) — web.dev (Google)