In breve
Prima di cambiare infrastruttura confronta URL, orari, provenienza e stato della cache. Il tecnico dovrebbe collegare il ritardo a una fase precisa e dimostrare il miglioramento senza alterare contenuti personali o funzioni commerciali.
- Confronta la stessa pagina in condizioni annotate.
- Distingui attesa iniziale e caricamento del contenuto principale.
- Verifica cache, elaborazione e chiamate a servizi esterni.
- Prova separatamente pagine pubbliche, accessi e carrello.
Capire dove si colloca l’attesa iniziale
Time to First Byte indica il tempo trascorso fino all’arrivo del primo byte della risposta. Nella navigazione entrano in gioco passaggi come reindirizzamenti, risoluzione del dominio, connessione e attesa della risposta. Non è quindi una misura pura della potenza dell’hosting.
Il TTFB non è uno dei Core Web Vitals, ma un’attesa iniziale lunga può ritardare la comparsa dei contenuti successivi. Come riferimento orientativo, web.dev suggerisce di puntare a 0,8 secondi o meno per molte tipologie di sito, considerando le esperienze al 75° percentile e il modo in cui vengono prodotte le pagine.
Non trasformare il riferimento in una promessa identica per ogni progetto. Un sito può inviare presto una struttura quasi vuota e mostrare il contenuto molto dopo. Per valutare l’esperienza occorre osservare anche quando diventa disponibile ciò che il cliente vuole leggere o utilizzare.
Preparare un piccolo campione rappresentativo
Scegli una homepage, una pagina servizio, una scheda prodotto e un percorso dinamico, se presente. Annota l’URL esatto: una variante che attraversa diversi reindirizzamenti può comportarsi diversamente dall’indirizzo finale. Registra data, ora, dispositivo e località della prova.
Ripeti i controlli in momenti comparabili senza inviare raffiche di richieste. Per un sito con traffico variabile, una prova isolata non rappresenta una giornata intera. Se il problema coincide con importazioni di catalogo, backup o campagne, comunica l’orario al tecnico.
Distingui le visite senza accesso da quelle effettuate con un account. Un amministratore WordPress e un cliente anonimo possono ricevere risposte attraverso percorsi diversi. La lentezza del pannello richiede inoltre controlli dedicati, descritti nella guida al pannello WordPress o WooCommerce lento.
Leggere i tempi della richiesta insieme al tecnico
Nel pannello Network del browser si può esaminare la richiesta del documento e la sequenza temporale. Chiedi di separare le fasi di collegamento dall’attesa e dal trasferimento. Le misure del laboratorio e quelle delle visite reali possono avere perimetri diversi: confrontarle senza questa distinzione porta a conclusioni fragili.
| Riscontro | Verifica successiva | Dato da chiedere |
|---|---|---|
| Tutte le pagine attendono | Infrastruttura e percorso comune | Tempi e carico negli stessi orari |
| Una sola funzione è lenta | Elaborazione e dipendenze della pagina | Durata di query e servizi chiamati |
| La seconda visita migliora | Livelli di cache e relative regole | Risposta servita dalla cache o generata |
| Il problema cambia per paese | Distanza e distribuzione delle risorse | Prove da località pertinenti al pubblico |
La tabella non assegna una causa definitiva. Serve a chiedere la prova successiva e a evitare interventi scollegati dal comportamento osservato.
Verificare la cache senza mescolare dati personali
Una cache può riutilizzare una risposta già preparata e ridurre il lavoro necessario per le visite successive. Il tecnico deve però distinguere le pagine pubbliche dai contenuti legati a un account, a un carrello o a condizioni specifiche del cliente. Le regole vanno valutate rispetto alla piattaforma.
Chiedi quali livelli sono attivi: applicazione, server, rete di distribuzione e browser. Non serve aggiungerne molti per principio. Occorre sapere quando una risposta viene aggiornata, come si riconosce una versione obsoleta e quali pagine sono escluse dal riutilizzo.
Esegui prove con due sessioni di test distinte e verifica prezzi, accesso, carrello e conferme. Non usare dati reali di clienti per collaudare una configurazione incerta. Se le modifiche non compaiono, la guida alla vecchia versione del sito ancora visibile aiuta a separare aggiornamento e cache.
Controllare il lavoro che precede la risposta
Un sito dinamico può dover leggere informazioni dal database, applicare regole e interrogare altri servizi prima di restituire la pagina. Se una dipendenza risponde lentamente, l’attesa può trasferirsi al visitatore. Il report tecnico dovrebbe mostrare quali passaggi occupano il tempo.
Esempio ipotetico: la pagina di un catalogo interroga il gestionale a ogni apertura, anche quando i dati non cambiano da ore. Una soluzione potrebbe prevedere un aggiornamento controllato delle informazioni pubbliche. Per disponibilità e prezzi, però, vanno concordati intervallo, validazione e comportamento quando il servizio non risponde.
Evita di disattivare plugin sul sito in uso soltanto per tentativi. Prepara una copia di prova, registra le dipendenze e modifica un elemento alla volta. La correzione deve preservare ciò che distingue il servizio: filtri, calcoli, prenotazioni e aggiornamenti non possono sparire senza una decisione esplicita.
Decidere quando ha senso intervenire sull’hosting
Un cambio di piano è motivato quando i riscontri mostrano risorse insufficienti, limiti raggiunti o un’infrastruttura inadatta al traffico e alle funzioni. Prima chiedi al fornitore dati riferiti agli orari e alle pagine segnalate, non soltanto caratteristiche commerciali del piano.
Confronta anche ciò che comprende la gestione: monitoraggio, assistenza, copie di sicurezza, configurazione e possibilità di prova. Un piano più costoso non corregge automaticamente una query inefficiente o una chiamata esterna bloccante. Se è possibile, verifica il comportamento su un ambiente rappresentativo prima del passaggio.
Una rete di distribuzione può essere pertinente per un pubblico geograficamente ampio, ma va configurata rispetto a contenuti e aggiornamenti. Per organizzare un trasferimento effettivo, consulta la guida a cambiare hosting senza interrompere sito ed email.
Verificare il miglioramento sulle pagine e sulle funzioni
Ripeti il campione iniziale dopo la correzione e registra che cosa è cambiato. Osserva sia la prima visita sia quelle successive, distinguendo le condizioni della cache. Controlla anche il caricamento del contenuto principale: un primo byte rapido non basta se il visitatore continua ad aspettare una pagina utilizzabile.
Verifica aggiornamenti dei contenuti, login, moduli e acquisti con dati di prova. Includi gli errori previsti, come una richiesta non valida o un servizio momentaneamente non disponibile. Il sito deve comunicare la situazione senza mostrare conferme false o perdere le scelte dell’utente.
Conserva misure, configurazione e data del rilascio. La manutenzione periodica può usare questo riferimento quando cambiano catalogo, traffico o integrazioni. Il risultato è una base verificabile per decidere gli interventi successivi, non una garanzia di posizionamento nei motori.
Domande frequenti
Un TTFB alto significa sempre hosting insufficiente?
No. Possono incidere rete, reindirizzamenti, elaborazione e servizi interrogati dal sito. Servono misure che distinguano le fasi della richiesta.
La cache deve essere attiva su tutte le pagine?
No. Le regole devono rispettare contenuti personali, accessi, carrelli e dati che cambiano. La configurazione va verificata con la piattaforma utilizzata.
Immagini più leggere risolvono l’attesa del primo byte?
Di norma intervengono su una fase successiva del caricamento. Se il documento iniziale arriva tardi, occorre indagare la richiesta e il lavoro necessario a produrlo.
Fonti e approfondimenti
Riferimenti ufficiali consultati per i criteri tecnici descritti nella guida.