Reducir TTFB 2026: Early Hints y Edge SSR

Actualizado: 11 de junio de 2026

Para reducir el TTFB en 2026 hay que actuar en tres frentes: acortar la distancia entre usuario y origen con edge rendering, eliminar el tiempo muerto del navegador con Early Hints (HTTP 103) y aprovechar el streaming SSR para que el primer byte salga antes de que termine la consulta a la base de datos. El umbral de Google sigue siendo 800 ms como "bueno", pero en proyectos competitivos hoy apuntamos a menos de 200 ms en P75. En esta guía verás cómo lograrlo, con código real y mediciones reproducibles.

Honestamente, la primera vez que apliqué Early Hints en un e-commerce europeo que servía tráfico a México me sorprendió ver el LCP caer 320 ms sin tocar una sola línea del backend. Desde entonces es lo primero que reviso en cualquier auditoría.

Un TTFB inferior a 200 ms en P75 es alcanzable combinando edge SSR, Early Hints 103 y caché en CDN con stale-while-revalidate.
Early Hints (HTTP 103) permiten enviar Link: rel=preload/preconnect antes del 200 OK, ganando entre 100 y 400 ms de paralelización en el navegador.
El header Server-Timing es la única forma estándar de atribuir cuánto tiempo se va en DB, render y red, y se ve en DevTools sin instrumentar.
Streaming SSR con renderToReadableStream de React 19 desacopla el primer byte del tiempo de hidratación de datos.
Cloudflare, Fastly y Vercel soportan 103 Early Hints en producción; Chrome 121+ y Safari 18 ya los consumen.
RUM con PerformanceObserver y la API navigationStart→responseStart son obligatorios: el TTFB de laboratorio miente.

Qué es el TTFB y qué se considera "bueno" en 2026

El Time to First Byte (TTFB) es el intervalo entre que el navegador envía la petición y recibe el primer byte de la respuesta. Lo define la especificación Navigation Timing Level 2 como responseStart - startTime. Engloba la resolución DNS, el handshake TCP/TLS, la latencia hasta el servidor (RTT), el tiempo de procesamiento backend y el de retorno hasta el cliente. No es un Core Web Vital propio, pero es el techo de los demás: si el TTFB es de 1,5 s, tu LCP nunca bajará de ahí.

Google clasifica el TTFB en tres tramos. ≤ 800 ms es "bueno", entre 800 ms y 1,8 s "necesita mejorar" y por encima de 1,8 s "deficiente", siempre medido en el percentil 75 de tu base de usuarios reales. En 2026 esa cifra de 800 ms ya queda lejos de lo que entrega un sitio bien arquitecturado: con edge rendering y CDN agresiva, sitios como Vercel, Shopify Hydrogen o Cloudflare Workers publican P75 entre 80 y 180 ms. Si vienes de un origen único en una región (típico de WordPress sobre un VPS), tu primer salto cualitativo será mover el HTML al edge.

Conviene recordar que el TTFB no es lo mismo que el FCP. El FCP necesita que el navegador parse el HTML inicial, descubra CSS bloqueante y pinte algo. Por eso un TTFB de 100 ms con CSS crítico sin inlinear puede convivir con un FCP de 1,2 s. Son problemas distintos y técnicas distintas, aunque suelen confundirse.

Cómo medir el TTFB correctamente

Medir TTFB con Lighthouse desde una conexión doméstica te da un número, pero no tu número. Necesitas RUM (Real User Monitoring) porque el TTFB depende mucho de la geografía, la red móvil y el estado de caché del CDN en cada PoP. La forma estándar y barata de hacerlo es con PerformanceObserver en el cliente:

// Captura TTFB real del usuario y lo envia a tu endpoint
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType !== 'navigation') continue;
    const ttfb = entry.responseStart - entry.startTime;
    const dns  = entry.domainLookupEnd - entry.domainLookupStart;
    const tcp  = entry.connectEnd - entry.connectStart;
    const wait = entry.responseStart - entry.requestStart;

    navigator.sendBeacon('/rum', JSON.stringify({
      ttfb, dns, tcp, wait,
      url: location.pathname,
      connection: navigator.connection?.effectiveType,
      cacheHit: entry.transferSize === 0, // bfcache
    }));
  }
}).observe({ type: 'navigation', buffered: true });

Para un baseline rápido desde terminal, usa curl con --write-out:

curl -o /dev/null -s -w \
  "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  https://tu-sitio.com/

Ejecuta esto contra distintos PoPs (por ejemplo desde un VPS en Frankfurt, otro en São Paulo y otro en Singapur) para ver si tu TTFB es estable o si depende de la región. Si la diferencia entre PoPs supera 300 ms, el problema no es backend, es geografía, y la solución pasa por caché en CDN o edge rendering.

