Guías

El TTFB, o Time To First Byte, es el tiempo que transcurre entre el momento en que tu navegador solicita una página a un servidor y el momento en que regresa el primer byte de la respuesta. Se mide en milisegundos y abarca todo lo que debe ocurrir antes de que el navegador pueda siquiera empezar a leer la página: resolver el dominio, abrir la conexión y - la parte que suele dominar - el servidor haciendo su trabajo y enviando ese primer byte.

Importa porque el TTFB es el impuesto que se paga en cada solicitud antes de que pueda ocurrir nada visible. Un navegador no puede renderizar un solo píxel hasta que empiecen a llegar los bytes, así que un TTFB lento retrasa toda la página en esa misma medida, por muy bien optimizados que estén tus imágenes, tu CSS y tu JavaScript. Es el suelo bajo tu velocidad de carga.

Qué mide realmente el TTFB

Bajo el capó, el TTFB es la suma de esperas más pequeñas: cualquier redirección, la resolución DNS que convierte tu dominio en una dirección IP, la conexión TCP y el handshake TLS que la protege, el tiempo que la solicitud pasa viajando hacia el servidor y, por último, el tiempo de procesamiento del servidor hasta que se escribe de vuelta el primer byte. En la mayoría de los sitios, esa última pieza - cuánto tarda el servidor en construir la respuesta - es la mayor y la más fácil de arreglar.

De forma crucial, el TTFB es una medida de back-end y de red, no de front-end. Si tu TTFB es alto, el problema está en el servidor, en el alojamiento o en la ruta de red, no en tu código de React o Vue. Ese es un diagnóstico útil: te dice que mires tu alojamiento, tu caché y tu base de datos en lugar del tamaño de tu bundle.

Qué se considera un buen TTFB

La recomendación de Google, publicada en web.dev, es que un buen TTFB está aproximadamente por debajo de 800 milisegundos en la mayoría de los sitios, y todo lo que supere los 1.8 s se considera deficiente. Son umbrales de campo - medidos en visitas reales - así que ya tienen en cuenta redes y dispositivos reales en lugar de una prueba de laboratorio sobre hardware rápido.

• Alojamiento lento o sobrecargado - un servidor compartido bajo la presión del tráfico de otros sitios
• Páginas dinámicas sin caché regeneradas desde cero en cada solicitud
• Consultas pesadas a la base de datos o código back-end lento que inflan el tiempo de procesamiento del servidor
• Sin CDN, de modo que cada visitante se conecta a un único servidor de origen distante
• Cadenas de redirección que añaden viajes de ida y vuelta adicionales antes de que empiece la respuesta real
• Handshakes TLS lentos o un servidor situado lejos de la mayor parte de tu audiencia

El TTFB no es en sí mismo uno de los tres Core Web Vitals, pero alimenta directamente el Largest Contentful Paint. El LCP nunca puede ser más rápido que el TTFB que lo precede, porque el contenido principal no puede aparecer hasta que la respuesta haya comenzado. Mejorar un TTFB lento suele mejorar el LCP sin esfuerzo adicional, y por eso el trabajo de rendimiento empieza tan a menudo aquí.

Cómo reducir el TTFB

La mayor palanca del lado del servidor es la caché. Servir una página desde una caché de página completa o desde una caché de borde de un CDN evita el trabajo de regenerarla en cada solicitud, convirtiendo cientos de milisegundos de procesamiento en una respuesta casi instantánea. Más allá de eso, un alojamiento más rápido o menos saturado, un código back-end más ligero y la depuración de consultas lentas a la base de datos reducen todos directamente la parte de procesamiento.

Del lado de la red, un CDN acorta la distancia física entre tu servidor y cada visitante, de modo que la solicitud y la respuesta recorren menos camino. Una gestión moderna de las conexiones - HTTP/2 o HTTP/3, keep-alive y una configuración TLS bien ajustada - reduce la sobrecarga del handshake, y allí donde una página puede pre-renderizarse a archivos estáticos, el alojamiento estático elimina casi por completo el procesamiento del servidor de la ruta crítica.

En resumen

En resumen, el TTFB es el impuesto de respuesta del servidor en cada página que sirves, y fija el techo de lo rápido que puede sentirse el resto de tu sitio. Un alojamiento capaz, una caché agresiva y un CDN son las tres palancas que más lo mueven - por eso arreglar el TTFB suele ser el trabajo de rendimiento con mayor efecto de palanca que puedes hacer antes de tocar una sola línea de código front-end.