Come ridurre il TTFB (Time to First Byte)

Ridurre il TTFB significa accorciare il tempo che passa tra il momento in cui il browser chiede una pagina e quello in cui riceve il primo byte della risposta. In pratica vuol dire tre cose: far generare l'HTML più in fretta a server e applicazione, servire HTML dalla cache così che la maggior parte delle richieste salti del tutto quel lavoro, e avvicinare la risposta ai tuoi visitatori. Questa guida ti mostra come capire quale dei tre è il tuo collo di bottiglia e cosa fare in ciascun caso.

Cosa misura il TTFB

Il Time to First Byte non è una cosa sola. È la somma di diverse fasi che avvengono prima che arrivi qualsiasi contenuto:

1. Redirect, se l'URL richiesto rimanda prima altrove.
2. Lookup DNS, cioè la traduzione del nome di dominio in un indirizzo IP.
3. Apertura della connessione, l'handshake TCP più la negoziazione TLS per HTTPS.
4. Richiesta ed elaborazione sul server, il tempo che il server impiega a costruire la risposta (esecuzione di PHP, query al database, rendering dei template).
5. Il viaggio di ritorno del primo byte verso il browser.

Ecco perché due siti su server identici possono avere TTFB molto diversi: uno magari è vicino ai suoi visitatori e serve pagine dalla cache, l'altro si trova su un altro continente e genera ogni richiesta da zero.

Il TTFB non è uno dei tre Core Web Vitals, ma sta alla base di tutti. Niente può essere visualizzato prima che arrivi il primo byte, quindi un TTFB lento sposta in avanti direttamente il Largest Contentful Paint. Se il tuo LCP è scarso, il TTFB è una delle prime cose da controllare. La guida ai Core Web Vitals spiega come sono collegate le metriche.

Qual è un buon TTFB?

La guida di web.dev sul TTFB raccomanda alla maggior parte dei siti di puntare a un TTFB di 0,8 secondi o meno, misurato al 75° percentile dei caricamenti reali. Valori oltre 1,8 secondi sono considerati scarsi.

Ci sono due cose da tenere a mente. Primo, questi numeri descrivono utenti reali su reti reali, comprese connessioni mobili lente lontane dal tuo server. Un test dal tuo ufficio accanto al data center sembrerà molto migliore di quello che vive un visitatore su un altro continente. Secondo, 0,8 s è un riferimento indicativo, non una soglia rigida da superare. I siti che fanno tutto il rendering sul client possono tollerare qualcosa in più; i siti con rendering lato server, cioè la maggior parte delle installazioni WordPress e dei negozi online, traggono vantaggio dallo stare ben al di sotto.

Misuralo e trova la fase lenta

Prima di cambiare qualsiasi cosa, misura dove finisce il tempo. Un controllo veloce da riga di comando:

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Ogni valore è cumulativo, in secondi. Fai le sottrazioni per ottenere le singole fasi:

• connect - dns è il viaggio di andata e ritorno in rete fino al server.
• tls - connect è l'handshake HTTPS.
• ttfb - tls è all'incirca il tempo di elaborazione sul server più un viaggio di andata e ritorno.

Esegui il comando più volte, perché spesso la prima richiesta paga una cache fredda o un nuovo lookup DNS. Se ttfb - tls resta alto (diciamo diverse centinaia di millisecondi o più) mentre le fasi di rete sono brevi, il collo di bottiglia è il server. Se invece le fasi di rete sono lunghe, il problema sono la distanza e il costo della connessione.

Per i numeri degli utenti reali, analizza la pagina con corewebvitals.page e guarda i dati sul campo degli utenti di Chrome, disponibili quando il sito ha abbastanza traffico. In Chrome DevTools, la scheda Network mostra la scomposizione dei tempi di ogni richiesta: "Waiting for server response" è la parte server del TTFB. La guida su come misurare la velocità di un sito spiega come combinare queste fonti senza ingannarti.

