Cómo reducir el TTFB (Time to First Byte)

Reducir el TTFB consiste en acortar el tiempo que pasa desde que el navegador pide una página hasta que recibe el primer byte de la respuesta. En la práctica eso significa tres cosas: que el servidor y la aplicación generen el HTML más rápido, que se sirva HTML en caché para que la mayoría de peticiones se ahorren ese trabajo y que la respuesta salga desde más cerca de tus visitantes. Esta guía te enseña a averiguar cuál de las tres es tu cuello de botella y qué hacer con cada una.

Qué mide el TTFB

El Time to First Byte no es una sola cosa. Es la suma de varias fases que ocurren antes de que llegue ningún contenido:

1. Redirecciones, si la URL solicitada reenvía primero a otra.
2. Consulta DNS, que convierte tu nombre de dominio en una dirección IP.
3. Establecimiento de la conexión, el handshake TCP más la negociación TLS para HTTPS.
4. Petición y procesamiento en el servidor, el tiempo que tu servidor dedica a construir la respuesta (ejecutar PHP, consultar la base de datos, renderizar plantillas).
5. El viaje de vuelta del primer byte hasta el navegador.

Por eso dos webs en servidores idénticos pueden tener un TTFB muy distinto: una puede estar cerca de sus visitantes y servir páginas en caché, y la otra estar en otro continente y generar cada petición desde cero.

El TTFB no es una de las tres Core Web Vitals, pero está por debajo de todas ellas. Nada se puede pintar antes de que llegue el primer byte, así que un TTFB lento retrasa directamente el Largest Contentful Paint. Si tu LCP es malo, el TTFB es una de las primeras cosas que debes revisar. La guía sobre las Core Web Vitals explica cómo se relacionan las métricas.

¿Qué es un buen TTFB?

La guía de web.dev sobre el TTFB (en inglés) recomienda que la mayoría de webs apunten a un TTFB de 0,8 segundos o menos, medido en el percentil 75 de las cargas reales. Los valores por encima de 1,8 segundos se consideran malos.

Conviene tener en cuenta dos cosas. La primera: estas cifras describen a usuarios reales en redes reales, incluidas conexiones móviles lentas lejos de tu servidor. Una prueba desde tu oficina, al lado del centro de datos, saldrá mucho mejor que lo que vive un visitante en otro continente. La segunda: 0,8 s es una referencia orientativa, no un aprobado estricto. Las webs que se renderizan por completo en el cliente pueden permitirse algo más; las renderizadas en el servidor, que incluyen la mayoría de instalaciones de WordPress y de tiendas online, ganan si quedan bastante por debajo.

Mídelo y encuentra la fase lenta

Antes de cambiar nada, mide en qué se va el tiempo. Una comprobación rápida desde la línea de comandos:

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Cada valor es acumulado y está en segundos. Resta para obtener las fases:

• connect - dns es el viaje de ida y vuelta por la red hasta el servidor.
• tls - connect es el handshake de HTTPS.
• ttfb - tls es, aproximadamente, el tiempo de procesamiento del servidor más un viaje de ida y vuelta.

Ejecútalo varias veces, porque la primera petición suele pagar una caché fría o una consulta DNS nueva. Si ttfb - tls sigue siendo alto (por ejemplo, varios cientos de milisegundos o más) mientras las fases de red son pequeñas, el cuello de botella es tu servidor. Si las fases de red son grandes, el problema es la distancia y el coste de las conexiones.

Para obtener cifras de usuarios reales, prueba la página en corewebvitals.page y mira los datos de campo de usuarios de Chrome, disponibles cuando tu web tiene tráfico suficiente. En Chrome DevTools, la pestaña Network muestra el desglose de tiempos de cada petición: "Waiting for server response" es la parte del TTFB que corresponde al servidor. La guía sobre cómo medir la velocidad de una web explica cómo combinar estas fuentes sin engañarte.

