TTFB WordPress: come misurare e ottimizzare il Time to First Byte

Cos’è il Time to First Byte e perché è cruciale per WordPress

Il Time to First Byte (TTFB) rappresenta il tempo che intercorre tra la richiesta HTTP del browser e la ricezione del primo byte di risposta dal server. Per WordPress, questo valore è particolarmente significativo perché include l’intero ciclo di elaborazione lato server: parsing PHP, query al database, esecuzione di hook e filtri, e generazione dell’HTML.

Nel 2026, con Core Web Vitals sempre più determinanti per il ranking SEO, un TTFB elevato impatta direttamente su Largest Contentful Paint (LCP) e sull’esperienza utente percepita. Google considera ottimale un TTFB inferiore a 800ms, accettabile fino a 1800ms, e problematico oltre questa soglia.

Per le agenzie che gestiscono decine di siti client, monitorare il TTFB è fondamentale per:

• Identificare problemi di hosting prima che impattino i KPI del cliente
• Giustificare upgrade infrastrutturali con dati oggettivi
• Differenziare problemi server-side da ottimizzazioni frontend
• Mantenere SLA di performance concordati contrattualmente

Come misurare correttamente il TTFB su WordPress

Misurare il TTFB richiede metodologie diverse a seconda del contesto e dell’obiettivo diagnostico.

Strumenti per test sintetici

I test sintetici forniscono misurazioni controllate e ripetibili, ideali per baseline e confronti:

• WebPageTest: lo standard de facto per analisi approfondite. Usa la funzione “First Byte” nella waterfall chart e configura test da diverse location geografiche per valutare l’impatto della CDN
• GTmetrix: fornisce TTFB nella sezione “Timings” con breakdown dettagliato. La versione PRO permette test programmati per monitoraggio continuativo
• Google PageSpeed Insights: utilizza dati Chrome UX Report (CrUX) per TTFB reale degli utenti, disponibile dal 2025 nella sezione “Discover what your real users are experiencing”
• KeyCDN Performance Test: eccellente per testare TTFB da 14 location globali simultaneamente, utile per validare configurazioni multi-region

Misurazione via command line

Per diagnosi rapide e scripting automatizzato, curl rimane insuperabile:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://example.com/

Per analisi più dettagliate con breakdown delle fasi:

curl -w "@curl-format.txt" -o /dev/null -s https://example.com/

# File curl-format.txt:
time_namelookup: %{time_namelookup}s\n
time_connect: %{time_connect}s\n
time_appconnect: %{time_appconnect}s\n
time_pretransfer: %{time_pretransfer}s\n
time_redirect: %{time_redirect}s\n
time_starttransfer: %{time_starttransfer}s\n
time_total: %{time_total}s

Monitoraggio Real User Metrics (RUM)

Dal 2026, i dati RUM sono diventati lo standard per decisioni infrastrutturali grazie alla maturità degli strumenti:

• Server-Timing API: implementabile via plugin per esporre metriche granulari nel browser DevTools e in dashboard centralizzate
• New Relic / Datadog: APM enterprise con breakdown automatico del TTFB per plugin, query DB e chiamate esterne
• Query Monitor Pro: plugin WordPress che traccia TTFB per ogni richiesta admin e frontend, con alert configurabili

Anatomia del TTFB in WordPress: dove si perde tempo

Un TTFB elevato su WordPress è raramente causato da un singolo fattore. L’analisi richiede un approccio stratificato.

Latenza di rete e DNS

Prima ancora che la richiesta raggiunga il server web:

• DNS lookup: dovrebbe rimanere sotto i 50ms. Provider DNS premium come Cloudflare o Route53 garantiscono risposte in 10-20ms globalmente
• TCP handshake + TLS: su HTTPS, aggiungi 80-150ms per la negoziazione. TLS 1.3 e HTTP/3 (QUIC) riducono questo overhead significativamente
• Distanza fisica: ogni 1000km aggiungono circa 10ms di latenza base. Per clienti internazionali, una CDN o server multi-region non è opzionale

Layer applicativo WordPress

Dopo che la richiesta raggiunge PHP-FPM o mod_php:

• Autoload di Composer: plugin moderni includono centinaia di classi. Un autoload non ottimizzato può aggiungere 50-200ms. Soluzione: composer dump-autoload -o --apcu in produzione
• Hook e filtri: un tema con 40+ plugin può eseguire 2000+ azioni per richiesta. Query Monitor identifica i colli di bottiglia specifici
• Query al database: una homepage WordPress media esegue 30-80 query. Oltre 150ms totali di query time indica problemi di ottimizzazione o hardware
• API esterne: chiamate sincrone a servizi terzi (analytics, CRM, licensing) sono killer nascosti. Sempre asincrono o cached

Configurazione server web

Nginx vs Apache, PHP-FPM tuning, OPcache: la configurazione server impatta il TTFB per 30-50%:

• OPcache disabilitato: aggiunge 200-500ms per ricompilazione PHP ad ogni richiesta
• PHP-FPM sottodimensionato: quando i worker sono saturi, le richieste accodano aggiungendo secondi di TTFB
• Disk I/O: su VPS economici con storage condiviso, il TTFB varia da 200ms a 3s+ negli orari di picco

Strategie di ottimizzazione TTFB per agenzie

Quick wins (impatto immediato)

1. Abilita caching full-page: Redis Object Cache + plugin come WP Rocket o LiteSpeed Cache riducono il TTFB del 70-90% per pagine anonime. Su WooCommerce, configura cache per pagine non personalizzate
2. Ottimizza OPcache: verifica che opcache.enable=1 e opcache.memory_consumption=256 (minimo). Su server con 50+ siti, considera 512MB
3. CDN per asset statici: anche senza full-page cache, servire CSS/JS/immagini da CDN riduce il carico su origin server e libera risorse PHP
4. Database cleanup: transient scaduti, revisioni post e tabelle WooCommerce non ottimizzate gonfiano il DB. WP-Optimize automatizza la manutenzione

Ottimizzazioni intermedie

1. Lazy loading per plugin pesanti: carica funzionalità come live chat, mappe, video embeds solo quando necessari tramite intersection observer
2. Query database indicizzate: identifica query lente con Query Monitor e aggiungi indici custom. Su tabelle WooCommerce oltre 50K righe, l’impatto è drammatico
3. Autoload optimization: limita dati in wp_options con autoload=yes sotto 1MB. Script: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';
4. HTTP/2 Server Push: per CSS/JS critici, il push riduce round-trip. Attenzione al cache-digest per evitare push ridondanti

Architetture avanzate

Per progetti enterprise o SaaS multi-tenant:

• Varnish Cache: reverse proxy davanti a WordPress con ESI (Edge Side Includes) per frammenti personalizzati. TTFB sotto 50ms per hit cache
• Load balancing multi-server: distribuzione geografica con MySQL read replica e Redis centralizzato. Complessità gestionale elevata ma TTFB consistente globalmente
• Serverless edge compute: Cloudflare Workers o AWS Lambda@Edge per logica di personalizzazione senza colpire origin. Il futuro per SaaS WordPress scalabili
• Database managed: Aurora MySQL o PlanetScale con auto-scaling eliminano il DB come bottleneck. Costo giustificabile oltre 500K pageview/mese

Scegliere l’hosting in base al TTFB

Nel 2026, la differenza tra hosting WordPress si misura sempre più in TTFB sotto carico.

Benchmark realistici per categoria

Dati aggregati da test su 200+ installazioni WordPress nel Q1 2026:

• Shared hosting economico (Aruba, Register.it): 800-2500ms, con spike oltre 5s in peak hours
• Managed WordPress entry (SiteGround, Kinsta starter): 300-600ms, consistente ma limitato in traffico concorrente
• Managed WordPress premium (WP Engine, Kinsta business): 150-300ms, con edge caching integrato
• Cloud VPS ottimizzato (DigitalOcean + RunCloud, Vultr HF): 200-400ms, richiede competenza sistemistica
• Enterprise managed (Pantheon, WordPress VIP): 80-200ms, architettura multi-layer con Varnish

Red flags nella scelta hosting

Elementi che predicono TTFB problematici:

• Overselling CPU: verifica steal time su VPS (top comando, colonna %st dovrebbe essere <5%)
• Storage HDD invece di NVMe: differenza 10x in IOPS impatta DB e cache
• PHP-FPM condiviso: su shared hosting, worker saturi da altri account degradano tutti i siti
• Assenza di object cache incluso: Redis/Memcached dovrebbe essere standard, non opzionale
• Data center unico distante dal target: hosting USA per pubblico italiano aggiunge 150ms+ inutili

Monitoraggio continuo e alerting