Early Hints (HTTP 103): la mayor ganancia gratis

Las Early Hints son una respuesta provisional con código 103, definida en RFC 8297, que el servidor envía antes del 200 OK final. Su utilidad es enviar Link: <...>; rel=preload y rel=preconnect mientras el backend todavía está calculando la respuesta. El navegador empieza a abrir conexiones y descargar recursos críticos durante esos cientos de milisegundos que de otra forma están muertos.

En un Next.js con App Router sobre Vercel, las Early Hints se emiten automáticamente desde la versión 14.1. Para Express o Fastify detrás de un CDN compatible, se hace a mano:

// Express + Node 22: envia 103 antes de la respuesta final
app.get('/', (req, res) => {
  // 1. Hint temprano: el navegador empieza preload y preconnect ya
  res.writeEarlyHints({
    link: [
      '</css/critical.css>; rel=preload; as=style',
      '</fonts/inter-var.woff2>; rel=preload; as=font; crossorigin',
      '<https://cdn.misitio.com>; rel=preconnect',
    ],
  });

  // 2. Render normal: tarda 400 ms, pero el navegador ya descargo la CSS
  renderPage(req).then((html) => res.send(html));
});

En nuestras pruebas en producción con un e-commerce de origen único en EU sirviendo a usuarios en LATAM, las Early Hints redujeron el LCP medio en 320 ms sin tocar el backend. La razón es simple: el RTT EU↔LATAM es de ~180 ms, así que cada round-trip que el navegador puede paralelizar con el render backend es oro puro.

Edge SSR y streaming con React 19

El edge rendering desplaza la generación HTML desde un servidor centralizado a workers ejecutándose en el PoP del CDN más cercano al usuario. Cloudflare Workers, Vercel Edge Functions, Fastly Compute@Edge y Deno Deploy ofrecen latencias de cold start por debajo de 5 ms y RTT al usuario en torno a 20–50 ms. Combinado con streaming SSR de React 19, el primer byte sale en cuanto el shell está listo, sin esperar a las queries de datos.

// app/page.tsx: Next.js 15 con streaming nativo
import { Suspense } from 'react';
import { ProductList } from './ProductList';
import { Skeleton } from './Skeleton';

export const runtime = 'edge'; // ejecuta en el PoP mas cercano

export default function HomePage() {
  return (
    <main>
      <h1>Catalogo</h1>
      {/* El shell se envia en el primer byte */}
      <Suspense fallback={<Skeleton />}>
        {/* Esta consulta puede tardar 300 ms; no bloquea el TTFB */}
        <ProductList />
      </Suspense>
    </main>
  );
}

Con esta configuración, el TTFB observado del usuario corresponde solo al tiempo de generar el shell y abrir el primer chunk del stream. La consulta lenta se entrega cuando esté lista, dentro del mismo stream HTTP, sin un segundo round-trip. Si combinas esta técnica con la Speculation Rules API para navegación instantánea, los usuarios perciben tiempos de respuesta cercanos a cero entre páginas.

Caché en CDN con stale-while-revalidate

Si tu contenido tolera 60 segundos de desactualización, no hay técnica más efectiva que servirlo desde caché de CDN. El truco moderno es combinar s-maxage con stale-while-revalidate. El CDN responde inmediatamente con la versión cacheada (TTFB ≈ 30 ms) y regenera en segundo plano sin penalizar al usuario.

// Respuesta del origen: header de cache
Cache-Control: public, s-maxage=60, stale-while-revalidate=86400

// Significado:
// - El CDN sirve la version fresca durante 60 s
// - Entre 60 s y 24 h, sirve la version vieja Y revalida en background
// - Solo el primer usuario tras la expiracion paga el coste del origen

Estrategia	TTFB típico (P75)	Frescura	Coste origen
Origen único, sin caché	600–1500 ms	Tiempo real	Alto
CDN `max-age` agresivo	30–80 ms	Hasta TTL	Mínimo
CDN `stale-while-revalidate`	30–80 ms	≤60 s para todos menos uno	Bajo
Edge SSR + streaming	80–180 ms	Tiempo real	Medio
ISR (revalidación bajo demanda)	30–80 ms (HIT) / 200 ms (MISS)	Por evento	Mínimo

Para contenido autenticado o personalizado, no descartes la caché. Usa Vary: Cookie con cuidado o, mejor, separa el shell (cacheable) de los datos personales (vía fetch post-load). Es la misma filosofía que vimos en nuestra guía de optimización de imágenes para LCP: separar lo crítico de lo demorable.

