¿Qué es el Time to First Byte (TTFB) y cómo mejorarlo?

El Time to First Byte (TTFB) mide el tiempo en milisegundos desde que el navegador solicita una página hasta que recibe el primer byte de respuesta del servidor. Un buen TTFB es de 800 milisegundos o menos en el percentil 75. El TTFB no es un Core Web Vital, pero es una métrica de diagnóstico fundamental porque afecta de forma directa tanto al Largest Contentful Paint (LCP) como al First Contentful Paint (FCP).

¿Qué es el Time to First Byte?

El Time to First Byte (TTFB) indica el tiempo transcurrido en milisegundos entre el inicio de la solicitud y la recepción del primer byte de respuesta de una página web. Por eso al TTFB también se le conoce como tiempo de espera. Permite medir la capacidad de respuesta de un servidor web y de la ruta de red entre el usuario y dicho servidor. El TTFB es una métrica base: el tiempo que se suma al TTFB se añade directamente al Largest Contentful Paint y al First Contentful Paint. Cada milisegundo ahorrado en el TTFB es un milisegundo que se ahorra en ambas métricas de renderizado.

El TTFB no es un Core Web Vital

Hay que dejarlo claro: el TTFB no es uno de los tres Core Web Vitals. Los Core Web Vitals son Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Google no utiliza el TTFB de forma directa en sus señales de posicionamiento sobre la experiencia en la página.

Sin embargo, el TTFB se clasifica como una métrica de diagnóstico. Te ayuda a entender por qué el LCP o el FCP son lentos. Según el Web Almanac de 2025, los sitios con un LCP deficiente consumen una media de 2,27 segundos solo en el TTFB. Eso agota casi por completo el umbral de 2,5 segundos del LCP antes incluso de que el navegador empiece a renderizar la página. Corregir el TTFB es, por tanto, una de las intervenciones con mayor impacto en las puntuaciones globales de los Core Web Vitals.

Por qué es importante el Time to First Byte

El Time to First Byte no es un Core Web Vital y es perfectamente posible aprobar los Core Web Vitals suspendiendo la métrica de TTFB. Eso no significa que carezca de importancia. Es una métrica crucial que conviene optimizar: mejorar el TTFB impulsará enormemente la velocidad y la experiencia de la página.

El impacto del TTFB en los visitantes

El Time to First Byte precede a todas las demás métricas de renderizado. Mientras el navegador espera el Time to First Byte, se queda inoperativo y se limita a mostrar una pantalla en blanco. Esto implica que cualquier incremento en el Time to First Byte añade tiempo de pantalla en blanco, mientras que reducirlo se traduce de inmediato en menos tiempo con la pantalla en blanco.

Para lograr esa sensación de carga instantánea, el Time to First Byte debe ser lo más rápido posible.

¿Por qué el TTFB no es un Core Web Vital? El TTFB no mide el renderizado: un TTFB bajo no garantiza una buena experiencia de usuario porque no contempla el tiempo que tarda el navegador en renderizar la página web. Aunque todos los bytes se descarguen a gran velocidad, la página web tardará en mostrarse si el navegador debe ejecutar mucho JavaScript o calcular maquetaciones complejas.

¿Qué es una buena puntuación de TTFB?

Lo recomendable es que el servidor responda a las solicitudes de navegación con la suficiente rapidez para que el percentil 75 de los usuarios disfrute de un FCP dentro del umbral «bueno». Como referencia, la mayoría de los sitios web debe aspirar a un TTFB de 0,8 segundos o menos.

• Un TTFB inferior a 800 milisegundos se considera bueno.
• Un TTFB de entre 800 y 1800 milisegundos necesita mejorar.
• Un TTFB superior a 1800 milisegundos se considera deficiente y debe corregirse de inmediato.

Impacto en el mundo real: el caso de estudio de T-Mobile