Per agenzie che gestiscono portfolio di siti client, il monitoraggio TTFB deve essere automatizzato e proattivo.

Setup consigliato

1. Synthetic monitoring ogni 5-15 minuti: Pingdom, UptimeRobot o script custom con curl schedulato via cron
2. Alert su degradation del 30%+: notifica immediata se TTFB supera baseline + 30% per 3 check consecutivi
3. Report settimanale cliente: include TTFB trend, percentile 95, e confronto con baseline. Giustifica interventi infrastrutturali con dati
4. Dashboard centralizzata: AgencyPilot o tool custom che aggrega TTFB di tutti i siti client con color coding (verde/giallo/rosso)

Correlazione TTFB con eventi

Traccia deploy, aggiornamenti plugin, e picchi di traffico per correlare anomalie TTFB:

• TTFB spike post-deploy? Rollback e debug offline
• Degradazione graduale? Indicatore di DB che richiede ottimizzazione o risorse server insufficienti
• Pattern giornaliero? Backup schedulati o cron job pesanti da spostare in orari low-traffic

TTFB e contratti SLA con i clienti

Definire TTFB target negli SLA protegge l’agenzia e allinea aspettative:

• Target realistico: per managed WordPress di qualità, impegnati su TTFB <500ms per 95° percentile su traffico non cached
• Escludi situazioni anomale: spike da attacchi DDoS, failure del provider hosting, aggiornamenti core WordPress non vanno conteggiati
• Remediation time: definisci tempi di risposta (2h lavorative per segnalazione) e risoluzione (24h per ripristino performance)
• Penalty e bonus: alcuni contratti enterprise includono sconti se SLA non rispettato, o bonus per overperformance

FAQ

Qual è un TTFB accettabile per un sito WordPress nel 2026?

Per siti su hosting managed di qualità, un TTFB sotto 400ms è lo standard atteso. Per e-commerce o siti con personalizzazione utente, 500-600ms rimane accettabile se il resto dello stack è ottimizzato. Oltre 800ms indica problemi sistemici che richiedono intervento immediato, poiché impattano negativamente Core Web Vitals e SEO.

La CDN migliora il TTFB?

Dipende dalla configurazione. Una CDN tradizionale che serve solo asset statici non riduce il TTFB dell’HTML iniziale, che viene comunque generato dall’origin server. Tuttavia, CDN con edge caching (Cloudflare APO, CloudFront con Lambda@Edge, Fastly) possono ridurre il TTFB fino al 90% servendo HTML cached dai POP edge. Per agenzie, soluzioni come Cloudflare Enterprise con Workers permettono personalizzazione edge-side mantenendo TTFB sotto 100ms globalmente.

Come distinguere se il problema TTFB è hosting o codice WordPress?

Usa un approccio stratificato: prima misura TTFB di un file statico sul server (curl -w %{time_starttransfer} https://sito.com/test.html). Se questo è elevato (>200ms), il problema è infrastrutturale. Se è basso ma WordPress è lento, usa Query Monitor per profilare: se “Database Queries” supera 150ms o “PHP Time” è oltre 300ms, il problema è applicativo. Per certificare responsabilità hosting, testa su staging con installazione WordPress pulita: se il TTFB rimane alto, hai evidenza oggettiva per escalation al provider.

I plugin influenzano il TTFB anche con page caching attivo?

Sì, in due scenari critici: primo, alla generazione iniziale della cache (il primo utente subisce TTFB pieno). Secondo, per pagine non cacheable come checkout WooCommerce, account utente, pagine con query string personalizzate. Plugin pesanti eseguono hook e query ad ogni richiesta non cached. Per questo, su siti transazionali, ottimizzare il TTFB uncached rimane fondamentale anche con caching aggressivo del contenuto statico.

Quanto incide il TTFB sul ranking Google nel 2026?

Dal major update di marzo 2025, Google ha rafforzato il peso dei Core Web Vitals, e il TTFB influenza direttamente LCP (Largest Contentful Paint). Dati di settore mostrano correlazione: siti con TTFB <200ms hanno LCP medio di 1.8s, mentre TTFB >800ms portano LCP oltre 3s (soglia poor). Google non usa TTFB come metrica diretta di ranking, ma l’impatto indiretto su LCP e INP è statisticamente significativo. Per competitività SEO in nicchie competitive, TTFB sotto 300ms è diventato requisito de facto.