Time to first byte (TTFB): qué es un buen valor y cómo reducirlo

Time to first byte (TTFB) es el tiempo desde el inicio de la navegación hasta el primer byte de la respuesta HTML. Web.dev de Google considera bueno un valor de 0,8 segundos o menos y malo uno superior a 1,8 segundos, medido en el percentil 75 de las visitas reales (web.dev, última actualización en noviembre de 2025). El TTFB no es una Core Web Vital, pero todas las métricas posteriores, incluidas First Contentful Paint y Largest Contentful Paint, empiezan después de él. En los móviles es también donde se acumulan las redirecciones, el DNS, el TLS y un servidor lento, porque cada uno de esos pasos cuesta al menos un viaje por la red móvil.

Qué es el time to first byte

El TTFB es la suma de todos los pasos anteriores a la llegada del primer byte del documento, incluidos las redirecciones, el DNS y el TLS. Según web.dev, incluye:

• el tiempo de redirección;
• el arranque del service worker, si el sitio tiene uno;
• la búsqueda DNS;
• la conexión y la negociación TLS;
• la petición en sí, hasta el primer byte de la respuesta.

Por eso un servidor rápido puede mostrar un TTFB lento. Una visita que empieza en http://example.com, redirige a https://example.com y luego a https://www.example.com ha pagado dos redirecciones y tres conexiones antes de que el servidor de la página final haya hecho nada.

El TTFB tampoco es lo mismo que el «tiempo de respuesta del servidor» de los informes antiguos de Lighthouse. Esa auditoría medía solo la espera del documento principal y excluía las búsquedas DNS y las redirecciones, así que es una parte del TTFB (Chrome for Developers).

Qué es un buen TTFB

Un buen TTFB es de 0,8 segundos o menos, y web.dev llama a sus umbrales «una guía aproximada», no un requisito. Estos son los rangos a noviembre de 2025, junto con la cifra más estricta de Lighthouse:

Las dos cifras miden cosas distintas. Los 600 ms de Lighthouse cubren el tiempo de respuesta propio del servidor, mientras que la guía de 0,8 s cubre el TTFB completo, así que una misma página puede aprobar una y suspender la otra. Ambas son umbrales de diseño fijados por Google.

¿Con qué frecuencia se obtiene una buena puntuación en móviles? En el Web Almanac 2025 de HTTP Archive, basado en datos de julio de 2025, el 44% de los sitios móviles tenía un buen TTFB, frente al 55% en escritorio. En móvil, el 40% necesitaba mejorar y el 17% era malo (Web Almanac 2025, Rendimiento).

Por qué el TTFB es más alto en móviles

El TTFB es más alto en móviles porque cada paso antes del primer byte es un viaje de ida y vuelta, y un viaje de ida y vuelta en una conexión móvil tarda más que en una cableada. En una primera visita por HTTPS con una conexión fría, la secuencia es:

1. Búsqueda DNS, para encontrar la dirección del servidor.
2. Handshake TCP: un viaje de ida y vuelta al servidor.
3. Handshake TLS: otro viaje de ida y vuelta con TLS 1.3, que la RFC 8446 describe como el «handshake de 1-RTT».
4. La petición HTTP y el primer byte de la respuesta: un viaje de ida y vuelta más el tiempo que tu servidor necesita.

Así que la red por sí sola cuesta tres viajes de ida y vuelta al servidor más la búsqueda DNS, antes del trabajo propio del servidor. La tabla siguiente es aritmética con dos tiempos de ida y vuelta (RTT) elegidos como ejemplo, no mediciones de ninguna red:

Con el RTT más alto, un servidor que responde en 400 ms ya rompe la guía de 0,8 s una vez sumado el DNS. El servidor no hizo nada mal; la preparación de la conexión se llevó más de la mitad del presupuesto.

Dos cosas reducen esta sobrecarga. Reutiliza la conexión: un visitante que vuelve y sigue conectado se salta los pasos 1 a 3. Y usa un protocolo más nuevo: HTTP/3 funciona sobre QUIC, cuyo handshake «combina la negociación de los parámetros criptográficos y de transporte» (RFC 9000, mayo de 2021), así que la preparación necesita menos viajes de ida y vuelta que TCP seguido de TLS. Web.dev señala que los CDN sirven contenido con protocolos modernos como HTTP/2 o HTTP/3 (web.dev).

