Qué es el Time To First Byte (TTFB) y cómo mejorarlo

El Time to First Byte (TTFB) mide el tiempo en milisegundos entre que el navegador solicita una página y recibe el primer byte de la respuesta del servidor. Un buen TTFB es de 800 milisegundos o menos en el percentil 75. El TTFB no es una Core Web Vital, pero es una métrica de diagnóstico crítica porque impacta directamente tanto en el Largest Contentful Paint (LCP) como en el First Contentful Paint (FCP).

Qué es el Time to First Byte

El Time to First Byte (TTFB) indica cuánto tiempo ha transcurrido en milisegundos entre el inicio de la solicitud y la recepción de la primera respuesta (byte) de una página web. Por lo tanto, el TTFB también se conoce como el tiempo de espera. El TTFB es una forma de medir la capacidad de respuesta de un servidor web y la ruta de red entre el usuario y ese servidor. El TTFB es una métrica fundamental; esto significa que el tiempo añadido al TTFB también se añadirá al Largest Contentful Paint y al First Contentful Paint. Cada milisegundo ahorrado en el TTFB es un milisegundo ahorrado en ambas métricas de pintura.

El TTFB no es una Core Web Vital

Es importante afirmar esto claramente: El TTFB no es una de las tres Core Web Vitals. Las Core Web Vitals consisten en Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Google no utiliza el TTFB directamente en sus señales de clasificación de experiencia de página.

Sin embargo, el TTFB se clasifica como una métrica de diagnóstico. Te ayuda a entender por qué tu LCP o FCP podría ser lento. Según el HTTP Archive Web Almanac 2024, los sitios con un LCP deficiente gastan un promedio de 2.27 segundos solo en el TTFB, lo que casi agota el umbral completo de 2.5 segundos del LCP antes de que el navegador siquiera comience a renderizar la página. Arreglar el TTFB es, por lo tanto, una de las cosas más impactantes que puedes hacer para tus puntuaciones generales de Core Web Vitals.

Por qué es importante el Time to First Byte

El Time to First Byte no es una Core Web Vital y es muy posible aprobar las Core Web Vitals fallando la métrica TTFB. Eso no significa que el TTFB no sea importante. El TTFB es una métrica extremadamente importante para optimizar y arreglar el TTFB mejorará enormemente la velocidad de la página y la experiencia de la página.

El impacto del TTFB para los visitantes

El Time to First Byte precede a todas las demás métricas de pintura. Mientras el navegador espera el Time to First Byte, no puede hacer nada y solo mostrará una pantalla en blanco. Esto significa que cualquier aumento en el Time to First Byte resultará en tiempo extra de "pantalla en blanco" y cualquier disminución en el Time to First Byte se traducirá en menos tiempo de "pantalla en blanco".

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

¿Por qué el TTFB no es una Core Web Vital? El TTFB no tiene en cuenta el renderizado: un TTFB bajo no significa necesariamente una buena experiencia de usuario porque no considera el tiempo que le toma al navegador renderizar la página web. Incluso si todos los bytes se descargan rápidamente, la página web podría tardar mucho en mostrarse si el navegador necesita procesar mucho JavaScript o renderizar diseños complejos.

¿Qué es una buena puntuación TTFB?

Se recomienda que tu servidor responda a las solicitudes de navegación lo suficientemente rápido para que el percentil 75 de los usuarios experimente un FCP dentro del umbral "bueno". Como guía aproximada, la mayoría de los sitios deberían esforzarse por tener un TTFB de 0.8 segundos o menos.

• Un TTFB por debajo de 800 milisegundos se considera bueno.
• Un TTFB entre 800 y 1800 milisegundos necesita mejora.
• Un TTFB superior a 1800 milisegundos se considera pobre y debe mejorarse inmediatamente.

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

