Tiempo de respuesta del servidor

Qué comprueba esta verificación

Mide cuánto tarda el servidor en devolver el primer byte del documento HTML — el TTFB. El reloj empieza cuando el rastreador de MetricSpot envía la petición y se detiene cuando llega el primer byte de respuesta. DNS, TCP, TLS y el procesamiento del servidor están todos incluidos.

La verificación pasa por debajo de 800 ms (umbral “bueno” de web.dev) y avisa por encima de 1,8 s.

Por qué importa

El TTFB es un techo para cualquier otro Core Web Vital. El Largest Contentful Paint (LCP) no puede bajar de TTFB + tiempo de renderizado — si tu servidor tarda 2 segundos en responder, tu LCP es matemáticamente de al menos 2 segundos, por muy rápido que sea tu CSS o por muy agresiva que sea la optimización de imágenes. El umbral de “buen LCP” de Google es de 2,5 s; un TTFB de 2 s te deja 500 ms para todo lo demás.

Un TTFB lento suele apuntar a una de cuatro cosas: una función serverless en frío, una consulta a base de datos en la ruta de la petición, falta de caché en el edge, o un CMS haciendo trabajo que no debería (WordPress sin object cache es el clásico).

Cómo arreglarlo

Encuentra primero el cuello de botella. Añade cabeceras Server-Timing para ver dónde se va el tiempo:

Server-Timing: db;dur=420, render;dur=180, total;dur=620

Después ataca la etapa que sea más grande.

Cachea el HTML en el edge. Una respuesta estática o cacheada a nivel de página debería servirse en 20-100 ms desde el POP más cercano, no en 800 ms desde tu origen.

# nginx — micro-cache dynamic pages for 60s
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=html:50m max_size=1g inactive=10m;

location / {
  proxy_cache html;
  proxy_cache_valid 200 60s;
  proxy_cache_use_stale updating error timeout;
  proxy_cache_lock on;
  proxy_pass http://app;
}

Cloudflare: activa “Cache Everything” mediante una Cache Rule para HTML, y luego sirve Cache-Control: s-maxage=60, stale-while-revalidate=600 desde tu origen. La magia está en stale-while-revalidate — Cloudflare sirve la copia caducada al instante y la refresca en segundo plano.

Caddy:

example.com {
  reverse_proxy localhost:3000
  header Cache-Control "public, max-age=0, s-maxage=60, stale-while-revalidate=600"
}

Next.js (App Router): prioriza la generación estática. Si una página es dinámica, configura el segmento de ruta:

export const revalidate = 60; // ISR
export const dynamic = "force-static"; // when possible

Para server components que tocan una base de datos, envuelve el fetch en unstable_cache o usa fetch(url, { next: { revalidate: 60 } }).

Bun / Node: las victorias habituales son (a) usar pool de conexiones a la base de datos (pg.Pool, no un cliente nuevo por petición), (b) evitar consultas N+1 — un JOIN gana a 50 idas y vueltas, (c) precalcular todo lo que puedas en build time, (d) servir la respuesta con gzip/brotli.

WordPress: instala un object cache persistente (Redis vía el plugin Redis Object Cache) y un page cache (WP Super Cache, W3 Total Cache o LiteSpeed Cache). Una instalación pelada de WP sin caché suele tardar entre 1 y 3 s por petición; con ambas cachés activas baja por debajo de 200 ms.

Base de datos: añade el índice que falta. Ejecuta EXPLAIN ANALYZE sobre la consulta más lenta de la ruta de tu petición; si dice Seq Scan, te falta un índice. Un solo índice ausente puede ser todo el problema de TTFB.

Latencia geográfica: si tu origen está en Frankfurt y tus visitantes están en Singapur, ninguna optimización de servidor arreglará los 180 ms de ida y vuelta. Pon un CDN delante del HTML (no sólo de las imágenes).

Una vez que el TTFB esté sano, trabaja en Largest Contentful Paint e Interaction to Next Paint — están aguas abajo del TTFB y revelan problemas del lado del cliente.

Preguntas frecuentes

¿Es el TTFB un Core Web Vital?

No. El TTFB es una métrica aguas arriba — Google no la usa como señal de ranking directamente. Pero es el suelo del LCP, que sí es señal de ranking. Un TTFB malo garantiza un LCP malo.

¿Por qué MetricSpot mide un TTFB distinto al de PageSpeed Insights?

Puntos de medición diferentes. MetricSpot mide desde nuestro rastreador en un único centro de datos. PSI usa datos de campo (Chrome User Experience Report) cuando están disponibles, que son usuarios reales en todo el mundo y en redes reales. Los datos de campo son la verdad; los de laboratorio son el diagnóstico.

Mi TTFB está bien para la home pero mal para las páginas de producto, ¿por qué?

Lo más probable es que la home esté cacheada y las páginas de producto no. O extiendes la caché de página a las URLs de producto (con un TTL corto y purga al cambiar el inventario), o precalculas las páginas de producto en build time vía ISR / revalidación bajo demanda.