Otra causa específica de los móviles: un sitio móvil separado. El consejo de Lighthouse sobre redirecciones dice que, para los usuarios de móvil, conviene considerar el diseño responsive en lugar de redirigirlos a una página móvil (Chrome for Developers). El enfoque responsive se explica en cómo hacer un sitio web apto para móviles.

Cómo medir el TTFB

Mide el TTFB dos veces: en laboratorio, para ver dónde se va el tiempo, y en campo, para ver qué obtienen los teléfonos reales. Las dos cifras pueden diferir: una ejecución de laboratorio es una carga en una máquina, y el valor de campo es el percentil 75 de las visitas reales.

En DevTools (laboratorio), abre el panel Red, recarga, selecciona la primera petición (el documento) y abre la pestaña Timing. Las fases se llaman Queueing, Stalled, DNS Lookup, Initial connection, Request sent y Waiting (TTFB), y «Waiting (TTFB)» es un viaje de ida y vuelta más el tiempo que el servidor tarda en preparar la respuesta (referencia de Chrome DevTools). Si la barra de Initial connection es larga y Waiting es corta, la solución está en la preparación de la conexión, no en la aplicación.

En la página (campo), la biblioteca web-vitals informa del TTFB y, en su versión de atribución, lo divide en las mismas fases. Su documentación (README de web-vitals) las nombra waitingDuration (redirecciones y trabajo del navegador antes de la petición), cacheDuration (comprobación de caché y tiempo del service worker), dnsDuration, connectionDuration y requestDuration (tiempo de red y procesamiento en el servidor):

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // Envíalo a tu endpoint de analítica; aquí solo lo mostramos en la consola.
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

Por dispositivo (campo, sin código), la API de Chrome UX Report acepta un formFactor de PHONE, TABLET o DESKTOP y devuelve el percentil 75 de experimental_time_to_first_byte (una métrica experimental de la API) (documentación de la API de CrUX). Los datos son una media móvil de 28 días. Es la forma más rápida de ver si el TTFB en el teléfono es peor que en escritorio. Cómo ejecutar el conjunto más amplio de pruebas de velocidad está en la guía de prueba de velocidad en móviles, y cómo informa Lighthouse del mismo problema está en la guía de auditoría móvil con Lighthouse.

En el servidor, añade una cabecera Server-Timing para ver qué paso del backend es lento. Chrome 65, Firefox 61 y Safari 16.4 la soportan (MDN browser-compat-data 8.1.7, octubre de 2026):

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

Los valores aparecen después en la pestaña Timing del panel Red y en navigationEntry.serverTiming del objeto de atribución de arriba.

Cómo reducir el TTFB

Empieza por la fase más grande de tu desglose, porque cada solución elimina solo su propia fase. Esta tabla relaciona lo que ves con lo que debes cambiar:

Las soluciones siguientes siguen la guía de web.dev para optimizar el TTFB (web.dev, actualizada en noviembre de 2025).

1. Elimina las redirecciones. Web.dev te indica que quites las redirecciones 301 y 302 del mismo origen, como un https:// que falta o un desajuste en la barra final, y que a los anunciantes y boletines les des la URL final. HSTS indica al navegador que use https:// directamente en lugar de pedir primero http://.
2. Pon un CDN delante. Un CDN responde desde un servidor de borde cercano al visitante, lo que acorta cada viaje de ida y vuelta de la tabla anterior. Según web.dev, normalmente también aporta HTTP/3, TLS 1.3 y compresión.
3. Cachea el HTML. Una página igual para todos los visitantes puede guardarse en caché con Cache-Control y servirse sin tocar la aplicación. Web.dev señala que tiempos de caché cortos ya ayudan a los sitios muy visitados. Añade un parámetro en la URL para saltarte la caché mientras diagnosticas.
4. Reduce el trabajo del servidor. La guía de Lighthouse recomienda optimizar la lógica de la aplicación y las consultas a la base de datos, mejorar el hardware si hace falta, y usar un CDN para los documentos que pueden guardarse en caché en el borde. Usa Server-Timing para encontrar primero el paso lento.
5. Comprime el texto. El insight de Lighthouse marca un documento principal enviado sin compresión. El navegador anuncia lo que acepta en Accept-Encoding y el servidor responde con Content-Encoding.
6. Transmite el HTML en streaming. Web.dev aconseja mantener el flujo de la respuesta, con renderizado en servidor por streaming o renderizado estático cuando sea posible, para que los primeros bytes salgan pronto. El vaciado temprano también se mide como responseStart, así que el TTFB puede parecer mejor de lo que se siente la página; revisa también First Contentful Paint.
7. Envía 103 Early Hints. Si el servidor necesita tiempo para generar la página, puede enviar primero una respuesta 103 con cabeceras Link, para que el navegador empiece un preconnect o un preload mientras espera.

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