T-Mobile invirtió fuertemente en reducir su Time to First Byte como parte de una iniciativa de optimización de rendimiento más amplia. Los resultados fueron sorprendentes: un aumento del 60% en las conversiones de visita a pedido. Al pasar a páginas renderizadas en el borde y un almacenamiento en caché agresivo del lado del servidor, T-Mobile redujo drásticamente el tiempo que los usuarios pasaban esperando el primer byte, lo que se tradujo en un LCP más rápido, un FCP más rápido y una experiencia de usuario mediblemente mejor. Este estudio de caso demuestra que la optimización del TTFB no es solo un ejercicio técnico; afecta directamente a los resultados comerciales.

El TTFB desde la solicitud hasta la respuesta

Del navegador al servidor: La solicitud

El tiempo de solicitud del navegador es el tiempo transcurrido desde el momento en que el navegador de un usuario envía una solicitud HTTP hasta que esa solicitud llega al servidor que aloja el sitio web. El TTFB de esta parte está en gran medida fuera del control directo del sitio web y depende en gran medida de:

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

Dentro de esta etapa, la búsqueda de DNS, el tiempo de inicio del navegador, las búsquedas en la caché del navegador y la negociación de la conexión con el servidor (TCP y TLS) toman un poco de tiempo.

En el servidor: Procesando y preparando la respuesta

Una vez que el servidor recibe la solicitud, el reloj corre mientras trabaja para generar una respuesta. Esta etapa es en la que la mayoría de los desarrolladores tienden a centrarse y donde los esfuerzos de optimización pueden tener el impacto más significativo. Los factores a considerar incluyen:

• Capacidades del servidor: El hardware potente (CPU, RAM), el software eficiente (servidor web, base de datos) y las configuraciones optimizadas importan.
• Duración de la base de datos: Si la solicitud requiere obtener datos de una base de datos, las consultas lentas pueden ser un cuello de botella importante.
• Optimización del código: El código del lado del servidor mal escrito (p. ej., scripts ineficientes) puede llevar a largos tiempos de procesamiento.
• Estrategias de caché: El almacenamiento en caché efectivo (como el almacenamiento en caché del lado del servidor o el uso de una Content Delivery Network) puede reducir drásticamente la carga de procesamiento para solicitudes repetidas.

De vuelta al navegador: Entregando el primer byte

Después del procesamiento, el servidor envía la respuesta, comenzando con el primer byte, de vuelta al navegador del usuario.

• De manera similar a la primera etapa, las condiciones de la red y la distancia también juegan un papel aquí.
• Las CDNs son particularmente beneficiosas en esta etapa ya que almacenan contenido en caché más cerca de los usuarios, minimizando el tiempo de viaje.
• Las redirecciones se sirven en este punto, lo que hace que el proceso se repita con un retraso adicional.

Etapas técnicas del Time To First Byte

De manera similar a la "ruta de solicitud a respuesta" en tu navegador, el Time To First Byte de las solicitudes de navegación se puede medir con la Navigation Timing API y desglosarse en 5 subpartes.

1. Tiempo de redirección: cuando un recurso se ha movido a una nueva ubicación, el tiempo de redirección se añade al TTFB del recurso.
2. Tiempo de Worker y Caché: antes de que un recurso se obtenga de internet, un navegador primero intentará buscarlo en su propia caché o a través de un worker (si se ha configurado un worker).
3. Tiempo de búsqueda DNS: A continuación, un navegador podría necesitar realizar una búsqueda DNS para traducir el nombre de dominio (www.example.com) a una dirección IP.
4. Tiempo de conexión TCP: Luego, el navegador se conectará al servidor y realizará algunas comprobaciones.
5. Handshake SSL: Luego, el navegador y el servidor cifrarán su comunicación.
6. Respuesta del servidor: Finalmente, el servidor necesita enviar el HTML. Podría necesitar generar el HTML primero.

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

CONSEJO de PageSpeed: cada recurso tiene su propio Time to First Byte. En este contexto, sin embargo, estamos hablando del Time to First Byte de la página principal.