T-Mobile apostó con fuerza por reducir su Time to First Byte dentro de una iniciativa más amplia de optimización del rendimiento. Los resultados fueron contundentes: un aumento del 60 % en las conversiones de visita a pedido. Al migrar a páginas renderizadas en el edge y aplicar un almacenamiento agresivo en caché de servidor, T-Mobile redujo de forma drástica el tiempo de espera del primer byte. Esto desencadenó un LCP más rápido, un FCP más rápido y una experiencia de usuario notablemente superior. Este caso práctico demuestra que optimizar el TTFB no es solo un ejercicio técnico: afecta de forma directa a los resultados del negocio.

El TTFB desde la solicitud hasta la respuesta

Del navegador al servidor: la solicitud

El tiempo de solicitud abarca desde que el navegador del usuario emite una petición HTTP hasta que esta alcanza el servidor que aloja el sitio web. El TTFB de este tramo escapa en gran medida al control directo del sitio web y depende sobre todo de:

• La velocidad de conexión del usuario.
• La calidad de su infraestructura de red.
• La distancia física entre el usuario y el servidor.

En esta fase, la resolución DNS, el arranque del propio navegador, las consultas a la caché local y la negociación de la conexión con el servidor (TCP y TLS) consumen su correspondiente margen de tiempo.

En el servidor: procesamiento y preparación de la respuesta

En cuanto el servidor recibe la solicitud, el reloj corre mientras genera la respuesta. Es la fase en la que suelen centrarse casi todos los desarrolladores y donde las tareas de optimización generan mayor impacto. Factores determinantes:

• Capacidad del servidor: Hardware potente (CPU, RAM), software eficiente (servidor web, base de datos) y configuraciones optimizadas resultan clave.
• Duración de las consultas a bases de datos: Si la petición exige consultar datos, las consultas lentas representan un grave cuello de botella.
• Optimización del código: Un código de backend mal estructurado (scripts poco eficientes) dispara el tiempo de procesamiento.
• Estrategias de caché: Una caché eficaz (en el servidor o a través de una Content Delivery Network) aligera drásticamente la carga de procesamiento ante visitas recurrentes.

De vuelta al navegador: entrega del primer byte

Tras el procesamiento, el servidor devuelve la respuesta al navegador del usuario, empezando por el primer byte.

• Igual que en la primera fase, el estado de la red y la distancia física vuelven a marcar la diferencia.
• Las CDN resultan especialmente ventajosas aquí: almacenan el contenido cerca de los usuarios y acortan el tiempo de tránsito.
• Las redirecciones se entregan en este punto, lo que obliga a reiniciar todo el ciclo con su correspondiente penalización de tiempo.

Fases técnicas del Time to First Byte

De forma similar al recorrido de la solicitud a la respuesta en el navegador, el Time to First Byte de las solicitudes de navegación puede medirse con la Navigation Timing API y desglosarse en 5 partes.

1. Tiempo de redirección: cuando un recurso se traslada a una nueva ubicación, el tiempo de la redirección se suma al TTFB del recurso.
2. Tiempo de worker y caché: antes de solicitar un recurso por internet, el navegador intenta localizarlo en su propia caché o mediante un worker (si se ha configurado alguno).
3. Tiempo de resolución DNS: a continuación, el navegador puede requerir una consulta DNS para resolver el nombre de dominio (www.example.com) en una dirección IP.
4. Tiempo de conexión TCP: después, el navegador establece conexión con el servidor y lleva a cabo varias comprobaciones.
5. Handshake SSL: seguidamente, el navegador y el servidor cifran el canal de comunicación.
6. Respuesta del servidor: por último, el servidor debe enviar el HTML. Puede que antes necesite generarlo dinámicamente.

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

Consejo de PageSpeed: cada recurso tiene su propio Time to First Byte. No obstante, en este contexto nos centramos en el Time to First Byte de la página principal.