Acelera el servidor y la aplicación

Si lo que domina es el tiempo de procesamiento, la solución está en el origen. Ve de lo más barato a lo más laborioso:

Actualiza el entorno de ejecución

Las versiones más nuevas de PHP, Node.js o Python suelen hacer el mismo trabajo bastante más rápido. Comprueba qué versión usa tu hosting y si tu CMS y tus plugins admiten una más reciente.

Añade una caché de objetos

WordPress, WooCommerce, Shopware, Magento y Drupal lanzan muchas consultas repetidas a la base de datos. Una caché de objetos persistente como Redis o Memcached guarda esos resultados en memoria entre peticiones. Muchos hostings gestionados la ofrecen como una opción que se activa sin más.

Encuentra las consultas y los plugins lentos

Un solo plugin que lanza una consulta costosa en cada carga de página puede dominar el TTFB. Usa un profiler o un monitor de consultas en una copia de staging, desactiva los sospechosos de uno en uno y vuelve a medir. En las tiendas, los filtros por facetas, los widgets de productos relacionados y las consultas de stock en tiempo real son culpables habituales.

Revisa los recursos del servidor

Si el TTFB va bien por la noche y mal en las horas punta, el servidor se está quedando sin CPU, memoria o workers de PHP. Aquí puede ser acertado ampliar recursos o pasar a un plan de hosting mejor, y ninguna optimización del front-end lo va a arreglar.

Cachea páginas HTML completas

La mayoría de peticiones a una web típica son de páginas que se ven igual para cualquier visitante anónimo. Generarlas desde cero cada vez es trabajo tirado. Una caché de página completa guarda el HTML terminado y lo devuelve sin tocar PHP ni la base de datos, y suele ser lo que más efecto tiene por sí solo sobre el TTFB.

Puedes cachear en distintas capas:

• En la aplicación, con un plugin de caché o la caché HTTP integrada (Shopware y Drupal traen una). La documentación de caché de WordPress (en inglés) da un buen resumen de las opciones.
• En el servidor, con un proxy inverso como Varnish o la caché de Nginx.
• En el edge, en un CDN o una red edge, para que las páginas en caché se sirvan desde una ubicación cercana al visitante.

Elijas la capa que elijas, sé estricto con lo que no se debe cachear: carritos, checkout, páginas de cuenta, sesiones iniciadas y todo lo personalizado. Esas peticiones deben saltarse la caché e ir siempre al origen. Si tus páginas envían cabeceras Cache-Control coherentes, todas las capas pueden seguirlas.

Comprueba si una página ha salido realmente de la caché mirando las cabeceras de respuesta:

curl -sI https://example.com/ | grep -i -E "cache|age"

Una caché que existe pero casi nunca acierta sirve de poco. Las tasas de acierto bajas suelen deberse a cookies o parámetros de URL que hacen que cada petición parezca única, o a tiempos de vida de caché demasiado cortos.

Acorta la distancia hasta tus visitantes

Cada ida y vuelta entre el navegador y el servidor cuesta tiempo, y una conexión HTTPS nueva necesita varias antes de que pueda llegar el primer byte. Si tu servidor está en Fráncfort y el visitante en Sídney, la física por sí sola añade un retraso apreciable a cada uno de esos viajes, por rápido que sea el servidor.

Hay dos formas de acortar esa distancia:

• Aloja la web cerca de tu público. Si casi todos tus visitantes están en un país, un servidor en ese país o cerca de él es lo más sencillo.
• Sirve desde una red edge. Un CDN termina las conexiones en una ubicación cercana al visitante y, cuando la página está en caché allí, responde sin contactar con tu origen. La guía ¿Qué es un CDN? explica qué puede arreglar y qué no.

Una red edge también ayuda un poco a las peticiones sin caché, porque el handshake TLS se hace cerca y el edge puede reutilizar una conexión ya abierta con el origen. Pero la gran ganancia viene de los cache hits.

