Come verificare la velocità di un sito web

Il modo veloce: esegui un test con un browser reale

Inserisci l'URL in un test di velocità della pagina e lascia che carichi la pagina in un browser vero invece di stimare. Un buon report ti dà uno screenshot di cosa è stato renderizzato, i tempi complessivi, e una ripartizione per richiesta che mostra quale immagine, script o chiamata di terze parti era lenta. Quella ripartizione è ciò che trasforma "la pagina è lenta" in "questo file di font blocca il rendering per 1,8 secondi".

Eseguilo subito dopo un deployment, dopo un aggiornamento di plugin o tema, e prima di impegnarti in un cambio di hosting o CDN. Quelli sono i momenti in cui la velocità cambia e nessuno se ne accorge.

Misurarlo tu stesso dalla riga di comando

Per la parte lato server della storia non ti serve affatto un browser. curl può stampare la propria ripartizione dei tempi:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Questo misura una richiesta solo per il documento HTML, quindi apparirà sempre più veloce della pagina reale. Ecco esattamente perché è utile: isola il server dal browser. Se il ttfb qui è alto, nessuna quantità di ottimizzazione delle immagini aiuterà. Se il ttfb è basso e la pagina sembra comunque lenta, il problema sta in quello che il browser deve fare dopo che arriva l'HTML.

Cosa significano TTFB, LCP e caricamento completo

• Tempo al primo byte (TTFB). Quanto tempo ha impiegato il server a iniziare a rispondere, incluso DNS, apertura della connessione, TLS ed elaborazione propria del server. Un TTFB alto indica l'hosting, le query al database o il codice backend, non gli asset della pagina.
• Largest Contentful Paint (LCP). Quando l'elemento visibile più grande nel viewport ha finito di renderizzarsi, di solito un'immagine principale, il poster di un video o un grande blocco di testo. È il numero più vicino a ciò che un visitatore chiama "quando è apparsa la pagina". Google considera buono un valore di 2,5 secondi o meno.
• Tempo di caricamento / caricamento completo. Quando il browser ha finito di caricare il documento e le sue risorse bloccanti. Tutto ciò che il visitatore può vedere è normalmente pronto ben prima di questo momento.
• Tempo totale per stabilizzarsi. Il tempo di caricamento più qualsiasi cosa ancora in esecuzione dopo, come script che recuperano dati una volta che la pagina sembra completata. Una pagina può sembrare finita ed essere comunque occupata, e quel lavoro compete con il primo scroll o clic del visitatore.
• Richieste e byte trasferiti. Quanti file ha scaricato la pagina e quanto è stato scaricato. Sono le leve dietro quasi ogni numero sopra elencato.

Leggili insieme. Un TTFB basso con un LCP alto significa che il browser sta facendo troppo: troppe richieste, script che bloccano il rendering, oppure un'immagine principale enorme. Un TTFB alto con tutto il resto normale significa che il server è il collo di bottiglia, ancora prima che il browser entri in gioco.

Perché un singolo test da un solo luogo inganna

È normale testare lo stesso URL due volte e ottenere due risultati diversi, e nessuno dei due è sbagliato. Tre cose guidano gran parte della variazione:

• Distanza. Un test eseguito vicino al server ha un percorso di rete più breve di uno eseguito su un altro continente. Se i tuoi visitatori sono in Europa e testi dalla stessa città del tuo server, stai misurando il caso migliore, non quello tipico.
• Profilo del dispositivo. Un test può emulare un dispositivo mobile con un viewport più piccolo, uno user agent diverso e una connessione rallentata artificialmente. Una pagina ottimizzata per desktop ottiene un punteggio molto diverso sotto emulazione mobile, di proposito.
• Cache e riscaldamento. La prima richiesta può colpire una cache fredda sulla CDN o nell'applicazione; la seconda viene servita calda. Esegui una pagina due o tre volte e usa lo schema, non la singola esecuzione più veloce.

Un singolo test vale comunque la pena eseguirlo. Significa solo che un numero ha un senso solo insieme alle condizioni in cui è stato misurato.

Come leggere una waterfall

La waterfall è la linea temporale per richiesta, una barra per file, ordinata per quando è iniziata. Quattro forme ricorrono di continuo:

1. Una prima barra lunga prima che inizi qualsiasi altra cosa. Quello è il TTFB sull'HTML, e tutto si mette in coda dietro di esso.
2. Una scala a gradini dove ogni richiesta inizia solo quando finisce la precedente. È una catena di dipendenza, di solito uno script che carica un altro script che carica il contenuto vero. Le catene sono la forma più costosa sul grafico.
3. Una barra larga nel mezzo da un dominio di terze parti. Pubblicità, widget di chat, analytics e font stanno qui, e una terza parte lenta ritarda la tua pagina se è caricata in modo sincrono.
4. Un cluster denso di barre minuscole. Decine di file piccoli, ciascuno con il proprio sovraccarico di connessione. File più grandi, più pochi e in cache di solito battono molti file piccoli.

Le barre in rosso o con codici 4xx e 5xx meritano attenzione anche quando la pagina sembra a posto, perché una richiesta fallita costa comunque tempo prima di fallire.

Individuare un rallentamento che nessuno stava cercando

Un singolo test ti dice come si è comportata la pagina una volta, da un luogo, su un profilo di dispositivo. È quello che vuoi quando fai debug di qualcosa di specifico. Non è quello che vuoi quando l'obiettivo è accorgersi affatto di un rallentamento: le pagine diventano più pesanti un aggiornamento alla volta, e nessuno esegue un test manuale in un tranquillo martedì. Il monitoraggio pianificato della velocità di pagina esegue lo stesso test dalle stesse ubicazioni a intervalli regolari, mantiene la cronologia, e avvisa quando i numeri superano una soglia. Eseguine uno ora con il test di velocità della pagina, e vedi tempo di risposta del server se la parte lenta risulta essere il server.