Temps de resposta del servidor

Què comprova aquesta auditoria

Cronometra quant triga el servidor a retornar el primer byte del document HTML: el TTFB. El rellotge comença quan el crawler de MetricSpot envia la petició i s’atura quan arriba el primer byte de la resposta. DNS, TCP, TLS i el processament del servidor estan inclosos.

La comprovació passa per sota de 800 ms (el llindar “bo” de web.dev) i avisa per sobre d’1,8 s.

Per què importa

El TTFB és un sostre per a tots els altres Core Web Vitals. El Largest Contentful Paint (LCP) no pot superar el TTFB + temps de renderitzat: si el teu servidor triga 2 segons a respondre, l’LCP és matemàticament d’almenys 2 segons, no importa com de ràpid sigui el teu CSS o com d’agressiva sigui la teva optimització d’imatges. El llindar “bo de LCP” de Google és 2,5 s; un TTFB de 2 s et deixa 500 ms per a tota la resta.

Un TTFB lent sol apuntar a una de quatre coses: una funció serverless en fred, una consulta a base de dades al camí de petició, falta de caché a l’edge, o un CMS fent feina que no hauria de fer (WordPress sense object cache és el clàssic).

Com solucionar-ho

Troba primer el coll d’ampolla. Afegeix capçaleres Server-Timing per veure on va el temps:

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

Després ataca l’etapa més gran.

Cacheja l’HTML a l’edge. Una resposta estàtica o cachejada a nivell de pàgina hauria de servir-se en 20-100 ms des del POP més proper, no en 800 ms des del teu origen.

# nginx, micro-cache de pàgines dinàmiques durant 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” via una Cache Rule per a HTML, i posa Cache-Control: s-maxage=60, stale-while-revalidate=600 des del teu origen. El stale-while-revalidate és la màgia: Cloudflare serveix la còpia antiga a l’instant i la refresca en segon pla.

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): prefereix la generació estàtica. Si una pàgina és dinàmica, configura el segment de ruta:

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

Per a server components que toquen una BBDD, embolcalla el fetch amb unstable_cache o fes servir fetch(url, { next: { revalidate: 60 } }).

Bun / Node: les victòries habituals són (a) connection-pool a la teva BBDD (pg.Pool, no un client nou per petició), (b) evita consultes N+1, un JOIN bat 50 round-trips, (c) precalcula tot el que puguis al build, (d) gzip/brotli a la resposta.

WordPress: instal·la un object cache persistent (Redis via el plugin Redis Object Cache) i una caché de pàgina (WP Super Cache, W3 Total Cache o LiteSpeed Cache). Un WP vanilla sense caché triga rutinàriament 1-3 s per petició; amb totes dues cachés activades baixa per sota de 200 ms.

Base de dades: afegeix l’índex que falta. Executa EXPLAIN ANALYZE sobre la consulta més lenta del teu camí de petició; si diu Seq Scan, necessites un índex. Un sol índex que falta pot ser tot el problema de TTFB.

Latència geogràfica: si el teu origen és a Frankfurt i els teus visitants a Singapur, cap quantitat d’optimització del servidor arreglarà el round-trip de 180 ms. Posa una CDN davant de l’HTML (no només d’imatges).

Un cop el TTFB sigui sa, treballa el Largest Contentful Paint i l’Interaction to Next Paint: són downstream del TTFB i revelen problemes al costat client.

Preguntes freqüents

El TTFB és un Core Web Vital?

No. El TTFB és una mètrica upstream, Google no la fa servir directament com a senyal de posicionament. Però és el sòl per a l’LCP, que sí que ho és. Un mal TTFB garanteix un mal LCP.

Per què MetricSpot mesura un TTFB diferent del de PageSpeed Insights?

Punts de mesura diferents. MetricSpot mesura des del nostre crawler en un sol datacenter. PSI fa servir dades de camp (Chrome User Experience Report) quan estan disponibles, que són usuaris reals d’arreu del món en xarxes reals. Les dades de camp són la veritat; les de laboratori són el diagnòstic.

El meu TTFB està bé per a l’home però malament per a les pàgines de producte, per què?

L’home probablement està cachejada i les pàgines de producte no. O bé estén la caché de pàgina a les URLs de producte (amb un TTL curt i invalidació en canvi d’inventari), o precalcula les pàgines de producte al build via ISR / revalidació on-demand.