El Time to First Byte puede fluctuar enormemente entre diferentes usuarios con diferentes dispositivos y desde diferentes ubicaciones. Es por eso que auto-medir el Time to First Byte desde tu computadora de escritorio probablemente no sea una gran idea. Usar herramientas como Pingdom o GTmetrix no es confiable por la misma razón.

La mejor manera de medir el Time To First Byte es recopilar datos de Real User Metrics (RUM) de tus visitantes. Puedes hacer esto tú mismo con el código a continuación o usar una herramienta RUM como CoreDash.

Medir TTFB con herramientas sintéticas

Medir TTFB con seguimiento RUM

Medir TTFB con datos de CrUX

CrUX (Chrome User Experience Report) es un conjunto de datos disponible públicamente de Google que contiene datos de rendimiento del mundo real para sitios web. Google utiliza el conjunto de datos de CrUX para determinar si estás aprobando o no las Core Web Vitals.

Se puede acceder al conjunto de datos de CrUX a través de herramientas como PageSpeed Insights, la CrUX API, Looker Studio o Google BigQuery. Utiliza cualquiera de estas herramientas para obtener el TTFB para tu sitio.

Medir TTFB con JavaScript

Para medir el Time to First Byte (TTFB) con JavaScript, puedes usar la Navigation Timing API. Puedes crear un PerformanceObserver que escuche una entrada de navegación y registre la propiedad responseStart en la consola. La propiedad responseStart representa la marca de tiempo cuando se recibió el primer byte de la respuesta. La biblioteca JavaScript web-vitals proporciona una forma más concisa de medir el TTFB en el navegador utilizando la función onTTFB.

El siguiente código se puede utilizar para medir 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
});

Encontrar cuellos de botella con la Server-Timing API

La Server-Timing API proporciona una forma estandarizada de enviar tiempos de rendimiento del servidor backend al navegador. Al utilizar encabezados Server-Timing, los desarrolladores pueden medir y analizar los componentes del lado del servidor que contribuyen al TTFB, ayudando a identificar áreas para la optimización y mejorando el rendimiento general del sitio web.

El encabezado Server-Timing puede contener tiempos para múltiples métricas separadas por comas. Cada entrada consta de:

• Un nombre corto para la métrica (como database y processing)
• Una duración en milisegundos (expresada como dur=123)
• Una descripción opcional (expresada como desc="My Description")

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

Leer Server-Timing en Chrome DevTools

Chrome DevTools muestra las entradas de Server-Timing directamente en el panel Network. Abre DevTools, selecciona la solicitud del documento en la pestaña Network, desplázate hacia abajo hasta la sección "Server Timing" en la pestaña Timing. Cada métrica que envíes a través del encabezado Server-Timing aparecerá con su nombre, descripción y duración. Esto hace que sea sencillo identificar si tu base de datos, renderizado de plantillas o capa de caché es el cuello de botella.

También puedes leer el encabezado Server-Timing programáticamente y enviar estos tiempos a tu herramienta RUM favorita como CoreDash para seguimiento y alertas a largo plazo.

Acelerar el TTFB con 103 Early Hints

103 Early Hints es un código de estado HTTP que permite al servidor enviar encabezados de respuesta preliminares al navegador antes de que la respuesta final esté lista. Mientras el servidor todavía está procesando la solicitud (consultando la base de datos, renderizando la plantilla), el navegador ya puede comenzar a cargar recursos críticos como hojas de estilo, fuentes y la imagen LCP.

Cómo funciona 103 Early Hints

En un flujo de solicitud tradicional, el navegador permanece inactivo durante todo el tiempo de procesamiento del servidor. Con 103 Early Hints, el servidor envía una respuesta parcial inmediatamente después de recibir la solicitud. Esta respuesta parcial contiene encabezados Link que le dicen al navegador qué recursos precargar o pre-conectar. El navegador actúa sobre estas pistas mientras espera la respuesta 200 completa.

Esto convierte efectivamente el tiempo de espera muerto en tiempo de carga productivo. Aunque 103 Early Hints no reduce el TTFB del documento en sí, reduce el impacto percibido del TTFB en métricas posteriores como LCP y FCP al darle al navegador una ventaja en el descubrimiento de recursos.

