Término del glosario

TTFB

Time To First Byte: cuánto tiempo espera el navegador entre solicitar una página y la llegada del primer byte.

Definición

TTFB (Time To First Byte) es el tiempo transcurrido entre el envío de una solicitud por parte del navegador y la llegada del primer byte de la respuesta. Es la métrica principal de rendimiento del lado del servidor en el alojamiento web, porque abarca todo lo que ocurre antes de que empiece a descargarse el HTML: búsqueda de DNS, negociación TLS, tiempo de ida y vuelta de la red, procesamiento del servidor, consultas a la base de datos y cualquier lógica del backend. Un buen TTFB es inferior a 200 ms para páginas en caché e inferior a 500 ms para páginas dinámicas; más de 800 ms es una señal de advertencia de que el servidor, la aplicación o la red son demasiado lentos. El TTFB influye directamente en Core Web Vitals (especialmente en LCP) y es lo que Google mide cuando habla de 'servidores lentos'. Se mide por solicitud utilizando la Navigation Timing API, y lo reportan Chrome DevTools, WebPageTest y la librería JS web-vitals. Es más relevante para páginas dinámicas sin caché; los recursos estáticos servidos desde un nodo de CDN pueden mostrar un TTFB bajo independientemente de la distancia al origen, por lo que esta métrica expone principalmente la lentitud del origen y la aplicación, más que la del transporte de red.

Cómo funciona

El TTFB se mide por solicitud, desde el momento en que el navegador envía el paquete de solicitud hasta el momento en que llega el primer byte de la respuesta. Lo reportan Chrome DevTools, WebPageTest y la librería JS Web Vitals, y es una de las métricas más prácticas que un proveedor de hosting puede mejorar.

Por qué es importante

Un TTFB alto da la sensación de un sitio lento, incluso cuando la página finalmente carga rápido, porque no puede ocurrir nada visible hasta que llega el primer byte. Reducirlo es una de las mejoras de rendimiento con mayor impacto: elegir un host más cercano a tu audiencia, añadir una CDN, cachear las consultas a la base de datos o precalcular la respuesta.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Preguntas frecuentes

¿Qué es un buen TTFB?

Menos de 200 ms para páginas en caché y menos de 500 ms para páginas dinámicas. Más de 800 ms significa que el servidor, la aplicación o la red son demasiado lentos para el visitante.

¿Cómo puedo mejorar el TTFB?

Aloja el sitio más cerca de tu audiencia, añade una CDN, cachea las consultas a la base de datos, precalcula las respuestas con ISR o generación estática, y utiliza HTTP/2 o HTTP/3.

¿Cómo compruebo el TTFB de mi sitio?

Abre Chrome DevTools, ve a la pestaña Network, recarga la página y observa el desglose de tiempos del documento principal: el TTFB es el valor de 'Waiting for server response'. WebPageTest y la librería JS web-vitals ofrecen el mismo dato en varias ejecuciones, lo cual es importante porque una sola solicitud puede resultar engañosa.

¿Añadir una CDN siempre soluciona un TTFB alto?

No. Una CDN acelera el contenido estático o en caché servido desde su nodo, pero si el servidor de origen es lento para generar respuestas dinámicas, la primera solicitud (o cualquier fallo de caché) sigue teniendo que llegar a ese origen, por lo que el TTFB se mantiene alto hasta que se corrija el backend en sí.

¿Qué suele causar picos repentinos de TTFB en un hosting que por lo demás es rápido?

Consultas a la base de datos sin optimizar, exceso de plugins (algo habitual en WordPress), arranques en frío en funciones serverless, problemas de DNS o de renegociación SSL, y vecinos de hosting compartido que consumen CPU. Revisa primero los registros del servidor y las herramientas de APM; un pico que solo aparece bajo carga suele apuntar al código de la base de datos o la aplicación, no a la red.