El Time to First Byte fluctúa notablemente entre diferentes usuarios, dispositivos y ubicaciones geográficas. Por esa razón, medir el Time to First Byte manualmente desde tu ordenador de escritorio no es una buena idea. Las herramientas como Pingdom o GTMetrix tampoco resultan fiables por idéntico motivo.

La forma idónea de medir el Time to First Byte es recopilar métricas reales de usuarios (RUM) de tus visitantes. Puedes hacerlo tú mismo con el código de abajo o recurrir a una herramienta de RUM como CoreDash.

Medir el TTFB con herramientas sintéticas

Medir el TTFB con monitorización RUM

Medir el TTFB con datos de CrUX

CrUX (Chrome User Experience Report) es un conjunto de datos público de Google con métricas de rendimiento real de sitios web. Google recurre al conjunto de datos de CrUX para evaluar si un sitio aprueba o suspende los Core Web Vitals.

Se puede acceder a los datos de CrUX mediante herramientas como PageSpeed Insights, la API de CrUX, Looker Studio o Google BigQuery. Utiliza cualquiera de ellas para conocer el TTFB de tu sitio.

Medir el TTFB con JavaScript

Para medir el Time to First Byte (TTFB) mediante JavaScript, recurre a la Navigation Timing API. Puedes crear un PerformanceObserver que capture la entrada de navegación y registre la propiedad responseStart en la consola. Dicha propiedad contiene la marca de tiempo exacta en que se recibió el primer byte de respuesta. La librería JavaScript web-vitals proporciona una vía aún más compacta para medir el TTFB en el navegador con la función onTTFB.

El siguiente código sirve para registrar y desglosar el Time to First Byte (TTFB):

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Detectar cuellos de botella con la Server-Timing API

La Server-Timing API define un mecanismo estandarizado para transmitir métricas de rendimiento del backend hacia el navegador. Mediante las cabeceras Server-Timing, los desarrolladores pueden medir y analizar con rigor los procesos del servidor que condicionan el TTFB, lo que facilita aislar áreas de mejora y optimizar el rendimiento general del sitio web.

La cabecera Server-Timing admite métricas múltiples separadas por comas. Cada entrada comprende:

• Un identificador breve de la métrica (como database o processing)
• Una duración en milisegundos (representada como dur=123)
• Una descripción opcional (representada como desc="My Description")

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Cómo inspeccionar Server-Timing en Chrome DevTools

Chrome DevTools muestra las entradas de Server-Timing directamente en el panel Network. Abre DevTools, selecciona la petición del documento en la pestaña Network y baja hasta el bloque «Server Timing» dentro de la pestaña Timing. Cada métrica remitida mediante la cabecera Server-Timing figurará con su nombre, descripción y duración. De este modo sabrás al instante si el cuello de botella procede de la base de datos, del renderizado de plantillas o de la capa de caché.

También puedes leer la cabecera Server-Timing por código y enviar los registros a tu herramienta RUM habitual, como CoreDash, para habilitar históricos y alertas.

Acelerar el TTFB con 103 Early Hints

103 Early Hints es un código de estado HTTP que permite al servidor enviar cabeceras de respuesta preliminares al navegador antes de tener lista la respuesta definitiva. Mientras el servidor continúa procesando la petición (consultando la base de datos o renderizando plantillas), el navegador puede comenzar a descargar recursos críticos como hojas de estilo, tipografías y la imagen del LCP.

Cómo funciona 103 Early Hints

En un ciclo tradicional de petición, el navegador permanece inactivo durante todo el procesamiento del servidor. Con 103 Early Hints, el servidor emite una respuesta parcial justo tras recibir la solicitud. Esta respuesta preliminar incluye cabeceras Link que ordenan al navegador qué recursos precargar o a qué dominios preconectarse. El navegador procesa estas indicaciones mientras aguarda la respuesta 200 final.