Early Hints funciona con HTTP/2 o superior en la mayoría de navegadores, y solo se procesa la primera respuesta 103 (MDN, junio de 2026). Tiene soporte desde Chrome 103, Firefox 120 y Safari 17. Una respuesta 103 cuenta como los primeros bytes para el TTFB, y Chrome ha cambiado qué marca de tiempo informa responseStart (a la respuesta final en Chrome 115, de nuevo a los primeros bytes en Chrome 133), así que compara el TTFB entre herramientas con cuidado (web.dev).

Si el sitio tiene un service worker, servir el esqueleto desde su caché también acorta el TTFB en las visitas repetidas. Web.dev sugiere stale-while-revalidate para los recursos que cambian poco y red primero para el HTML personalizado.

Sitios estáticos y sitios con CMS

Un sitio estático ya tiene el mejor caso: el HTML existe antes de la petición, así que el TTFB es sobre todo la preparación de la conexión, y un CDN es la solución principal. Un CMS construye la página al recibir la petición, así que la mayor ganancia está en la caché de página completa. Para WordPress, la documentación de Lighthouse enumera un tema ligero, caché de página completa y menos plugins; para Drupal, caché de página, OPcache de PHP y Redis o Memcached; para Magento, Varnish (Chrome for Developers, última actualización en 2019, antes de Lighthouse 13).

Una URL AMP separada también añade una versión de la página que hay que mantener coherente con la canónica; si todavía la necesitas se explica en AMP en 2026.

Comprueba la cadena de redirecciones en una página de tamaño móvil

Las redirecciones son la única causa de TTFB que puedes ver sin cronómetro: un teléfono puede ser enviado a un sitio distinto que un ordenador. Mobile View Extension recarga la pestaña con el user agent, el tamaño de pantalla y la relación de píxeles de un teléfono, así que puedes comprobar en qué URL acabas y que la página móvil carga como la versión real. No mide el TTFB ni ninguna métrica de velocidad, y se ejecuta con la conexión y el hardware de tu ordenador, así que para tiempos en teléfonos reales usa las herramientas de campo de arriba.

Preguntas frecuentes

¿Qué es un buen TTFB?

Un buen TTFB es de 0,8 segundos o menos en el percentil 75, y más de 1,8 segundos es malo, según web.dev (noviembre de 2025). Son guías aproximadas, y el TTFB no forma parte de las Core Web Vitals.

¿Es el TTFB una Core Web Vital?

No. Las Core Web Vitals son Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift, y web.dev indica que el TTFB no es una de ellas. Importa porque un TTFB alto retrasa First Contentful Paint y Largest Contentful Paint.

¿Por qué mi TTFB es distinto en Lighthouse y en los datos de campo?

Lighthouse hace una carga en una máquina con limitación de red, mientras que los datos de campo cubren visitas reales en redes y cachés reales. Fíate del valor de campo y usa la ejecución de laboratorio para encontrar la fase lenta.

¿Afecta el TTFB al SEO?

Web.dev dice que el TTFB no es una Core Web Vital, pero va antes de First Contentful Paint, así que un TTFB lento retrasa las métricas que vienen después, sobre todo Largest Contentful Paint. Arregla primero esas métricas y usa el TTFB para averiguar por qué van lentas.