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
| Fase | Qué pasa | Share típico |
|---|---|---|
| DNS lookup | Resolver dominio a IP | 0-100ms |
| Conexión TCP | Handshake 3-way | ~1 RTT |
| Negociación TLS | Handshake SSL | 1-2 RTTs |
| Request enviado | HTTP request | Trivial |
| Procesamiento servidor | App + database | 0-2000+ ms |
| Primer byte llega | Transfer red back | 1 RTT |
Thresholds TTFB
| TTFB | Rating |
|---|---|
| ≤ 800ms | Bueno |
| 800ms - 1800ms | Necesita mejora |
| > 1800ms | Pobre |
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.comHerramientas
| Tool | Tipo |
|---|---|
| Lighthouse / PageSpeed Insights | Lab |
| Chrome DevTools Network | Lab |
| WebPageTest | Lab desde múltiples regiones |
| web-vitals.js | RUM |
| Search Console CWV report | Field |
| CrUX Dashboard | Field, público |
| Logs servidor | Server-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.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.