Performance front-end e Core Web Vitals misurati

«Abbiamo già controllato, PageSpeed dà verde.» È la risposta che ricevo più spesso, ed è il motivo per cui questa pagina comincia da qui.

Quel punteggio è una simulazione: una macchina carica la pagina una volta, in condizioni decise da Google, e dà un voto. I numeri che Google usa per il posizionamento arrivano dai browser dei tuoi visitatori, sugli ultimi 28 giorni, mentre fanno quello che fanno di solito. Le due misure possono divergere parecchio.

Su una scheda prodotto l’instabilità visiva in laboratorio era 0,007, nei dati di campo 0,20. Trenta volte. La simulazione caricava la pagina e si fermava, i visitatori scrollavano, e gli spostamenti che contano avvengono mentre scrolli.

Quello che misuro è cosa succede sulla pagina e chi lo causa. Non «CLS 0,19» ma «questo pulsante compare dopo tre secondi e mezzo, il testo accanto va a capo, la pagina scende di 33 pixel». Sul primo numero non puoi agire, sul secondo sì.

La performance non è solo front-end. Sullo stesso negozio il tempo di risposta del server, misurato sull’origine e non sulla cache della CDN, è sceso da 954 a 636 millisecondi su desktop dopo il trasloco da un hosting condiviso che uccideva i processi PHP. Capire quale delle due metà è lenta viene prima di qualunque ottimizzazione.

Il risultato non resta fermo da solo. Su un catalogo le richieste che bloccano il rendering sono passate da 31 a 13 in quattro interventi datati, e senza un controllo in pipeline il primo aggiornamento di plugin le rimette dov’erano. Per questo lascio una soglia a cricchetto: registra dove sei oggi e impedisce di tornare indietro mentre punti a dove vuoi arrivare.

Da te mi serve accesso in lettura al sito, e se c’è un ambiente di prova anche quello. Non serve fermare niente.

Quando non conviene chiamarmi: se il sito è appena stato rifatto e non è ancora online, non ci sono dati di campo e metà del lavoro non si può fare. Si aspettano quattro settimane di traffico vero.