Tempo di risposta del server

Cosa verifica questo controllo

Misura quanto tempo impiega il server a restituire il primo byte del documento HTML — TTFB. Il cronometro parte quando il crawler di MetricSpot invia la richiesta e si ferma quando arriva il primo byte di risposta. DNS, TCP, TLS e l’elaborazione del server sono tutti inclusi.

Il controllo passa sotto gli 800 ms (la soglia “buona” di web.dev) e avverte oltre 1,8 s.

Perché è importante

Il TTFB è un soffitto per ogni altro Core Web Vital. Il Largest Contentful Paint (LCP) non può battere TTFB + tempo di render — se il tuo server impiega 2 secondi a rispondere, il tuo LCP è matematicamente almeno 2 secondi, indipendentemente da quanto sia veloce il tuo CSS o aggressiva l’ottimizzazione delle immagini. La soglia “LCP buono” di Google è 2,5 s; un TTFB di 2 s ti lascia 500 ms per tutto il resto.

Un TTFB lento di solito indica una di quattro cose: una funzione serverless a freddo, una query di database nel path della richiesta, nessun caching edge, o un CMS che fa lavoro che non dovrebbe (WordPress senza object cache è il classico).

Come sistemarlo

Trova prima il collo di bottiglia. Aggiungi header Server-Timing per vedere dove va il tempo:

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

Poi attacca la fase più grande.

Cacha l’HTML all’edge. Una risposta statica o page-cached dovrebbe essere servita in 20-100 ms dal POP più vicino, non 800 ms dalla tua origin.

# nginx — micro-cache delle pagine dinamiche per 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: abilita “Cache Everything” tramite una Cache Rule per l’HTML, poi imposta Cache-Control: s-maxage=60, stale-while-revalidate=600 dalla tua origin. Lo stale-while-revalidate è la magia — Cloudflare serve la copia stantia istantaneamente e si aggiorna in background.

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): preferisci la generazione statica. Se una pagina è dinamica, imposta la configurazione del segmento route:

export const revalidate = 60; // ISR
export const dynamic = "force-static"; // quando possibile

Per i server component che colpiscono un DB, avvolgi la fetch in unstable_cache o usa fetch(url, { next: { revalidate: 60 } }).

Bun / Node: le vittorie tipiche sono (a) connection-pool del tuo DB (pg.Pool, non un client nuovo per richiesta), (b) evita le query N+1 — un JOIN batte 50 round-trip, (c) precalcola tutto ciò che puoi al momento della build, (d) gzip/brotli la risposta.

WordPress: installa un object cache persistente (Redis tramite il plugin Redis Object Cache) e una page cache (WP Super Cache, W3 Total Cache, o LiteSpeed Cache). Un’installazione WP vaniglia senza caching impiega routinemente 1-3 s per richiesta; con entrambe le cache abilitate scende sotto i 200 ms.

Database: aggiungi l’indice mancante. Esegui EXPLAIN ANALYZE sulla query più lenta nel path della tua richiesta; se dice Seq Scan, ti serve un indice. Un singolo indice mancante può essere l’intero problema TTFB.

Latenza geografica: se la tua origin è a Francoforte e i tuoi visitatori sono a Singapore, nessuna ottimizzazione del server può sistemare il round-trip di 180 ms. Metti una CDN davanti all’HTML (non solo alle immagini).

Una volta che il TTFB è in salute, lavora su Largest Contentful Paint e Interaction to Next Paint — sono a valle del TTFB e rivelano problemi client-side.

Domande frequenti

Il TTFB è un Core Web Vital?

No. Il TTFB è una metrica a monte — Google non la usa direttamente come segnale di posizionamento. Ma è il pavimento per l’LCP, che è un segnale di posizionamento. Un TTFB cattivo garantisce un LCP cattivo.

Perché MetricSpot misura un TTFB diverso da PageSpeed Insights?

Punti di misurazione diversi. MetricSpot misura dal nostro crawler in un singolo data center. PSI usa dati di campo (Chrome User Experience Report) quando disponibili, che sono utenti reali in tutto il mondo su reti reali. I dati di campo sono la verità; i dati di laboratorio sono la diagnostica.

Il mio TTFB è buono per la home page ma cattivo per le pagine prodotto — perché?

La home page è probabilmente in cache e le pagine prodotto no. O estendi il page caching agli URL prodotto (con un TTL breve e invalidazione al cambio inventario), o precalcola le pagine prodotto al momento della build tramite ISR / on-demand revalidation.