Time to First Byte (TTFB): Definición, Causas, Optimización

TTFB mide el tiempo desde request hasta primer byte de respuesta. Limita LCP. ≤ 800ms = bueno. Afectado por servidor, DB, red, CDN.

¿Qué es Time to First Byte (TTFB)?

Time to First Byte (TTFB) es el tiempo que tarda el navegador en recibir el primer byte de una respuesta HTTP después de enviar el request. Captura todo lo que pasa antes de que cualquier rendering pueda empezar: DNS lookup, handshake TCP, negociación TLS, procesamiento servidor, queries database y round-trip red.

TTFB es fundamental para performance percibido — cada métrica subsecuente (LCP, FCP, TTI) está acotada por ella.

Fases TTFB

FaseQué pasaShare típico
DNS lookupResolver dominio a IP0-100ms
Conexión TCPHandshake 3-way~1 RTT
Negociación TLSHandshake SSL1-2 RTTs
Request enviadoHTTP requestTrivial
Procesamiento servidorApp + database0-2000+ ms
Primer byte llegaTransfer red back1 RTT

Thresholds TTFB

TTFBRating
≤ 800msBueno
800ms - 1800msNecesita mejora
> 1800msPobre

Cómo medir TTFB

API JavaScript

new PerformanceObserver((list) => {
  for (const entry of list.getEntriesByType('navigation')) {
    const ttfb = entry.responseStart - entry.requestStart;
    console.log('TTFB:', ttfb, 'ms');
  }
}).observe({ type: 'navigation', buffered: true });

cURL

curl -w "time_starttransfer: %{time_starttransfer}\n" -o /dev/null -s https://example.com

Herramientas

ToolTipo
Lighthouse / PageSpeed InsightsLab
Chrome DevTools NetworkLab
WebPageTestLab desde múltiples regiones
web-vitals.jsRUM
Search Console CWV reportField
CrUX DashboardField, público
Logs servidorServer-side, solo fase app

Optimizaciones TTFB comunes

1. CDN con edge caching

Edge servers responden desde RAM en < 50ms. Mayor win TTFB.

2. Cachear HTML dinámico

Páginas SSR pueden frecuentemente cachearse 60s-5min en CDN.

3. Optimizar queries database

Queries N+1 lentas son el #1 killer TTFB server-side.

4. Usar HTTP/2 o HTTP/3

Elimina head-of-line blocking.

5. TLS 1.3 para handshake más rápido

1 RTT en vez de 2 para conexiones nuevas.

6. Reuse de conexión

Keep-alive + multiplexing HTTP/2.

7. Origins geo-distribuidos

Origin en us-east-1, usuarios en Sydney = 200ms+ red sola.

8. Pre-render o static generate

Si página no necesita ser dinámica.

TTFB y Core Web Vitals

  • LCP empieza midiendo desde request, así TTFB está incluido en LCP
  • Si TTFB es 1s, LCP es al menos 1s
  • Mejorar TTFB por 500ms típicamente mejora LCP por ~500ms

Pitfalls TTFB comunes

  • Origin en una región, usuarios mundialmente.
  • SSR sin caching.
  • Queries DB N+1.
  • Calls API external síncronos.
  • Cold-start funciones serverless.
  • Middleware pesado.
  • Resumption TLS deshabilitado.
  • HTTP/1.1 only.

FAQ: Time to First Byte

¿Qué es buen TTFB?

≤ 800ms en percentil 75 per Google.

¿Es TTFB un Core Web Vital?

No — INP, LCP y CLS lo son. Pero TTFB es métrica diagnóstico recomendada.

¿Cómo mejora CDN el TTFB?

Edge servers cachean respuestas cerca de usuarios.

¿Por qué mi TTFB es diferente en lab vs field?

Tests lab usan redes controladas; field mide usuarios reales.

¿HTTPS hurts TTFB?

Ligeramente — TLS añade ~1-2 RTTs. Pero TLS 1.3 minimiza costo.

¿Cómo mejoro TTFB en una página dinámica?

Cachear en CDN, optimizar queries DB, mover a edge SSR.

¿Diferencia entre TTFB y server response time?

Server response time = solo fase app/DB. TTFB = red + fase app.

Testea TTFB desde regiones reales con LoadFocus

LoadFocus corre Lighthouse + load tests desde 25+ regiones globales. Regístrate en loadfocus.com/signup.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.

×