Velocizza server e applicazione

Se domina il tempo di elaborazione, la soluzione sta sull'origine. Procedi in quest'ordine, dal passo più economico a quello più impegnativo:

Aggiorna il runtime

Le versioni più recenti di PHP, Node.js o Python sono spesso sensibilmente più veloci a parità di lavoro. Controlla quale versione usa il tuo hosting e se CMS e plugin ne supportano una più nuova.

Aggiungi una object cache

WordPress, WooCommerce, Shopware, Magento e Drupal eseguono tutti molte query ripetute al database. Una object cache persistente come Redis o Memcached tiene quei risultati in memoria tra una richiesta e l'altra. Molti hosting gestiti la offrono come opzione da attivare.

Trova query e plugin lenti

Un solo plugin che esegue una query costosa a ogni caricamento di pagina può dominare il TTFB. Usa un profiler o un monitor delle query su una copia di staging, disattiva i sospetti uno alla volta e misura di nuovo. Nei negozi online, i filtri a faccette, i widget dei prodotti correlati e le verifiche di magazzino in tempo reale sono colpevoli frequenti.

Controlla le risorse del server

Se il TTFB va bene di notte e male nelle ore di punta, il server sta esaurendo CPU, memoria o worker PHP. Più risorse o un piano di hosting migliore possono essere la scelta giusta, e nessuna ottimizzazione del front-end risolverà il problema.

Metti in cache le pagine HTML complete

La maggior parte delle richieste a un sito tipico riguarda pagine uguali per ogni visitatore anonimo. Generarle da zero ogni volta è lavoro sprecato. Una cache di pagina completa salva l'HTML finito e lo restituisce senza toccare PHP o il database, ed è di solito l'intervento con l'effetto singolo più grande sul TTFB.

Puoi mettere in cache a livelli diversi:

• Nell'applicazione, con un plugin di cache o una cache HTTP integrata (Shopware e Drupal ne hanno una). La documentazione di WordPress sulla cache (in inglese) offre una buona panoramica delle opzioni in quell'ambito.
• Sul server, con un reverse proxy come Varnish o una cache Nginx.
• Sull'edge, su un CDN o una rete edge, così le pagine in cache vengono servite da una località vicina al visitatore.

Qualunque livello scegli, sii rigoroso su cosa non va messo in cache: carrello, checkout, pagine account, sessioni degli utenti loggati e tutto ciò che è personalizzato. Queste richieste devono saltare la cache e arrivare ogni volta all'origine. Se le tue pagine inviano header Cache-Control sensati, ogni livello può seguirli.

Verifica se una pagina arriva davvero dalla cache guardando gli header di risposta:

curl -sI https://example.com/ | grep -i -E "cache|age"

Una cache che esiste ma raramente va a segno serve a poco. Tassi di hit bassi dipendono di solito da cookie o query string che fanno sembrare unica ogni richiesta, oppure da durate della cache troppo brevi.

Accorcia la distanza dai visitatori

Ogni viaggio di andata e ritorno tra browser e server costa tempo, e una nuova connessione HTTPS ne richiede diversi prima che il primo byte possa partire. Se il tuo server è a Francoforte e un visitatore a Sydney, la sola fisica aggiunge un ritardo evidente a ciascuno di quei viaggi, per quanto veloce sia il server.

Ci sono due modi per accorciare questa distanza:

• Scegli un hosting vicino al tuo pubblico. Se quasi tutti i visitatori sono in un solo paese, un server in quel paese o nelle vicinanze è il guadagno più semplice.
• Servi le pagine da una rete edge. Un CDN chiude le connessioni in una località vicina al visitatore e, quando la pagina è in cache lì, risponde senza contattare affatto la tua origine. La guida Cos'è un CDN spiega cosa può risolvere e cosa no.

