--- title: "TTFB. Como de rápida es tu web - Carlos Sánchez" description: "Cuanto tarda tu web desde que tu usuario hace click hasta que le llega información" author: "Carlos Sánchez" url: https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/ image: https://carlossanchezdonate.com/wp-content/uploads/tb-ttfb-slow.jpg --- # TTFB utilidad, diagnóstico y optimización Esta es la mejor guía que puede tener cualquier usuario técnico y no técnico sobre el TTFB, escrita por un SEO Técnico experto en programación y con alto conocimiento sobre el funcionamiento de Google Cuanto tarda tu web desde que tu usuario hace click hasta que le llega información ![TTFB utilidad, diagnóstico y optimización](https://carlossanchezdonate.com/wp-content/uploads/cover-ttfb-slow.avif) **Autor:** : [Carlos Sánchez](https://carlossanchezdonate.com/sobre-mi/) **Temática: ** : [WPO](https://carlossanchezdonate.com/seo-avanzado/rendimiento-velocidad/) **Fecha de publicación:** : 2025-09-07 **Última revisión:** : 2025-09-10 **Índice** mostrar 1 Cómo se mide el TTFB 2 Causas de un TTFB lento 2.1 Red y cliente 2.1.1 Estacionalidad y puntos geográficos implicados 2.1.2 Redes en general 2.2 Mala optimización de la web 2.3 Problema del servidor 3 Solución de problemas 4 Conclusión **El TTFB**, Time To First byte (tiempo hasta el primer byte), como su propio nombre indica, calcula el tiempo que trascurre desde que el usuario entra a una página hasta que el navegador comienza a recibir los datos del servidor. Para entenderlo bien, el TTFB incluye varios pasos en la conexión: - Resolución DNS. - Conexión TCP y negociación TLS (si aplica). - Procesamiento de la petición en el servidor. - Primer byte de respuesta enviado al navegador. Si bien el TTFB no es una "métrica principal" de [Core Web Vitals,](https://carlossanchezdonate.com/curiosidades/pagespeed-insights-rendimiento-vs-velocidad/)incide directamente sobre el **LCP**,  que sí que lo es. Por lo que, a menos que esté muy bien optimizado el resto de cosas, un TTFB suele producir [un LCP lento](https://carlossanchezdonate.com/seo-avanzado/rendimiento-velocidad/#informacion). Es importante distinguirlo del **LCP, **aunque estén relacionados, no son exactamente lo mismo**,** ya que el LCP calcula cuánto tarda en renderizarse el elemento más grande visible en la ventana del usuario. Es decir: el TTFB mide el retardo entre la petición y la primera respuesta, no el tiempo completo de carga de la página. ** El LCP mide el tiempo que tarda en cargarse el elemento más grande visible dentro del [viewport](https://carlossanchezdonate.com/articulo/vh-css-rendering/) de una página web. Una métrica muy a tener en cuenta para [comprobar el rendimiento de una página web](https://carlossanchezdonate.com/articulo/medir-la-velocidad-de-una-web-wpo/). No obstante, si el servidor tarda demasiado en entregar el primer byte, el navegador ni siquiera puede empezar a descargar y renderizar el contenido, lo que retrasa el LCP. Yendo al grano: el TTFB es un factor de velocidad que afecta directamente al LCP, una de las tres métricas principales de CWV. ![Montar una web basica](https://carlossanchezdonate.com/wp-content/uploads/funcionamiento-web-basico.jpg) [Funcionamiento de una web básica](https://carlossanchezdonate.com/articulo/como-funciona-una-web/). Si bien, en esta métrica, hay cuestiones que no afectan como: si las imágenes son avif o jpg; precargas; cargas diferidas o si se tiene insertado un iframe. El código puede ser uno de los culpables de tener una mala nota en esta métrica, ya que un código mal optimizado puede hacer que el servidor tarde más en realizar una respuesta. Hay varios sospechosos de un TTFB lento, pero antes de identificarlos y solucionarlos, es importante aprender a medirlo. ## Cómo se mide el TTFB Cuando utilizamos el [PageSpeed Insights](https://carlossanchezdonate.com/articulo/medir-la-velocidad-de-una-web-wpo/#pagespeed-insights), una de las métricas que nos salen en el caso de que suficientes usuarios visiten esa página o grupo de páginas desde Chrome, es el TTFB, esta además nos sale como "otras métricas destacadas" ![](https://carlossanchezdonate.com/wp-content/uploads/core-web-vitals-pagespeed.avif) > Una misma página te puede dar un TTFB distinto aunque lo analices el mismo día sin haber hecho un cambio en la web. Tanto el dispositivo, como el servidor, como el estado de la red, pueden experimentar diferencias a lo largo del día, por lo que el tiempo del TTFB está sujeto a distintas condiciones. > > > Lo ideal es calcular el promedio. Por ejemplo, las Core Web Vitals (que podemos verlo con PageSpeed Insights) mide el TTFB que han tenido los usuarios desde Chrome durante los últimos 28 días. Es importante tener en cuenta lo que he comentado, lo que nos interesa a nivel Core Web Vitals es el CrUX (señalado en azul en la siguiente imagen) y tanto la información de laboratorio (señalada en morado en la siguiente imagen), como origen o la URL en concreto, nos puede dar pistas o información también acerca del TTFB. ![](https://carlossanchezdonate.com/wp-content/uploads/laboratorio-crux.webp) Además de PageSpeed, para tener más precisión, podemos utilizar otras herramientas externas complementarias, que nos sirvan para medir esto, como pueden ser, entre otras: - [Webpagetest](https://www.webpagetest.org/) - [Pingdom Tools](https://tools.pingdom.com/) - [GTMetrix](https://gtmetrix.com/) - [Devtools](https://carlossanchezdonate.com/articulo/devtools-para-seo/) Voy a poner el ejemplo con Webpagetest, que me gusta mucho, y voy a hacer la comparativa entre dos páginas y su TTFB. Cuando se hace un análisis comparativo, para ver si una web tiene un buen TTFB o no, se debe poner la misma configuración y mismo periodo. De hecho, aunque no toquemos nada, analizando la misma web en momentos distintos nos darán resultados distintos. ![](https://carlossanchezdonate.com/wp-content/uploads/geohat-ttfb-home.jpg) ![](https://carlossanchezdonate.com/wp-content/uploads/wpo-core-web-page-test-ct-geohat.avif) > Como he comentado, los resultados incluso con la misma configuración te pueden variar. Resultados test Geohat: - 07/08/2025: [https://www.webpagetest.org/result/250807_YiDcZR_7Y5/](https://www.webpagetest.org/result/250807_YiDcZR_7Y5/)  TTFB: 0.769 LCP: 1.775 SI: 1.754 - 07/09/2025: [https://www.webpagetest.org/result/250907_YiDcN5_3H7/](https://www.webpagetest.org/result/250907_YiDcN5_3H7/) TTFB: 0.992 LCP: 2.060 SI: 1.807 Resultados Ayto Cartagena: - 07/08/2025 [https://www.webpagetest.org/result/250807_YiDcWG_802/](https://www.webpagetest.org/result/250807_YiDcWG_802/) TTFB: 1.701 LCP: 23.895 SI: 14.075 - 07/09/2025 [https://www.webpagetest.org/result/250907_YiDcNJ_3NP/](https://www.webpagetest.org/result/250907_YiDcNJ_3NP/)  TTFB: 1.605 LCP: 11.001 SI: 11.744 Ambas webs, sin haber hecho ningún cambio sustancial de un mes a otro, podemos observar como sus métricas han variado. Pese a que en el Ayuntamiento de Cartagena pueda parecer que han reducido a la mitad con el análisis de LCP, como digo, estas métricas hay que tomarlas como referencia, no como un dato objetivo. De hecho, en el caso de que tu hagas un análisis con cualquiera de estas dos webs, seleccionando exactamente la misma configuración (te basta con darle al botón "*Re-Run Test*") verás que te salen unas métricas distintas, incluso aunque no se haya hecho configuración alguna ni en web ni en servidor para mejorar o empeorar la velocidad. Esta misma prueba la puedes hacer con un periódico o cualquier tipo de web. La velocidad de una página, especialmente las métricas que dependen del TTFB y de todo el entrado end-to-end (DNS lookup, conexión TCP/TLS, latencia de red, respuesta inicial del servidor...), es algo que varía, no es estático en el tiempo. Aunque no toques la web. Esto quiere decir que nos tenemos que esforzar en mejorar el promedio, no un análisis puntual, ni nos vale un análisis puntual como KPI efectivo. ¿No lo estás entendiendo? Si quieres aprender a aplicar todo esto y mucho más, accede a mi formación: [¡Aprende SEO de verdad!](/master-seo-tecnico/) ## Causas de un TTFB lento Para Diagnosticar qué te ralentiza el TTFB, lo lógico y lo rápido sería decir directamente que se debe al servidor o hosting donde está alojado. No obstante, la solución no siempre es pagar más, una página mal optimizada te puede salir cara en varios sentidos, y uno de estos sentidos es que tengas que sobrepagar hosting. Recuerdo un aula virtual que para funcionar de forma eficiente (y aun así daba problemas) pagaban 2000€ mensuales de hosting, la realidad es que hicieron una web monolítica donde los alumnos subían archivos en el mismo sitio donde veían sus propios vídeos. Si estás en el punto en el que no sabes decidirte por un hosting, te digo aquí [que tienes que tener en cuenta a la hora de elegir un hosting](https://carlossanchezdonate.com/articulo/criterios-para-elegir-un-hosting/) y si te conviene VPS, hosting compartido, dedicado o Cloud. Te comento posibles causas: ### Red y cliente La pongo la primera porque nunca hay que pasarla por alto, tanto del negocio como de los puntos geográficos implicados. Si tienes un ecommerce, a menos que hagas una ampliación de hardware, es posible que en momentos pico de tráfico inusual de clientes, tu web se vea más saturada y la respuesta del servidor sea más lenta. Es por esto que hay que prever fechas como Black Friday, reyes, campañas virales y grandes ofertas. #### Estacionalidad y puntos geográficos implicados Se habla menos de esta causa porque es más marginal y suele afectar menos, pero es también una causa real de posibles bajadas de tráfico. Tanto por el ancho de banda que pueda haber donde tu servidor, como especialmente por parte de los clientes. Incidencias que suelen haber que pueden afectar tu TTFB: ##### Mucha gente en el mismo lugar o gente aislada. Es decir, poca cobertura: Si tu web es muy visitada en un congreso, o imaginémonos que es muy visitada en un festival. Además de toda la gente que se pueda querer meter a la vez, el internet con datos será peor donde hay aglomeraciones de gente, porque habrá más cantidad de personas por antena. Es por esto que cuando estás en un sitio con mucha gente tu cobertura y tu internet va peor. Si la gente intenta acceder a tu web en estas condiciones el TTFB experimentado será peor y te puede afectar a las estadísticas de LCP y por tanto al Core Web Vitals. Por lo tanto, si sabes que tu web va a ser visitada por mucha gente en estas condiciones, dependiendo del objetivo, puedes preparar una APP para estas circunstancias o una landing específica si se trata de publicidad con un QR. Ten en cuenta que no es un factor que se pueda controlar. En verano, dependiendo del sector de población, tiende a estar en lugares más masificados o por el contrario con menor cobertura por estar aislados, esto puede afectar a tu TTFB. Ten en cuenta que tanto ciertos hoteles, zonas rurales, festivales, zonas masificadas que no estén preparadas pueden hacer que se aumente la latencia y por tanto el TTFB aunque tu web siga igual que siempre. ##### El verano es caluroso - Los CPDs (centros de datos) grandes o decentes no suelen tener problemas, pero suelen tener que gestionar más costes de refrigeración en verano, algún proveedor puede tener que llegar a hacer throttling de recursos (limitar acceso) para evitar sobrecalentamientos. - Si eso puede pasar con un CPD, no hablemos con casas y comunidades respecto a sus routers, switches, equipos de red y su mantenimiento, especialmente si están en lugares poco ventilados, donde les de el sol, o húmedos Realmente este último punto, al igual que con las aglomeraciones, no sería un fallo del TTFB real del servidor, pero en las estadísticas de google afectarían por el promedio de 28 días, ya que realmente accedería a tu web gente con menos latencia y por tanto las estadísticas de TTFB serían mas lentas. ##### Lejanía entre puntos Cuanto más lejos esté el cliente del centro de datos, mayor será el tiempo de ida y vuelta (RTT). Si tienes tu hosting en madrid sin un CDN con distintos POPs o edge nodes probablemente el TTFB de un usuario en Valencia será mucho menor que el de un usuario en Sidney. Es importante adecuar la página al potencial público objetivo. #### Redes en general A todo lo mencionado debemos añadir que la calidad de los operadores no es la misma, que no todos ofrecen la misma calidad de conexión, la cantidad de usuarios que pueden usar VPNs para ver tu contenido, si la web se suele ver desde redes corporativas. ¿Cuál es el público objetivo de tu web y cómo suele navegar? ### Mala optimización de la web Una de las opciones más habituales es una mala configuración de la web. Loops, bucles, llamadas a la DDBB excesivamente lentas que pueden hacer que el contenido que se arroje sea excesivamente lento, etc. Aquí la posibilidad de causas son tan amplias y variadas como la cantidad de webs que pueden haber en el mundo y aunque yo te pueda dar consejos y asesorar de forma gratuita si lo preguntas en un comentario de mi Linkedin o en mi Discord, la realidad es que si este es el fallo, suele dedicar mucho más tiempo del que se le puede dedicar a una consulta gratuita. Si lo necesitas, puedes reservarme una [consultoría para diagnosticarlo](https://carlossanchezdonate.com/servicios/consultoria/) (ya se vería el precio de la solución) o buscar a cualquier [alumno de mi máster de SEO Técnico](https://carlossanchezdonate.com/master-seo-tecnico/) que 100% sabe solucionar el problema. También tienes la opción de hacerlo y aprender a hacerlo en cualquier web, con clases muy detalladas y tutorías personalizadas. Si tu web ha tenido a lo largo de su vida muchos plugins, es posible que haya mucha morralla en la DDBB. Si se utilizan muchos constructores, es posible que la web no sea lo más limpia del mundo. ### Problema del servidor Realmente puede ser que el servidor en el que estés sea insuficiente para tu web por óptima que esté o por el tráfico que reciba. En este caso puede ser por la [configuración del servidor](https://carlossanchezdonate.com/seo-avanzado/servidores/), que te digo lo mismo del máster, o por el hardware mismo. No obstante hay un truco que puedes hacer para diagnosticar fácil si es el servidor o la web. - Haz la prueba de ttfb con el robots.txt. o un .txt que quieras personalizado. Si un archivo estático y simple como un .txt te da un ttfb bajo, es el servidor. No suele depender de la programación de la web (salvo cuando se ha hecho por medio de un plugin y no se ve el archivo en el gestor de archivos). - Puedes probarlo el mismo análisis con una imagen estática. - En un subdominio, con el .htaccess limpio, genera una página index.php con un `echo 'Hola';` o algo simple, si este también va lento, no es tu web, es el servidor. Un error habitual en el problema del servidor, antes de decidir cambiarte de hosting, es la capacidad de almacenamiento. Comprueba que tienes más de un 20~30% de espacio libre en el disco duro de tu servidor. Si no es el caso, ya sabes donde puede estar en el problema. Eso se suele deber a la cantidad de copias de seguridad sin control. Si lo del disco duro no es el caso, pidele soporte a tu hosting contandole las pruebas que has realizado, demostrando que el problema es del servidor. Si te dan evasivas, si puedes considerar cambiar de hosting. A veces puede incluso ser un cloud en AWS, Azure o Google Cloud mal configurados. Matar moscas a cañonazos no implica que por más poder se tenga mayor eficacia, especialmente si no se configura bien. ## Solución de problemas Esto le afecta más a webs que tengan [la renderización desde el servidor](https://carlossanchezdonate.com/articulo/renderizacion-de-javascript-en-el-seo/#server-side-rendering-renderizado-desde-el-lado-del-servidor), y además de tener un código mejor optimizado, se puede aliviar con: - Un upgrade temporal de hardware (para luego no seguir pagando en exceso ya que es un momento pico). - [Un buen CDN.](https://carlossanchezdonate.com/articulo/cdn/) - [Limitando el rastreo a cierta velocidad de rastreo o a determinados user-agents.](https://carlossanchezdonate.com/articulo/bloquear-user-agents/) - [Ajustando el caché desde el servidor](https://carlossanchezdonate.com/articulo/cache-en-el-seo/#cache-del-servidor). - [Protocolo HTTP.](https://carlossanchezdonate.com/curiosidades/version-protocolo-http/) - Compresión de los elementos (brotli, gzip...) - Versión de PHP (o lenguaje de servidor que se use) Memory Limit - Max_childern/max_request - autoloaders pesados - Uso de FPM, FastCGI o CGI (lo mejor es FPM) Llamadas a APIs Externas Si se usa Apache debería tener Nginx como proxy para quitarse la mayor parte de la carga, por ejemplo para servir los recursos estáticos. Keepalive [Limita las directivas del .htaccess](https://carlossanchezdonate.com/articulo/redirecciones-htaccess-wpo/) si las puedes poner en la configuración del servidor (especialmente si tu servidor no es litespeed). ## Conclusión EL TTFB te puede afectar a la experiencia del usuario, puede afectar directamente al LCP que es una de las medidas del Core Web Vitals y por tanto a SEO, puede afectar la experiencia del usuario y aumentarte incluso el porcentaje de rebote, incluso en caso de ser una web grande, puede afectarte al propio Crawl Budget. ¿Y tú? ¿Tienes un buen TTFB en tu público promedio? Si te gusta este artículo, me ayudarías un montón compartiendo mi contenido: Compartir: [![Compartir en LinkedIn](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/linkedin.svg)](https://www.linkedin.com/cws/share/?url=https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/) [![Compartir en Twitter](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/tw.svg)](https://twitter.com/intent/tweet?url=https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/) [![Compartir en Facebook](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/facebook.svg)](https://www.facebook.com/sharer/sharer.php?u=https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/) [![Compartir en WhatsApp](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/whatsapp.svg)](whatsapp://send?text=https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/) [![Compartir en Telegram](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/tlg.svg)](https://telegram.me/share/url?url=https://carlossanchezdonate.com/articulo/ttfb-utilidad-diagnostico-y-optimizacion/) No se te da mal el SEO Técnico Te falta mi máster**. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB [¡Accede al Máster de SEO Técnico!](/master-seo-tecnico/) Tal vez te interesen otros artículos: [Artículos de SEO](/seo-avanzado/) [SXO como especialidad](https://carlossanchezdonate.com/articulo/sxo-especialidad-seo/) [Sitemaps](https://carlossanchezdonate.com/articulo/sitemaps/) [Curación de enlaces en el SEO](https://carlossanchezdonate.com/articulo/curacion-de-enlaces-en-el-seo/) [Texto alternativo para imágenes](https://carlossanchezdonate.com/articulo/alt-imagenes/) [Rich Snippets con HTML](https://carlossanchezdonate.com/articulo/rich-snippets-sin-datos-estructurados/)