Leggere PageSpeed richiede competenza: gli errori da evitare

PageSpeed Insights è gratuito, si usa in un clic e produce un numero facile da confrontare. Proprio per questo sembra uno strumento per tutti. In realtà il rapporto è pensato per sviluppatori: contiene decine di voci tecniche, stime teoriche e suggerimenti generici che, letti senza esperienza, portano spesso a conclusioni sbagliate. Vediamo perché serve competenza per interpretarlo e come evitare gli errori più comuni.

Il 100 non è l’obiettivo

Il punteggio è un indicatore, non un traguardo. Un sito può avere 75 su mobile ed essere velocissimo per i suoi visitatori reali, oppure avere 95 in laboratorio e risultare lento per chi lo usa davvero. Inseguire il 100 a tutti i costi porta spesso a togliere funzioni utili, come la chat, le statistiche o le mappe, per guadagnare pochi punti che nessun cliente noterà.

La domanda giusta non è «come arrivo a 100?», ma «i miei visitatori aspettano troppo? E dove?».

I suggerimenti sono generici

Lighthouse applica le stesse regole a ogni sito del mondo. Non sa che quel file JavaScript serve al carrello, che quella libreria è richiesta dal tuo gestionale o che quel carattere tipografico fa parte del marchio. Alcuni consigli tipici:

• «Riduci il JavaScript inutilizzato»: spesso quel codice serve in un’altra pagina o dopo un clic;
• «Rimanda il caricamento delle risorse»: se fatto male, rompe menu, slider o moduli;
• «Precarica la risorsa più grande»: utile solo se si sceglie la risorsa giusta;
• «Usa formati immagine moderni»: corretto, ma va fatto senza rovinare la qualità.

Alcuni suggerimenti sono anche in contraddizione tra loro: unire i file aiuta in certi casi e peggiora in altri. Decidere quale applicare richiede di conoscere il sito.

Le stime di risparmio sono teoriche

Accanto a molte voci compare un risparmio stimato, per esempio «1,2 secondi». È una stima calcolata in condizioni ideali e i risparmi non si sommano: tre voci da un secondo ciascuna non fanno guadagnare tre secondi. Spesso, dopo aver corretto una voce, il punteggio cambia di poco.

Confronta più misure

Ogni prova di laboratorio è una singola misura, influenzata da molti fattori. Per valutare davvero una modifica:

1. esegui almeno tre prove prima e tre dopo;
2. guarda la versione mobile, che è quella che Google considera di più;
3. controlla i dati reali degli utenti, se il sito ne ha, tenendo conto che si aggiornano su 28 giorni;
4. prova più pagine: la home, una scheda prodotto, un articolo, il carrello.

Sapere cosa ignorare

Una parte dell’esperienza consiste nel capire quali voci non meritano tempo. Per esempio:

• avvisi su script di terze parti indispensabili, come il sistema di pagamento;
• differenze di pochi punti tra una prova e l’altra;
• voci con risparmi minimi, di poche decine di millisecondi;
• la categoria «navigazione agentica», ancora sperimentale.

Mai truccare il test

Esistono trucchi che riconoscono lo strumento di misura e gli servono una pagina diversa, alleggerita, da quella che vedono i visitatori. Il punteggio sale, ma la velocità reale resta la stessa. È una pratica scorretta: Google la considera cloaking, cioè mostrare contenuti diversi ai sistemi di Google e alle persone, e può penalizzare il sito. Noi non lo facciamo e lo sconsigliamo sempre: l’unico miglioramento che conta è quello che sentono i tuoi visitatori.

Quando serve un tecnico

Puoi fare molto da solo: comprimere le immagini, togliere plugin che non usi, attivare la cache. Conviene invece rivolgersi a un tecnico quando:

• il punteggio è basso e non capisci da quale voce partire;
• vuoi applicare ottimizzazioni sul JavaScript o sul CSS, che possono rompere il sito;
• i dati reali degli utenti sono scarsi nonostante buone prove di laboratorio;
• il tempo di risposta del server è alto e non sai perché.

Per la parte che riguarda l’hosting siamo noi il tecnico: tempo di risposta, cache, iWebLab Cache, Image Optimizer e Database Intelligence. Per tema e plugin serve chi ha costruito il sito, e ti aiutiamo volentieri a capire cosa chiedergli.

Gli errori più comuni

Ecco le situazioni che vediamo più spesso quando un cliente ci scrive dopo aver letto un rapporto di PageSpeed:

• Confrontare il proprio sito con quello di un concorrente facendo una sola prova per ciascuno: con la variabilità del laboratorio, il confronto non dice quasi nulla.
• Cambiare hosting per guadagnare punti, quando il tempo di risposta del server era già buono: il punteggio resta uguale, perché il problema era nel tema o negli script.
• Installare tre plugin di ottimizzazione insieme: si pestano i piedi a vicenda, duplicano la cache e spesso rompono il sito.
• Applicare il rinvio di tutti gli script senza provare il sito dopo: il punteggio sale, ma il menu non si apre più o il carrello non aggiunge i prodotti.
• Misurare subito dopo una modifica e guardare i dati reali: quelli si aggiornano su 28 giorni, quindi servono settimane per vedere l’effetto.
• Misurare una pagina che non è in cache, per esempio subito dopo averla modificata: la prima visita è sempre più lenta delle successive.

In tutti questi casi il rapporto era corretto, ma è stato letto male. È qui che l’esperienza fa la differenza.

In sintesi

• PageSpeed è uno strumento per tecnici: il numero da solo non basta a capire cosa fare.
• Il 100 non è l’obiettivo; conta l’esperienza dei visitatori reali.
• Suggerimenti generici e risparmi stimati vanno valutati caso per caso.
• Confronta più prove, più pagine e i dati reali; mai truccare il test.

Hai un rapporto di PageSpeed e non sai da dove cominciare? Apri un ticket: ti aiutiamo a leggerlo e a separare ciò che dipende dal server da ciò che dipende dal sito.