Il TTFB (Time to First Byte) è il tempo che intercorre tra la richiesta HTTP e la ricezione del primo byte di risposta dal server. La soglia "Good" è ≤200ms, "Needs Improvement" 200-600ms, "Poor" >600ms. Per ridurlo: usa un CDN per servire dall'edge, ottimizza le query al database, implementa server-side caching, e scegli un hosting con server fisicamente vicini ai tuoi utenti. Un TTFB alto penalizza tutte le altre metriche: nessuna ottimizzazione frontend può compensare un server che risponde lentamente.
Cosa compone il TTFB: DNS, TCP, TLS, server processing
Il TTFB è la somma di più latenze: DNS lookup (quanto impiega il DNS a risolvere il dominio), TCP handshake (la connessione TCP in 3 step), TLS handshake (la negoziazione crittografica HTTPS), e server processing time (quanto il server impiega a generare la risposta). Su connessione tipica italiana le prime tre fasi insieme valgono 50-120ms. Se il TTFB è 800ms il server processing è almeno 600-700ms: questo è il problema da risolvere.
Una distinzione importante: il server processing time include tutto ciò che accade sul server prima di inviare la risposta — query al database, rendering del template, chiamate ad API esterne, autenticazione. Un sito WordPress con 30 plugin attivi può avere server processing time di 800ms anche su hardware veloce, perché esegue decine di operazioni PHP sincrone per ogni richiesta. La soluzione non è sempre un hardware migliore: spesso è un'architettura migliore.
Hosting condiviso vs VPS vs cloud: l'impatto sul TTFB
L'hosting condiviso economico (5-10€/mese) mette decine o centinaia di siti sullo stesso server: CPU e RAM condivise, niente SSD NVMe, e picchi di carico degli altri siti che rallentano il tuo. Un VPS entry-level (20-40€/mese) su provider come Hetzner o DigitalOcean offre CPU dedicata, SSD NVMe, e TTFB costantemente sotto 100ms. Il cloud managed (Vercel, Railway, Fly.io) aggiunge edge caching e deploy automatici.
I valori TTFB che misuriamo tipicamente per provider diversi da utenti italiani: Aruba Piano Starter (shared) → 800ms-1,5s. SiteGround Piano GrowBig → 400-600ms (usa server europei e object cache). Hetzner VPS CX11 con Nginx + PHP-FPM ottimizzato → 80-150ms. Vercel (Next.js SSG) → 15-30ms. Vercel (Next.js SSR) → 80-200ms. La differenza tra 1.200ms e 20ms di TTFB significa rispettivamente un LCP minimo di 2,5 secondi vs un LCP ottenibile sotto 1 secondo a parità di tutto il resto.
Database: la causa più frequente di TTFB alto
Nella maggior parte dei siti dinamici il server processing time è dominato dalle query al database. Una pagina che fa 30 query SQL (waterfall di query non ottimizzate) impiega 500ms solo di database. Soluzioni: aggiungere indici sulle colonne usate nei `WHERE` e `JOIN`, raggruppare le query N+1 con eager loading, implementare caching a livello applicativo (Redis, Memcached) per i dati che non cambiano frequentemente, e usare una connection pool per evitare l'overhead di connessione per ogni richiesta.
Il problema N+1 è la causa più frequente di database lenti in WordPress e applicazioni ORM: per caricare 10 post con i loro autori, fai 1 query per i post e poi 10 query separate per ogni autore (una per ID). La soluzione SQL è usare JOIN o IN clause per recuperare tutto in 1-2 query. In WordPress si usa `get_posts()` con `meta_query` ottimizzata invece di loop con `get_post_meta()`. In Prisma (per Next.js) si usa `include` invece di nested queries separate.
CDN e edge computing: il modo più rapido per abbassare il TTFB
Mettere una CDN davanti al server non aiuta solo con gli asset statici: con una CDN che supporta il page caching (Cloudflare, Fastly, Vercel) anche le pagine HTML vengono servite dall'edge. Per contenuto completamente statico il TTFB scende a 20-40ms indipendentemente dalla location. Per contenuto semi-dinamico lo stale-while-revalidate permette di servire dalla cache mentre l'origine aggiorna in background.
Cloudflare APO (Automatic Platform Optimization) per WordPress è uno degli strumenti più efficaci per ridurre il TTFB dei siti WordPress senza cambiare hosting: per 5$/mese, Cloudflare mette in cache le pagine HTML WordPress nell'edge network, riducendo il TTFB da 800ms a 20-30ms per gli utenti di ritorno. Non funziona per le pagine personalizzate per utente loggato (checkout, account), ma funziona perfettamente per tutte le pagine pubbliche. Nella gestione siti web lo consigliamo come primo intervento rapido prima di migrare l'hosting.
Static Site Generation e ISR: TTFB di 20ms
La tecnica più efficace per azzerare il server processing time è generare le pagine HTML a build time (SSG) invece che per ogni richiesta (SSR). Con Next.js SSG le pagine sono file HTML statici distribuiti sulla CDN: il TTFB è di 20-40ms ovunque nel mondo. ISR (Incremental Static Regeneration) aggiunge la flessibilità di aggiornare le pagine su intervalli definiti senza rebuild completo. Per i siti con contenuto che cambia raramente (landing page, blog, portfolio) è la scelta ottimale.
La scelta tra SSG, ISR e SSR dipende dalla frequenza di aggiornamento e dalla personalizzazione del contenuto. Landing page e blog: SSG puro, rebuild al cambio di contenuto. Pagine prodotto e-commerce: ISR con `revalidate: 300` (aggiorna ogni 5 minuti). Dashboard personalizzate e pagine utente loggato: SSR inevitabilmente, ma con caching selettivo degli elementi statici. News in tempo reale: ISR con `revalidate: 60` o SSR con cache CDN di 30 secondi. Queste scelte architetturali nel progetto sviluppo web fanno la differenza tra un TTFB di 20ms e uno di 500ms.
Misurare il TTFB correttamente
Chrome DevTools → tab Network → seleziona la prima richiesta (documento HTML) → hover su "Waiting (TTFB)". Misura da più location con WebPageTest.org scegliendo "Virginia (USA)" e "Frankfurt (EU)" per capire l'impatto geografico. Google Search Console mostra il TTFB aggregato per URL nei Core Web Vitals. Misura sempre da più location: un server a Milano ha TTFB di 30ms da Roma ma 150ms da Tokyo.
Un errore di misurazione frequente: misurare il TTFB su pagine con cache calda. La prima visita a una pagina (cache cold) può avere TTFB di 500ms su WordPress; le visite successive con cache object (Redis) o page cache (WP Rocket) scendono a 50ms. Misura sempre in modalità incognito senza cache browser, e usa WebPageTest con il parametro `runs=3, fvonly=0` per ottenere sia First View (cache cold) che Repeat View (cache warm). Il TTFB che conta per il ranking è il First View.
DNS: il componente dimenticato del TTFB
Il DNS lookup aggiunge latenza ad ogni nuova connessione. Usa un DNS provider veloce: Cloudflare DNS (1.1.1.1) è uno dei più veloci al mondo con latenza media di 14ms. DNS prefetching (`<link rel="dns-prefetch">`) risolve in anticipo i domini di terze parti (CDN font, analytics) prima che siano necessari. Riduci il numero di domini terzi: ogni dominio aggiuntivo è un DNS lookup in più.
Nei waterfall dei siti che analizziamo, i DNS lookup di terze parti sommano spesso 100-300ms extra nelle prime richieste. I domini più frequenti: `fonts.googleapis.com`, `connect.facebook.net`, `www.googletagmanager.com`, `cdn.hotjar.com`. Per ognuno, aggiungi `<link rel="dns-prefetch" href="//fonts.googleapis.com">` e `<link rel="preconnect" href="//fonts.googleapis.com" crossorigin>` nell'`<head>`. `preconnect` fa DNS + TCP + TLS in anticipo (più aggressivo di `dns-prefetch`, da usare solo per i 2-3 domini più critici). Il risparmio è di 50-150ms per connessione.