Ejemplo de configuración del servidor para 103 Early Hints

Muchas CDNs y servidores web ahora soportan 103 Early Hints. Aquí hay un ejemplo usando Cloudflare, que genera automáticamente 103 Early Hints a partir de encabezados Link y etiquetas preload/preconnect encontradas en tu 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
...

Para Nginx, puedes configurar Early Hints añadiendo encabezados Link a tu respuesta y habilitando HTTP/2 o HTTP/3 push. Apache soporta 103 Early Hints a través de la directiva H2EarlyHints. Consulta nuestra guía detallada sobre implementar 103 Early Hints para instrucciones paso a paso.

Eliminar el TTFB con la Speculation Rules API

La Speculation Rules API está diseñada para mejorar el rendimiento de futuras navegaciones. Una vez que un visitante ha llegado a tu página, puedes usar Speculation Rules para instruir a un navegador a obtener (con la directiva prefetch) o incluso renderizar completamente (con la directiva prerender) páginas que es más probable que el visitante visite a continuación.

Cómo Speculation Rules elimina el TTFB

Cuando una página es pre-renderizada, el navegador la carga y renderiza completamente en una pestaña oculta. Cuando el usuario hace clic en el enlace, la página pre-renderizada se intercambia instantáneamente. El resultado: un TTFB medido de 0 milisegundos. Este no es un número teórico. Los datos RUM de CoreDash de corewebvitals.io confirman que las navegaciones pre-renderizadas a través de Speculation Rules muestran un p75 TTFB de 0ms.

Prefetching es una alternativa más ligera. En lugar de renderizar completamente la página, el navegador solo obtiene el documento HTML y lo almacena en caché. Esto elimina la parte de red del TTFB mientras aún requiere que el navegador analice y renderice el documento tras la navegación.

Sintaxis JSON de Speculation Rules

Las Speculation Rules se definen utilizando un bloque <script type="speculationrules"> que contiene JSON. Aquí hay un ejemplo que pre-renderiza todos los enlaces de navegación en tu barra de menú con una ansia "moderada" (activada al pasar el cursor o pulsar):

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

También puedes usar un enfoque basado en listas para URLs específicas:

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

El soporte del navegador para Speculation Rules está creciendo. Chrome 121+ soporta la API completa, incluidas las reglas de documento. Para los navegadores que aún no soportan Speculation Rules, podrías usar un script ligero como quicklink como respaldo. Utiliza nuestro Generador de Speculation Rules para crear la configuración correcta para tu sitio.

¿Cómo afecta el alojamiento al Time to First Byte?

El alojamiento afecta al Time to First Byte de múltiples maneras. Al invertir en un mejor alojamiento, generalmente es posible mejorar inmediatamente el Time to First Byte sin cambiar nada más. Especialmente al cambiar de un alojamiento compartido de bajo presupuesto a servidores virtuales correctamente configurados y administrados, el TTFB podría mejorar drásticamente.

CONSEJO de Alojamiento: un mejor alojamiento implica un procesamiento más rápido, mejor velocidad de red y más y más rápida memoria del servidor. Un alojamiento costoso no siempre equivale a un mejor alojamiento. Muchas actualizaciones en servicios de alojamiento compartido solo te dan más almacenamiento, no más potencia de CPU.

No recomiendo cambiar de alojamiento sin conocer las causas raíz de los problemas de TTFB. Te aconsejo que configures el seguimiento RUM y añadas encabezados Server-Timing.

Cuando actualizas tu alojamiento, generalmente deberías buscar al menos una de estas tres mejoras:

• Obtener más recursos (CPU + RAM): Especialmente cuando el servidor tarda demasiado en generar el HTML dinámico.
• DNS más rápido: Muchos proveedores de alojamiento de bajo presupuesto son notorios por su pobre rendimiento DNS.
• Mejor configuración: Busca cifrados SSL más rápidos, HTTP/3, compresión Brotli y acceso a la configuración del servidor web (para deshabilitar módulos innecesarios), por nombrar algunos.

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