Atribuir el TTFB con Server-Timing

Cuando el TTFB sube y no sabes por qué, el header Server-Timing es la herramienta más útil que existe. Define métricas con nombre que aparecen directamente en la pestaña Network de DevTools, sin instrumentación de cliente. Si lo expones en producción, también puede leerse desde PerformanceServerTiming en JavaScript para enviarlo a tu RUM. La documentación de MDN tiene la referencia completa de la sintaxis.

// Express middleware que mide DB, render y total
app.use(async (req, res, next) => {
  const t0 = performance.now();
  const t1 = performance.now();
  const data = await db.query('SELECT ...');
  const tDb = performance.now() - t1;

  const t2 = performance.now();
  const html = await render(data);
  const tRender = performance.now() - t2;

  res.setHeader('Server-Timing',
    `db;dur=${tDb.toFixed(1)}, ` +
    `render;dur=${tRender.toFixed(1)}, ` +
    `total;dur=${(performance.now() - t0).toFixed(1)}`
  );
  res.send(html);
});

Una vez tienes esta visibilidad, los problemas saltan a la vista. Un db;dur=420 apunta a una query N+1 o a falta de índice; un render;dur=180 con un árbol pequeño sugiere un useMemo mal puesto o un JSON serializando algo gigante; un total alto sin desglose alto indica latencia de red al backend. Sin Server-Timing, terminas adivinando.

Errores comunes que disparan el TTFB

En auditorías reales (he hecho bastantes este último año), estos son los cinco patrones que más empeoran el TTFB en proyectos por lo demás bien optimizados:

Redirects 301 en cadena. Cada salto añade un RTT completo. Verifica con curl -IL: si tu landing principal hace http:// → https:// → www., estás pagando 300 ms gratis. Configura el redirect final en el edge.
Cookies de tracking en el HTML inicial. Si tu Set-Cookie contiene un ID de sesión por petición, el CDN no puede cachear. Mueve esa lógica a un fetch post-render.
Falta de HTTP/3. Sobre redes móviles inestables, HTTP/3 (QUIC) evita el head-of-line blocking de TCP y reduce TTFB en P95 entre 80 y 200 ms. Está disponible en Cloudflare, Fastly, Vercel y nginx 1.25+.
Conexiones de base de datos sin pooling. Abrir una conexión TCP+TLS a Postgres por petición cuesta 50–150 ms. Usa PgBouncer, el Neon HTTP driver, o un pooler como Hyperdrive.
SSR sin streaming. Si tu renderToString espera a todas las queries antes de emitir un byte, estás multiplicando latencias. Cambia a renderToPipeableStream o renderToReadableStream.

Para el caso particular del CLS y otros vitals afectados cuando el TTFB es alto, revisa también nuestra guía para eliminar layout shifts en 2026. Un TTFB lento amplifica los shifts visibles porque retrasa el primer paint informativo.

Preguntas frecuentes

¿Qué es un buen TTFB en 2026?

Google considera "bueno" un TTFB ≤ 800 ms en el percentil 75 de usuarios reales. Sin embargo, los sitios punteros en 2026 alcanzan P75 entre 80 y 180 ms combinando edge rendering, CDN con stale-while-revalidate y HTTP/3. Por debajo de 200 ms es un objetivo realista y competitivo.

¿Las Early Hints (HTTP 103) reducen realmente el TTFB?

Las Early Hints no bajan el TTFB del 200 OK, pero adelantan la descarga de recursos críticos (CSS, fuentes, conexiones a CDNs) durante el tiempo de procesamiento del servidor. El efecto neto es un LCP entre 100 y 400 ms más rápido, equivalente a haber bajado el TTFB esa cantidad para los recursos preload.

¿Cuál es la diferencia entre TTFB y FCP?

El TTFB mide cuándo llega el primer byte del HTML al navegador; el FCP mide cuándo el navegador pinta algo de ese HTML. Un TTFB rápido no garantiza un FCP rápido si el HTML descarga CSS bloqueante o ejecuta scripts síncronos antes del primer pintado.

¿Cómo reduzco el TTFB en WordPress?

Pon Cloudflare o Fastly delante con caché de página completa y stale-while-revalidate, activa OPcache y un object cache (Redis), elimina plugins lentos que se ejecuten en init, y usa HTTP/3. Para contenido logueado, usa fragmentos cacheables con ESI o edge personalization.

¿Edge SSR siempre mejora el TTFB?

No siempre. Si tu base de datos sigue en una región única, el worker edge tendrá que cruzar el océano para cada query y el TTFB puede empeorar. Edge SSR brilla cuando los datos también están replicados al edge (D1, Turso, KV) o cuando el contenido es cacheable.