Cuanto tarda tu web desde que tu usuario hace click hasta que le llega informació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, incide directamente sobre el LCP, que si que lo es. Por lo que a menos que esté muy bien optimizado el resto de cosas un TTFB suele producir un LCP lento.
Es importante distinguirlo del LCP, aunque estén relacionados, no es 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: 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 de una página web. Una métrica muy a tener en cuenta para comprobar el rendimiento de una página web.
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.
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.
Banner promocionado:
Cuando utilizamos el 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"
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), y tanto la información de laboratorio, como origen o la URL en concreto nos puede dar pistas o información también acerca del TTFB.
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:
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.
Como he comentado, los resultados incluso con la misma configuración te pueden variar.
Resultados test Geohat:
Resultados Ayto Cartagena:
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 es 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.
Para Diagnosticar que 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 caro 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 y si te conviene VPS, hosting compartido, dedicado o Cloud.
Te comento posibles causas:
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.
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:
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.
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.
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.
A todo lo mencuonado 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.
¿Cual es el público objetivo de tu web y cómo suele navegar?
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.
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 (ya se vería el precio de la solución) o buscar a cualquier alumno de mi máster de SEO Técnico 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.
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, 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.
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.
Esto le afecta más a webs que tengan la renderización desde el servidor, y además de tener un código mejor optimizado, se puede aliviar con:
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?
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!