Un Time to First Byte alto puede tener múltiples causas. Sin embargo, DNS, TCP y SSL afectan a todos los Time to First Bytes. Así que empecemos por ahí. Aunque optimizar estos tres puede no producir los mayores resultados, optimizar estos optimizará cada TTFB individual.

Acelerar DNS

CONSEJO de PageSpeed: DNS, TCP y SSL suelen ser un problema mayor cuando utilizas un host barato o cuando sirves a una audiencia global sin usar una CDN. Utiliza el seguimiento RUM para ver tu TTFB global y desglosar el TTFB en sus subpartes.

Utiliza un proveedor de DNS rápido. No todos los proveedores de DNS son tan rápidos como otros. Algunos proveedores de DNS (gratuitos) son simplemente más lentos que otros proveedores de DNS (gratuitos). Cloudflare, por ejemplo, te dará uno de los proveedores de DNS más rápidos del mundo de forma gratuita.

Aumentar el TTL de DNS. Otra forma es aumentar el valor del Time to Live (TTL). TTL es una configuración que determina cuánto tiempo se puede almacenar en caché la búsqueda. Cuanto mayor sea el TTL, menos probable es que el navegador necesite realizar otra búsqueda DNS. Es importante tener en cuenta que los ISP también almacenan en caché el DNS.

Acelerar TCP

La "parte TCP" del TTFB es la conexión inicial con el servidor web. Al conectarse, el navegador y el servidor comparten información sobre cómo se intercambiarán los datos. Puedes acelerar TCP conectándote a un servidor que esté geográficamente cerca de tu ubicación y asegurándote de que el servidor tenga suficientes recursos libres. A veces, cambiar a un servidor ligero como NGINX puede acelerar la parte TCP del TTFB. En muchos casos, usar una CDN acelerará la conexión TCP.

Acelerar SSL/TLS

Una vez que se ha realizado la conexión TCP, el navegador y el servidor necesitarán asegurar la conexión mediante cifrado. Puedes acelerar esto utilizando protocolos más rápidos, nuevos y ligeros (cifrados SSL) y estando geográficamente más cerca de tu servidor web (ya que la negociación TLS toma bastantes viajes de ida y vuelta ). Usar una CDN a menudo mejorará el tiempo de conexión SSL, ya que las CDNs suelen estar muy bien configuradas y tienen múltiples servidores en todo el mundo. TLS 1.3 en particular está diseñado para mantener la negociación TLS lo más corta posible.

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

Almacenamiento en caché de página

Con mucho, la forma más eficiente de acelerar el Time to First Byte es servir el HTML desde la caché del servidor. Hay varias formas de implementar el almacenamiento en caché de página completa. La forma más efectiva es hacerlo directamente a nivel de servidor web con, por ejemplo, el módulo de almacenamiento en caché de NGINX o utilizando Varnish como un proxy de caché inverso.

También hay muchos complementos para diferentes sistemas CMS que almacenarán en caché páginas completas y muchos marcos SPA como Next.js tienen su propia implementación de almacenamiento en caché de página completa junto con diferentes estrategias de invalidación.

Si deseas implementar tu propio almacenamiento en caché, la idea básica es simple. Cuando un cliente solicita una página, verifica si existe en la carpeta de caché. Si no existe, crea la página, escríbela en la caché y muestra la página como lo harías normalmente. En cualquier solicitud siguiente a la página, el archivo de caché existirá y podrás servir la página directamente desde la caché.

Almacenamiento en caché parcial

Con el almacenamiento en caché parcial, la idea es almacenar en caché partes de la página o recursos (como llamadas a API, resultados de bases de datos) de uso frecuente, lentos o costosos para una recuperación rápida. Esto eliminará los cuellos de botella al generar una página. Si estás interesado en este tipo de optimizaciones, deberías buscar estos conceptos: 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