Esto convierte de forma efectiva un tiempo muerto de espera en tiempo productivo de carga. Aunque 103 Early Hints no reduce el TTFB del documento en sí, sí alivia el impacto percibido del TTFB en métricas posteriores como LCP y FCP al anticipar el descubrimiento de recursos críticos.

Ejemplo de configuración de servidor para 103 Early Hints

Muchas CDN y servidores web ya admiten 103 Early Hints. Esto es lo que se aplica en Cloudflare, que genera automáticamente 103 Early Hints a partir de las cabeceras Link y de las etiquetas preload y preconnect declaradas en el HTML:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

En Nginx, puedes configurar Early Hints añadiendo cabeceras Link a la respuesta y activando Server Push bajo HTTP/2 o HTTP/3. Apache admite 103 Early Hints a través de la directiva H2EarlyHints. Revisa nuestra guía detallada para implementar 103 Early Hints si necesitas instrucciones paso a paso.

Eliminar el TTFB con la Speculation Rules API

La Speculation Rules API se diseñó para acelerar navegaciones futuras. Cuando un visitante llega a tu página, puedes recurrir a Speculation Rules para indicarle al navegador que descargue (con la directiva prefetch) o incluso renderice por completo (con la directiva prerender) las páginas con mayor probabilidad de ser visitadas a continuación.

Cómo anula el TTFB la Speculation Rules API

Cuando una página se somete a prerender, el navegador la descarga y renderiza en su totalidad dentro de una pestaña invisible. En el momento en que el usuario hace clic en el enlace, la página prerenderizada se conmuta al instante. El resultado: un TTFB medido de 0 milisegundos. No es una cifra teórica: los datos RUM de CoreDash procedentes de corewebvitals.io confirman que las navegaciones prerenderizadas con Speculation Rules arrojan un TTFB p75 de 0ms.

El prefetching es una alternativa más liviana. En vez de renderizar la página completa, el navegador descarga únicamente el documento HTML y lo guarda en caché. Esto neutraliza la fase de red del TTFB, aunque el navegador aún deba procesar y renderizar el documento cuando se produzca la navegación.

Sintaxis JSON de Speculation Rules

Las Speculation Rules se declaran mediante un bloque <script type="speculationrules"> que contiene JSON. A continuación tienes un ejemplo que aplica prerender a todos los enlaces del menú con avidez «moderate» (se activa al pasar el cursor o al pulsar el puntero):

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

También puedes recurrir a una lista explícita para URLs determinadas:

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

La compatibilidad de los navegadores con Speculation Rules sigue en aumento: Chrome 121+ admite la API completa, incluidas las reglas basadas en documento. Para navegadores que aún no son compatibles con Speculation Rules, puedes usar una librería ligera como quicklink a modo de fallback. Emplea nuestro generador de Speculation Rules para diseñar la configuración precisa de tu sitio.

¿Cómo influye el hosting en el Time to First Byte?

El hosting condiciona el Time to First Byte de múltiples formas. Invertir en una mejor infraestructura suele traducirse en una mejora inmediata del Time to First Byte sin necesidad de modificar el código. La mejora del TTFB suele ser drástica, sobre todo al migrar desde un alojamiento compartido de bajo coste hacia servidores virtuales bien configurados y optimizados.

Consejo sobre hosting: un hosting de calidad aporta mayor velocidad de procesamiento, mejor rendimiento de red y memoria de servidor más abundante y rápida. Un hosting caro no siempre equivale a un hosting óptimo: muchas ampliaciones en planes compartidos solo añaden capacidad de disco, no potencia de cálculo de CPU.

No aconsejo cambiar de hosting sin identificar antes la causa raíz de los fallos de TTFB. Configura primero la monitorización RUM e incorpora cabeceras Server-Timing.

Al renovar o mejorar el hosting, prioriza siempre al menos una de estas tres mejoras:

• Más recursos de sistema (CPU + RAM): Esencial cuando el servidor demora demasiado la generación del HTML dinámico.
• DNS más veloz: Muchos proveedores de hosting económicos ofrecen un rendimiento de DNS deficiente.
• Configuraciones más avanzadas: Cifrados SSL más rápidos, HTTP/3, compresión Brotli y acceso directo a la configuración del servidor web (para deshabilitar módulos innecesarios), entre otras ventajas.

Cómo mejorar el TTFB: acelerar la conexión inicial

Un Time to First Byte elevado responde a causas diversas. Sin embargo, DNS, TCP y SSL intervienen en todos los registros de TTFB. Conviene empezar por ahí. Aunque resolver estos tres factores no siempre aporte el mayor recorte absoluto, optimizarlos acelera absolutamente todos los TTFB.

Acelerar DNS

Consejo de PageSpeed: DNS, TCP y SSL suelen suponer un obstáculo mayor cuando se opera con un hosting barato o ante audiencias globales sin el apoyo de una CDN. Emplea la monitorización RUM para evaluar tu TTFB global y desglosarlo en sus fases correspondientes.

Contrata un proveedor de DNS rápido. No todos los servicios de DNS rinden al mismo nivel: algunos proveedores (incluso gratuitos) son notablemente más lentos que otros. Cloudflare, por ejemplo, ofrece gratis uno de los servidores DNS más veloces del mercado.

Aumenta el TTL del DNS. Otra vía consiste en elevar el valor Time to Live (TTL). El TTL es un parámetro que determina cuánto tiempo se conserva la resolución en caché. A mayor TTL, con menor frecuencia tendrá el navegador que lanzar una nueva resolución DNS. Recuerda que los proveedores de acceso a internet (ISP) también almacenan las respuestas DNS en caché.

Acelerar TCP

La fase TCP del TTFB corresponde al establecimiento inicial de la conexión con el servidor web. Al conectar, el navegador y el servidor acuerdan las condiciones para transferir datos. Puedes acelerar TCP conectando con un servidor geográficamente próximo y asegurando que la máquina disponga de recursos libres suficientes. A veces, sustituir el software por un servidor ligero como NGINX recorta esta fase. En la mayoría de los casos, recurrir a una CDN es la vía más directa para acelerar la conexión TCP.

Acelerar SSL/TLS

Una vez cerrada la conexión TCP, el navegador y el servidor deben asegurar el canal mediante cifrado. Puedes acelerar el proceso utilizando suites de cifrado SSL más modernas, ágiles y ligeras, así como acortando la distancia geográfica con el servidor (la negociación TLS precisa varios viajes de ida y vuelta o round-trips). Una CDN mejora con frecuencia este tiempo de conexión, ya que sus servidores están muy bien optimizados y distribuidos por todo el planeta. TLS 1.3 se diseñó precisamente para acortar al mínimo la negociación TLS.

Cómo mejorar el TTFB: acelerar el lado del servidor

Caché de página

La estrategia más contundente para acelerar el Time to First Byte consiste en entregar el HTML directamente desde la caché del servidor. Existen varias fórmulas para implementar caché de página completa. La más eficaz opera a nivel de servidor web; por ejemplo, mediante el módulo de caché de NGINX o configurando Varnish como proxy inverso de caché.

Abundan también los plugins para plataformas CMS capaces de cachear páginas completas, mientras que muchos frameworks SPA como Next.js integran mecanismos propios de caché de página con distintas estrategias de invalidación.

Si prefieres diseñar tu propio sistema de caché, el principio es directo: cuando un cliente solicita una página, compruebas si existe en la carpeta de caché. Si no está, generas la página, la guardas en caché y la sirves con normalidad. En las siguientes solicitudes, el archivo en caché ya existirá y entregarás la página de inmediato desde el almacenamiento.

Caché parcial

