Misurare la velocità di un sito: quello che gli strumenti non dicono

Questo articolo era del 2019 ed era un elenco di dieci strumenti. Gli strumenti ci sono ancora quasi tutti, ma nel frattempo è cambiata la cosa che misurano, ed è cambiata due volte. Vale la pena riscriverlo da capo, partendo da un fatto che a noi è costato un pomeriggio: il nostro metro per il peso delle pagine era sbagliato, e sbagliava in due direzioni opposte allo stesso tempo.

Il punteggio non è la misura

La prima cosa da togliersi dalla testa è il numero grande e colorato in cima a PageSpeed Insights. Quel punteggio da 0 a 100 nasce da una simulazione: Lighthouse carica la pagina su una macchina in un data center, con una rete e una CPU finte, e pesa nove metriche secondo una formula che Google cambia a ogni versione maggiore.

È utile per una cosa sola: confrontare due versioni della stessa pagina sulla stessa macchina, prima e dopo un intervento. Non dice come va il sito. Ci sono siti a 95 che sul telefono di un cliente in centro sono inservibili, e siti a 68 che si aprono all'istante.

Il riquadro che conta sta sopra il punteggio ed è quello che quasi nessuno guarda.

Laboratorio e campo sono due cose diverse

Chrome raccoglie i tempi reali delle visite vere e li aggrega in un archivio pubblico, il Chrome UX Report. È una finestra mobile di 28 giorni: quello che vedi oggi è quello che è successo nell'ultimo mese, su telefoni veri, su reti vere, in posti veri.

Quei dati sono «il campo». La simulazione di Lighthouse è «il laboratorio». Servono a due cose diverse:

• il campo dice se hai un problema;
• il laboratorio dice dove.

Se parti dal laboratorio, ottimizzi cose che non fanno male a nessuno. È il modo più comune di perdere una settimana.

I tre numeri, e cos'è cambiato

Le metriche di riferimento sono tre e hanno soglie precise.

LCP, entro 2,5 secondi. È il momento in cui compare l'elemento più grande sopra la piega — quasi sempre la fotografia grande o il titolo. Non è «quando la pagina ha finito di caricare»: è quando chi guarda capisce di essere arrivato.

INP, entro 200 millisecondi. Misura quanto ci mette la pagina a rispondere a un tocco, guardando tutte le interazioni della visita e prendendo la peggiore. Ha sostituito FID a marzo del 2024, ed è una brutta notizia per parecchi siti: FID misurava solo il ritardo del primo tocco, cioè la metrica più facile da superare che esistesse. INP guarda il tocco e la risposta, ogni volta.

CLS, sotto 0,1. È quanto la pagina si sposta sotto le dita mentre carica. È il difetto che fa premere il pulsante sbagliato.

E c'è una regola che vale per tutti e tre: la soglia va rispettata dal 75% delle visite, non dalla media. La media è la statistica che serve a non vedere il problema, perché nasconde esattamente la coda lenta — quelli con il telefono vecchio, la linea che balla, il paese senza campo — cioè le persone che stai perdendo.

Gli strumenti, e a cosa serve ciascuno

Sono meno di quelli che elencavamo nel 2019, e ognuno ha un compito.

Search Console, sezione Segnalazioni sull'esperienza sulla pagina. È l'unico posto dove vedi i dati di campo del tuo sito raggruppati per tipo di pagina, con quante URL stanno male. Si guarda per prima, ed è gratis per chiunque abbia verificato il dominio.

PageSpeed Insights. Stessa cosa per una singola pagina, più la parte di laboratorio con l'elenco di cosa la rallenta. Il riquadro in alto è il campo; sotto c'è la simulazione.

Lighthouse, dentro gli strumenti per sviluppatori di Chrome. Serve mentre lavori, per il prima-e-dopo. Con la stessa avvertenza: se lo lanci sul tuo portatile con venti schede aperte, misuri il portatile.

WebPageTest, quando vuoi capire davvero. Ti fa scegliere il posto da cui partire, il tipo di connessione e quante volte ripetere, e ti restituisce il grafico a cascata di ogni singola richiesta. È l'unico che risponde alla domanda «perché quel font arriva dopo tre secondi».

Di GTmetrix e Pingdom, che nel 2019 stavano in questo elenco, si può fare a meno: danno un punteggio proprio, con una formula loro, e un punteggio in più non è un'informazione in più.

Il nostro metro, e i due errori che nascondeva

Qui viene la parte utile, perché è successa a noi e per un po' non ce ne siamo accorti.