A veces, la página no se puede servir desde la caché (parcial) porque el archivo de caché no existe, grandes partes de las páginas son dinámicas o porque te encuentras con otros problemas. Es por eso que necesitamos optimizar el código de la aplicación. Cómo se hace esto depende completamente de tu aplicación. Se basa en reescribir y optimizar las partes lentas de tu código.

Optimizar consultas de base de datos

La mayoría de las veces, las consultas de base de datos ineficaces son la causa raíz de un Time to First Byte lento. Comienza registrando "consultas lentas" y "consultas que no usan índices" en el disco. Analízalas, añade índices o pide a un experto que realice ajustes en la base de datos para solucionar estos problemas. Consulta MongoDB Performance Advisor y MySQL Slow Query Log para obtener más detalles.

Reducir la latencia de red interna

Una mala práctica con la que me encuentro más veces de las que me gustaría es un retraso en el Time to First Byte causado por la lentitud en la comunicación entre la aplicación web y el almacenamiento de datos. Esto generalmente solo ocurre con sitios grandes que han subcontratado su almacenamiento de datos a APIs en la nube.

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

Almacenamiento en caché del lado del cliente

El almacenamiento en caché del lado del cliente implica que el navegador del usuario almacene recursos a los que ya ha accedido, como imágenes y scripts. Entonces, cuando el usuario regresa a tu sitio web, su navegador puede recuperar rápidamente los recursos almacenados en caché en lugar de tener que descargarlos nuevamente. Esto puede reducir significativamente el número de solicitudes realizadas al servidor, lo que a su vez puede reducir el TTFB.

Para implementar el almacenamiento en caché del lado del cliente, puedes usar el encabezado HTTP Cache-Control. Este encabezado te permite especificar cuánto tiempo el navegador debe almacenar en caché un recurso en particular.

Podrías considerar almacenar completamente en caché el HTML de la página en el lado del cliente. Esto reducirá drásticamente el TTFB ya que no se necesita ninguna solicitud al servidor. La desventaja es que una vez que la página está en la caché del navegador, cualquier actualización en la versión en vivo de la página no será vista por el usuario hasta que expire la caché de la página.

Service Workers

Los service workers son scripts que se ejecutan en segundo plano en el navegador de un usuario y pueden interceptar solicitudes de red realizadas por el navegador. Esto significa que los service workers pueden almacenar en caché recursos como HTML, imágenes, scripts y hojas de estilo, para que cuando el usuario regrese a tu sitio web, su navegador pueda recuperar rápidamente los recursos almacenados en caché en lugar de tener que descargarlos nuevamente.

Prefetching de página

Si no deseas usar la Speculation Rules API debido a su limitado soporte de navegador, podrías usar un pequeño script llamado quicklink. Esto hará prefetch de todos los enlaces en la ventana gráfica visible y prácticamente eliminará el Time To First Byte para estos enlaces.

La desventaja de quicklink es que requiere más recursos del navegador, pero por ahora superará a la Speculation Rules API en términos de cobertura del navegador.

Cómo mejorar el TTFB: aprovechar una CDN

Una Content Delivery Network o CDN utiliza una red distribuida de servidores para entregar recursos a los usuarios. Estos servidores suelen estar geográficamente más cerca de los usuarios finales y altamente optimizados para la velocidad. Si estás usando Cloudflare, consulta nuestra guía sobre cómo configurar Cloudflare para un rendimiento óptimo de Core Web Vitals.

TTFB con una CDN y almacenamiento en caché en el borde

TTFB sin una CDN, alojado en Alemania

Una CDN puede ayudar a mejorar 5 de las 6 partes del Time to First Byte:

• Tiempo de redirección: La mayoría de las CDNs pueden almacenar en caché las redirecciones en el borde o usar edge workers para manejar las redirecciones sin la necesidad de conectarse al servidor de origen.
• Tiempo de búsqueda DNS: La mayoría de las CDNs ofrecen servidores DNS extremadamente rápidos que probablemente superarán a tus servidores DNS actuales.
• Tiempo de conexión TCP y Handshake SSL: La mayoría de las CDNs están configuradas extremadamente bien y estas configuraciones, junto con la mayor proximidad a los usuarios finales, acelerarán el tiempo de conexión y handshake.
• Respuesta del servidor: Las CDNs pueden acelerar el tiempo de respuesta del servidor de un par de maneras. La primera es almacenando en caché la respuesta del servidor en el borde (almacenamiento en caché de página completa en el borde), pero también ofreciendo una excelente compresión (Brotli) y los protocolos más nuevos (HTTP/3).

Cómo mejorar el TTFB: evitar redirecciones

El tiempo de redirección se añade al Time To First Byte. Por lo tanto, como regla general, evita las redirecciones tanto como sea posible. Las redirecciones pueden ocurrir cuando un recurso ya no está disponible en una ubicación pero se ha movido a otra ubicación. El servidor responderá con un encabezado de respuesta de redirección y el navegador intentará esa nueva ubicación.

Redirecciones del mismo origen. Las redirecciones del mismo origen se originan a partir de enlaces en tu propio sitio web. Deberías tener control total sobre estos enlaces y deberías priorizar la corrección de estos enlaces cuando trabajes en el Time to First Byte. Hay muchas herramientas que te permitirán verificar todo tu sitio web en busca de redirecciones.

Redirecciones de origen cruzado. Las redirecciones de origen cruzado se originan a partir de enlaces en otros sitios web. Tienes muy poco control sobre estos.

Redirecciones múltiples. Las redirecciones múltiples o cadenas de redirección ocurren cuando una sola redirección no redirige a la ubicación final del recurso. Estos tipos de redirecciones ejercen más presión sobre el Time to First Byte y deben evitarse a toda costa. Nuevamente, usa una herramienta para encontrar estos tipos de redirecciones y corregirlos.

Redirecciones de HTTP a HTTPS. Una forma de evitar esto es usar el encabezado Strict-Transport-Security (HSTS), que forzará HTTPS en la primera visita a un origen, y luego le dirá al navegador que acceda inmediatamente al origen a través del esquema HTTPS en futuras visitas.

Cuando un usuario solicita una página web, el servidor puede responder con una redirección a otra página. Esta redirección puede añadir tiempo adicional al TTFB porque el navegador debe realizar una solicitud adicional a la nueva página.

Hay varias formas de evitar redirecciones o minimizar el impacto de las redirecciones:

1. Actualiza tus enlaces internos. Siempre que cambies la ubicación de una página, actualiza tus enlaces internos a esa página para asegurarte de que no queden referencias a la ubicación anterior de la página.
2. Maneja las redirecciones a nivel de servidor.
3. Usa URLs relativas: Al enlazar a páginas en tu propio sitio web, usa URLs relativas en lugar de URLs absolutas. Esto ayudará a prevenir redirecciones innecesarias.
4. Usa URLs canónicas: Si tienes múltiples páginas con contenido similar, usa una URL canónica para indicar la versión preferida de la página. Esto ayudará a prevenir contenido duplicado y redirecciones innecesarias.
5. Usa redirecciones 301: Si debes usar una redirección, usa una redirección 301 en lugar de una redirección 302. Una redirección 301 es una redirección permanente, mientras que una redirección 302 es una redirección temporal. Usar una redirección 301 ayudará a prevenir redirecciones innecesarias.

Optimizar la priorización de recursos junto con el TTFB

Reducir el TTFB es solo una parte de la historia del rendimiento de carga. Una vez que llega el primer byte, el navegador necesita saber qué recursos priorizar. Lee nuestra guía sobre priorización de recursos para aprender cómo las pistas fetchpriority, preload y preconnect funcionan junto con un TTFB rápido para ofrecer las cargas de página más rápidas posibles. Además, considera auto-alojar tus Google Fonts para eliminar las búsquedas DNS de terceros y los tiempos de conexión que se suman al TTFB percibido por tus usuarios.

Lo que muestran los datos de TTFB del mundo real