Con la caché parcial, el objetivo es almacenar fragmentos pesados, lentos o recurrentes de la página o de sus dependencias (como llamadas a API o resultados de bases de datos) para agilizar su entrega. Esto suprime los cuellos de botella al componer la página. Si buscas profundizar en este tipo de técnicas, investiga conceptos como: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache y Opcode Cache.

Optimizar el código de la aplicación

En ocasiones la página no puede servirse desde la caché (ni siquiera de forma parcial) porque el archivo no existe, gran parte del contenido es dinámico o surgen otros condicionantes. Por eso resulta crítico optimizar el código de la aplicación. La solución depende de la arquitectura de cada proyecto: radica en reescribir y optimizar los bloques más lentos del backend.

Optimizar las consultas a la base de datos

Casi siempre, las consultas ineficientes a bases de datos constituyen la causa raíz de un Time to First Byte lento. Empieza por registrar en disco las consultas lentas («slow queries») y aquellas que no utilicen índices. Analízalas, genera los índices necesarios o recurre a un especialista para afinar la base de datos. Consulta las guías de MongoDB Performance Advisor y de MySQL Slow Query Log para profundizar.

Reducir la latencia interna de red

Un error habitual que observo con excesiva frecuencia es la degradación del Time to First Byte por culpa de la lentitud de comunicación entre la aplicación web y los almacenes de datos. Suele darse sobre todo en plataformas grandes que delegan su persistencia en API cloud externas.

Cómo mejorar el TTFB: acelerar el lado del cliente

Caché del lado del cliente

La caché del cliente consiste en que el navegador guarde recursos que ya ha descargado previamente, como imágenes y scripts. Cuando el usuario regresa a tu sitio web, el navegador recupera estos recursos de su propia caché en vez de descargarlos de nuevo. Esto reduce sensiblemente las peticiones remitidas al servidor, lo que a su vez alivia el TTFB.

Para aplicar caché en el cliente, utiliza la cabecera HTTP Cache-Control. Esta directiva te permite fijar cuánto tiempo debe almacenar el navegador un recurso concreto en caché.

Puedes plantearte almacenar por completo en la caché del cliente el HTML de la página. Esto rebaja de forma radical el TTFB, ya que no se emite ninguna petición al servidor. La contrapartida es que, una vez la página queda en la caché del navegador, el usuario no percibirá ninguna actualización de la versión en producción hasta que expire el tiempo de caché fijado.

Service workers

Los service workers son scripts que se ejecutan en segundo plano dentro del navegador y tienen la capacidad de interceptar peticiones de red. Esto les permite almacenar en caché recursos como HTML, imágenes, scripts y hojas de estilo; de este modo, cuando el usuario regresa al sitio web, el navegador recupera de inmediato el contenido en local sin tener que descargarlo otra vez.

Prefetching de páginas

Si prefieres no utilizar la Speculation Rules API debido a su limitada compatibilidad en navegadores, puedes recurrir a una utilidad compacta llamada quicklink. Se encarga de precargar todos los enlaces presentes en el viewport visible y prácticamente anula el Time to First Byte al hacer clic en ellos.

La desventaja de quicklink radica en que consume más recursos del dispositivo, aunque hoy por hoy supera a la Speculation Rules API en cobertura de navegadores.

Cómo mejorar el TTFB: utilizar una CDN

Una Content Delivery Network o CDN recurre a una red distribuida de servidores para entregar recursos a los usuarios. Estas máquinas se sitúan físicamente más cerca de los usuarios finales y están optimizadas para la velocidad. Si utilizas Cloudflare, revisa nuestra guía para configurar Cloudflare para un rendimiento óptimo en Core Web Vitals.

Una CDN permite recortar 5 de las 6 fases que componen el Time to First Byte:

• Tiempo de redirección: Casi todas las CDN pueden almacenar redirecciones en el edge o utilizar edge workers para resolverlas sin contactar con el servidor de origen.
• Tiempo de resolución DNS: La gran mayoría de CDN provee servicios DNS ultrarrápidos que superan con holgura a los servidores DNS tradicionales.
• Conexión TCP y Handshake SSL: Las CDN presentan configuraciones muy pulidas que, unidas a la cercanía física con el usuario, aceleran notablemente la conexión y el intercambio de certificados.
• Respuesta del servidor: Las CDN aceleran este tiempo de dos formas: reteniendo la respuesta en caché en el edge (edge caching de página completa) y aplicando algoritmos modernos de compresión (Brotli) junto con los protocolos más recientes (HTTP/3).

Cómo mejorar el TTFB: evitar redirecciones

El tiempo consumido en redirecciones se añade de forma íntegra al Time to First Byte. Por norma general, evita las redirecciones al máximo. Suelen ocurrir cuando un recurso deja de estar disponible en una URL y se mueve a otra: el servidor devuelve una cabecera de redirección y el navegador debe iniciar una nueva petición hacia ese nuevo destino.

Redirecciones del mismo origen. Se generan desde enlaces internos dentro de tu propio sitio web. Tienes control absoluto sobre ellos y debes priorizar su corrección al optimizar el Time to First Byte. Hay múltiples herramientas que permiten auditar todo el sitio web para cazar estas redirecciones.

Redirecciones entre distintos orígenes. Proceden de enlaces ubicados en sitios web externos. Sobre estas apenas tienes margen de maniobra.

Redirecciones múltiples. Las cadenas de redirecciones surgen cuando una primera redirección no conduce a la ubicación definitiva del recurso, sino a otro salto intermedio. Este encadenamiento penaliza severamente el Time to First Byte y debe suprimirse a toda costa. Emplea de nuevo una herramienta de rastreo para detectar y resolver estas secuencias.

Redirecciones de HTTP a HTTPS. Una técnica eficaz para neutralizarlas es activar la cabecera Strict-Transport-Security (HSTS), que impone el uso de HTTPS desde la primera visita y ordena al navegador que en accesos futuros solicite directamente el protocolo HTTPS.

Cuando un usuario pide una página web, el servidor puede responder redirigiendo hacia otra dirección. Este salto añade tiempo al TTFB porque el navegador está obligado a lanzar una solicitud suplementaria para alcanzar la página definitiva.

Esto es lo que debes aplicar para erradicar las redirecciones o mitigar su impacto:

1. Actualiza los enlaces internos. Cada vez que cambies la URL de una página, actualiza todos los enlaces internos que apunten a ella para que no quede ningún rastro de la dirección antigua.
2. Resuelve las redirecciones directamente a nivel de servidor.
3. Usa URLs relativas: Al enlazar contenido interno de tu sitio web, recurre a URLs relativas en lugar de absolutas. Esto previene redirecciones accidentales.
4. Usa URLs canónicas: Si gestionas varias páginas con contenido idéntico o similar, designa una URL canónica para marcar la versión prioritaria. Evitarás contenido duplicado y saltos innecesarios.
5. Usa redirecciones 301: Si no queda más remedio que redirigir, aplica un código 301 en vez de un 302. El 301 es una redirección permanente, mientras que el 302 es temporal. El estado 301 permite al navegador cachear el destino y esquivar peticiones redundantes.

Optimizar la priorización de recursos junto con el TTFB

Recortar el TTFB resuelve solo una parte del rendimiento de carga. En cuanto aterriza el primer byte, el navegador necesita saber qué recursos priorizar. Revisa nuestra guía de priorización de recursos para comprobar cómo directivas como fetchpriority, preload y preconnect cooperan con un TTFB veloz para acelerar al máximo la carga de la página. Asimismo, valora alojar tus propias Google Fonts para suprimir resoluciones DNS externas y tiempos de conexión que inflan el TTFB percibido por los visitantes.

Qué revelan los datos de TTFB en el mundo real