Questo sito ha un tetto di peso scritto in uno script che gira sulle pagine buildate: legge l'HTML, prende gli asset che quell'HTML dichiara, li comprime e li somma. Se il totale supera la soglia, esce in errore. 190 kB per il JavaScript, 48 per il CSS.

Sembrava una misura seria. Aveva due difetti, e andavano in direzioni opposte.

Il primo, in eccesso: contava un file di compatibilità da 38,7 kB che i browser moderni scaricano e non eseguono mai. Il metro diceva un numero più alto del vero, e per starci dentro avevamo già tolto roba che non serviva togliere.

Il secondo, in difetto, ed è il grosso: la libreria di animazione arriva con un import() dinamico, cioè non è scritta nell'HTML. 47,2 kB compressi che quello script non ha mai visto. Non erano nel conto, e quindi non erano nel budget.

Misurata con un browser vero, la home ne scarica 248,8. Non 207,5, che era il numero sbagliato in eccesso, e nemmeno 168,8, che era quello sbagliato in difetto.

I due errori non si annullavano. Si sommavano in una cosa peggiore di entrambi: un metro che raccontava un sito più leggero del vero mentre sembrava severo. Ci abbiamo creduto per settimane, e nel frattempo ottimizzavamo il numero, non la pagina.

La lezione, se una c'è: prima di lavorare contro un numero, guarda cosa quel numero conta. Un metro che misura la cosa sbagliata è peggio di nessun metro, perché ti dà fiducia.

Un budget serve solo se qualcosa si rompe

L'altra cosa che abbiamo imparato riguarda la soglia, non la misura.

Un tetto di peso funziona se sforarlo ferma qualcosa. Se stampa un avvertimento e la build continua, dopo tre settimane nessuno lo legge più. Da noi lo script esce in errore, e la build non passa.

Ma c'è il rovescio, e ci siamo cascati: una soglia rossa da tre giorni non è un segnale, è rumore. Quando il lavoro fatto bene costa peso — è successo con il foglio di stile, misurato a 46,8 contro un tetto di 40 — la soglia si alza, nello stesso commit, scrivendo nel file perché. Alzarla è permesso. Alzarla di nascosto no, e lasciarla rossa nemmeno.

C'è anche un pezzo che nessuno dei due metri vede: le immagini. Quando abbiamo portato la pagina dei lavori da quattordici copertine a trenta, sono entrati 279 kB in più, e nessuno script ha detto niente. Quel numero l'abbiamo misurato a mano e scritto accanto alla decisione. Va bene spendere, non va bene spendere senza saperlo.

Dove se ne va il peso, in ordine

Se devi intervenire e hai poco tempo, l'ordine che paga è quasi sempre questo.

1. Le immagini. Sono la voce più grande su otto siti su dieci. Formati moderni, dimensioni giuste per lo schermo che le mostra, width e height dichiarati — quest'ultimo da solo sistema quasi tutto il CLS.
2. Quello che carichi da fuori. Font di terze parti, mappe, widget di recensioni, chat, pixel pubblicitari. Ognuno apre una connessione a un dominio che non controlli, e il tuo sito va veloce quanto il più lento.
3. Il JavaScript che non serve a questa pagina. Il caso classico è il carrello caricato anche sul modulo contatti.
4. Il tempo di risposta del server. Conta, ma è l'ultimo perché di solito è il più piccolo dei quattro — e se hai le prime tre a posto, si sistema con la cache.

Da dove partire, lunedì mattina

Quattro cose, in quest'ordine, e le prime due non richiedono nessuno.

1. Apri Search Console e guarda i dati di campo. Se sono verdi, hai finito: il resto è ottimizzazione di un problema che non hai.
2. Se sono rossi, guarda quale gruppo di pagine lo è. Quasi sempre è uno solo — le schede prodotto, o le pagine con la mappa — e questo ti dice già dov'è il problema.
3. Prendi una pagina di quel gruppo e passala a WebPageTest da mobile, su una connessione lenta. Il grafico a cascata ti dice cosa arriva tardi.
4. Rimisura fra ventotto giorni. I dati di campo sono una media mobile su quel periodo: se ricontrolli il giorno dopo l'intervento, vedi ancora il mese vecchio e pensi di aver fatto un lavoro inutile.

Il punto di tutto questo non è il posizionamento, che è un effetto laterale e piccolo. È che chi aspetta se ne va, e se ne va prima di Google. Lo abbiamo scritto anche parlando di prenotazioni dirette: un sito che ci mette sei secondi ad aprirsi su rete mobile non ha un problema di velocità, ha un problema di prenotazioni.

Come costruiamo i siti perché questi numeri restino dove devono, sta nella pagina siti web.