Los siguientes datos provienen de CoreDash Real User Monitoring y del HTTP Archive Web Almanac 2024 (datos de CrUX, junio de 2024).

La variación geográfica es enorme

El TTFB varía dramáticamente según la distancia física entre el usuario y el servidor. Los datos de CoreDash de corewebvitals.io (alojado en Europa) ilustran esto claramente:

Los usuarios europeos cerca del servidor ven un TTFB por debajo de 170ms, mientras que los usuarios en India experimentan un TTFB 3 veces mayor y los usuarios en China ven un TTFB casi 10 veces mayor (1,468ms) debido al Gran Cortafuegos y la gran distancia física. Estos datos demuestran por qué una CDN con ubicaciones de borde globales es esencial para audiencias internacionales.

El prerenderizado de Speculation Rules ofrece un TTFB de 0ms

Los datos de tipo de navegación de CoreDash confirman que las páginas pre-renderizadas a través de Speculation Rules logran un p75 TTFB de 0 milisegundos. Las navegaciones estándar miden 131ms, las recargas llegan a 82ms (beneficiándose de conexiones calientes) y las navegaciones atrás-adelante son las más lentas con 244ms. Esto convierte a las Speculation Rules en la técnica más efectiva para eliminar el TTFB en cargas de página posteriores.

El TTFB móvil es 2.5 veces el de escritorio

En corewebvitals.io, los usuarios móviles experimentan un p75 TTFB de 316ms en comparación con 124ms en escritorio. Esta brecha de 2.5x es causada por la latencia de la red móvil, no por diferencias del servidor. Solo el 88.5% de las cargas de página móvil logran una calificación de TTFB "buena" en comparación con el 96.1% en escritorio. Al optimizar para TTFB, prueba siempre en redes móviles reales.

Los visitantes nuevos vs. recurrentes ven un TTFB similar

En este sitio, los nuevos visitantes ven un p75 TTFB de 127ms mientras que los visitantes recurrentes ven 138ms. La similitud sugiere que el almacenamiento en caché consistente del lado del servidor (en lugar de las ventajas de la caché del lado del cliente) es el factor principal en el rendimiento del TTFB. En sitios sin almacenamiento en caché del lado del servidor, la brecha entre visitantes nuevos y recurrentes puede ser mucho mayor.

El TTFB global se ha estancado durante 5 años

Según el HTTP Archive Web Almanac 2024, solo el 42% de las páginas móviles logran una puntuación TTFB "buena" a nivel mundial. Este número apenas ha cambiado del 41% en 2021, lo que convierte al TTFB en la métrica de rendimiento más estancada en la web. Mientras tanto, el LCP mejoró del 44% al 59% y el INP del 55% al 74% durante el mismo período. Los sitios con un LCP deficiente gastan un promedio de 2.27 segundos solo en TTFB, casi el umbral completo de 2.5 segundos del LCP.

Profundizaciones relacionadas: Subpartes del TTFB

Cada subparte del Time to First Byte tiene sus propias estrategias de optimización. Explora estas profundizaciones para obtener orientación específica:

• Corregir e Identificar Problemas de TTFB: Una guía de diagnóstico paso a paso para encontrar la causa raíz de un TTFB lento utilizando DevTools, Server-Timing y datos RUM.
• Reducir la Duración de Espera: Cómo minimizar el tiempo de redirección y los retrasos de procesamiento del servidor que se suman a tu TTFB.
• Reducir la Duración de la Caché: Estrategias para el almacenamiento en caché del navegador, service workers y caché de atrás/adelante (bfcache) para eliminar el TTFB para visitantes recurrentes.
• Minimizar la Duración de DNS: Cómo acelerar la resolución de DNS con proveedores de DNS más rápidos, valores TTL aumentados y pistas de recursos dns-prefetch.
• Optimizar la Duración de la Conexión (TCP + TLS): Reducir el tiempo de handshake TCP y TLS con HTTP/3, TLS 1.3, reanudación de sesión y pistas preconnect.