Elimina redirecciones y costes de conexión

Los detalles pequeños se acumulan, sobre todo en redes móviles:

• Evita las cadenas de redirecciones. Pasar de http://example.com a https://example.com, luego a https://www.example.com y después a https://www.example.com/en/ son tres viajes de ida y vuelta extra antes de que ocurra nada útil. Enlaza directamente a la URL final y deja como mucho una redirección.
• Usa HTTP/2 o HTTP/3 y TLS 1.3. Reducen el número de viajes necesarios para establecer la conexión y permiten al navegador descargar muchos recursos por una sola conexión.
• Usa un proveedor de DNS rápido. El DNS forma parte del TTFB para quien visita tu web por primera vez. Los proveedores basados en anycast o GeoDNS responden desde ubicaciones cercanas.
• Activa la compresión. Brotli o gzip para el HTML apenas cambian el primer byte, pero acortan el resto de la descarga que viene después.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting actual y actúa sobre las partes del TTFB que dependen de la red y de la caché. Mantienes tu proveedor; apuntas los servidores de nombres de tu dominio a fast.site y, tras la verificación, tu tráfico pasa por su red edge.

Fast Edge Cache™ guarda en el edge las páginas que se pueden cachear. En un cache HIT la respuesta sale directamente del edge sin contactar con tu origen; en un MISS la página se pide una vez y se almacena. La caducidad sigue las cabeceras Cache-Control de tu origen o tus propias reglas, y un cache warmer mantiene precargadas las páginas importantes. Los carritos, el checkout y las sesiones iniciadas se saltan la caché, algo que la cabecera fs-cache indica como BYPASS. Puedes comprobar cualquier URL como se explica en cómo comprobar la caché, y la documentación de caché explica las reglas.

GeoDNS dirige a los visitantes al edge disponible más cercano, con regiones en Norteamérica, Europa, Asia-Pacífico y Sudamérica según tu plan (consulta las regiones). Los certificados se emiten y se renuevan automáticamente.

fast.site no hace más rápida una consulta lenta a la base de datos, así que los ajustes en el origen siguen importando para las páginas sin caché. La analítica del panel muestra el TTFB y la tasa de aciertos de caché, para que midas el efecto en tu propia web. Puedes hacerlo, por ejemplo, con una prueba gratuita de 7 días.

Preguntas frecuentes

¿El TTFB afecta al SEO?

El TTFB no es una de las Core Web Vitals que Google usa como señal de experiencia de página. Sin embargo, retrasa el Largest Contentful Paint, que sí lo es. Mejorar el TTFB sirve sobre todo para tener un mejor LCP y una web que se siente más rápida, no para conseguir un impulso directo en el ranking.

¿Por qué el TTFB solo es alto en la primera visita?

La primera petición suele incluir una consulta DNS, un handshake TLS nuevo y una caché fría en el servidor o en el edge. Las siguientes reutilizan conexiones y encuentran la caché caliente. Si el TTFB de la primera visita te importa (y en la mayoría de landing pages importa), revisa la velocidad del DNS, las redirecciones y el precalentamiento de la caché.

¿Por qué el TTFB sale bien en mi prueba pero mal para los usuarios reales?

Tu propia prueba suele hacerse con una conexión rápida, cerca del servidor y con la caché caliente. Los datos de campo, como los que muestran corewebvitals.page o Search Console, vienen de usuarios reales de Chrome en todo tipo de redes y ubicaciones, medidos en el percentil 75. La diferencia suele apuntar a la distancia o a páginas que rara vez están en caché.

¿Un CDN arregla un TTFB lento?

Arregla la parte que se debe a la distancia y a generar las mismas páginas una y otra vez, siempre que tus páginas se puedan cachear de verdad. No acelera las peticiones que tienen que llegar al origen, como el checkout o las páginas con sesión iniciada. Para esas sigue haciendo falta afinar el servidor y la aplicación.