Los datos que figuran a continuación proceden del sistema de Real User Monitoring de CoreDash y del Web Almanac de 2025.

La variación geográfica es enorme

El TTFB oscila drásticamente en función de la separación física entre el usuario y el servidor. Los datos de CoreDash registrados en corewebvitals.io (con servidor en Europa) lo demuestran claramente:

Los usuarios europeos cercanos al servidor registran un TTFB por debajo de 170ms, mientras que en la India la cifra se triplica y en China se multiplica casi por diez (1468ms) por efecto del Gran Cortafuegos y la enorme distancia geográfica. Estos registros confirman por qué disponer de una CDN con nodos edge internacionales resulta imprescindible ante audiencias globales.

El prerender de Speculation Rules ofrece 0ms de TTFB

Los datos por tipología de navegación de CoreDash constatan que las páginas precargadas con prerender mediante Speculation Rules alcanzan un TTFB p75 de 0 milisegundos. Las navegaciones habituales marcan 131ms, las recargas se sitúan en 82ms (favorecidas por conexiones ya activas) y las navegaciones de avance y retroceso (back-forward) quedan rezagadas en 244ms. Esto convierte a Speculation Rules en el recurso más resolutivo para suprimir el TTFB en visitas sucesivas.

El TTFB en móvil multiplica por 2,5 al de escritorio

En corewebvitals.io, los accesos desde móvil arrojan un TTFB p75 de 316ms frente a los 124ms observados en escritorio. Esta brecha de 2,5x responde a la latencia de las redes móviles, no a deficiencias del servidor. Apenas un 88,5% de las cargas móviles alcanza la calificación de TTFB «bueno», frente al 96,1% obtenido en escritorio. Al optimizar el TTFB, evalúa siempre sobre conexiones móviles reales.

Usuarios nuevos y recurrentes registran un TTFB similar

En este sitio web, los visitantes nuevos marcan un TTFB p75 de 127ms, mientras que los recurrentes anotan 138ms. Esta coincidencia demuestra que una caché de servidor sólida y consistente (por encima de los beneficios de la caché del navegador) representa el pilar maestro del TTFB. En sitios desprovistos de caché de servidor, la diferencia entre usuarios nuevos y recurrentes suele ser sustancialmente mayor.

El TTFB global lleva 5 años estancado

De acuerdo con el Web Almanac de 2025, únicamente el 44 % de las páginas móviles obtiene una valoración de TTFB «bueno» en todo el mundo. La proporción apenas se ha movido desde el 41 % anotado en 2021, lo que convierte al TTFB en la métrica más rezagada de la web. En ese mismo intervalo, el LCP progresó del 44 % al 59 % y el INP escaló del 55 % al 74 %. Los sitios web con un LCP deficiente consumen una media de 2,27 segundos exclusivamente en el TTFB, agotando prácticamente el margen completo de 2,5 segundos del LCP.

Guías relacionadas: fases del TTFB

Cada componente del Time to First Byte responde a tácticas de optimización específicas:

• <b>Identificar y corregir problemas de TTFB</b>: Guía de diagnóstico paso a paso para localizar la raíz de un TTFB lento mediante DevTools, Server-Timing y telemetría RUM.
• <b>Reducir la duración de espera</b>: Cómo recortar los tiempos de redirección y las demoras de procesamiento en backend que inflan tu TTFB.
• <b>Reducir la duración de caché</b>: Estrategias de caché en navegador, service workers y back/forward cache (bfcache) para fulminar el TTFB en visitas recurrentes.
• <b>Minimizar la duración de DNS</b>: Cómo acelerar la resolución DNS contratando proveedores más rápidos, elevando los valores TTL y configurando directivas dns-prefetch.
• <b>Optimizar la duración de conexión (TCP + TLS)</b>: Reducción de los handshakes TCP y TLS con HTTP/3, TLS 1.3, reanudación de sesiones y directivas preconnect.