Una rete edge aiuta un po' anche le richieste non in cache, perché l'handshake TLS avviene vicino al visitatore e l'edge può riutilizzare una connessione già aperta verso l'origine. Il grande guadagno, però, arriva dai cache hit.

Elimina redirect e costi di connessione

Le piccole cose si sommano, soprattutto sulle reti mobili:

• Evita le catene di redirect. Da http://example.com a https://example.com a https://www.example.com a https://www.example.com/en/ sono tre viaggi di andata e ritorno in più prima che succeda qualcosa di utile. Linka direttamente l'URL finale e tieni al massimo un redirect.
• Usa HTTP/2 o HTTP/3 e TLS 1.3. Riducono il numero di viaggi necessari per aprire la connessione e permettono al browser di scaricare molte risorse su un'unica connessione.
• Usa un provider DNS veloce. Per chi visita il sito per la prima volta, il DNS fa parte del TTFB. I provider basati su Anycast o GeoDNS rispondono da località vicine.
• Attiva la compressione. Brotli o gzip sull'HTML non cambiano molto il primo byte, ma accorciano il resto del download che segue.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale e interviene sulle parti del TTFB legate alla rete e alla cache. Mantieni il tuo hosting; punti i nameserver del dominio su fast.site e, dopo la verifica, il tuo traffico passa dalla sua rete edge.

Fast Edge Cache™ conserva sull'edge le pagine che si possono mettere in cache. Con un cache HIT la risposta arriva direttamente dall'edge senza contattare la tua origine; con un MISS la pagina viene recuperata una volta e salvata. La scadenza segue gli header Cache-Control della tua origine o le tue regole, e un cache warmer tiene pronte le pagine importanti. Carrello, checkout e sessioni degli utenti loggati saltano la cache, e l'header fs-cache lo segnala come BYPASS. Puoi controllare qualsiasi URL come descritto in come verificare la cache, e la documentazione sulla cache spiega le regole.

GeoDNS indirizza i visitatori all'edge funzionante più vicino, con regioni in Nord America, Europa, Asia-Pacifico e Sud America a seconda del tuo piano (vedi regioni). I certificati vengono emessi e rinnovati automaticamente.

fast.site non rende più veloce una query lenta al database, quindi gli interventi sull'origine restano importanti per le pagine non in cache. Le statistiche nella dashboard mostrano TTFB e cache hit ratio, così puoi misurare l'effetto sul tuo sito. Puoi farlo per esempio durante una prova gratuita di 7 giorni.

Domande frequenti

Il TTFB influisce sulla SEO?

Il TTFB non è uno dei Core Web Vitals che Google usa come segnale di esperienza sulla pagina. Ritarda però il Largest Contentful Paint, che invece lo è. Migliorare il TTFB serve soprattutto a ottenere un LCP migliore e un sito che si percepisce più veloce, non a una spinta diretta nel posizionamento.

Perché il TTFB è alto solo alla prima visita?

La prima richiesta include spesso un lookup DNS, un nuovo handshake TLS e una cache fredda su server o edge. Le richieste successive riutilizzano le connessioni e trovano una cache già calda. Se il TTFB della prima visita conta per te (e per la maggior parte delle landing page conta), guarda velocità del DNS, redirect e riscaldamento della cache.

Perché il TTFB è buono nel mio test ma scarso per gli utenti reali?

Il tuo test di solito gira su una connessione veloce vicina al server, con una cache già calda. I dati sul campo, come quelli di corewebvitals.page o di Search Console, arrivano da utenti reali di Chrome su ogni tipo di rete e località, misurati al 75° percentile. La differenza indica spesso un problema di distanza o pagine che finiscono raramente in cache.

Un CDN risolve un TTFB lento?

Risolve le parti dovute alla distanza e alla generazione ripetuta delle pagine, purché le pagine si possano davvero mettere in cache. Non velocizza le richieste che devono arrivare all'origine, come il checkout o le pagine degli utenti loggati. Per quelle servono comunque interventi su server e applicazione.