Il tuo sito è lento sullo smartphone: perché e come risolvere

A chi serve questa guida

Hai un sito e sullo smartphone sembra lento: la pagina resta vuota per un po’, il testo salta mentre qualcosa si carica, o un menu risponde in ritardo quando lo tocchi. Magari sul portatile va tutto bene e un visitatore o un collega ti dice il contrario. Oppure un test di velocità è venuto rosso e non sai da dove cominciare.

La guida vale per WordPress, per i costruttori di siti e per i siti fatti a mano o statici. I primi passi non richiedono competenze tecniche: misurare e ridimensionare le immagini. I passi successivi riguardano plugin, script, font e hosting, quindi potrebbe servirti la persona che ha costruito o gestisce il tuo sito.

Cosa significa «lento», e perché lo smartphone lo mostra per primo

«Lento» non è una misura sola. Google descrive l’esperienza con tre indicatori, i Core Web Vitals, e indica un obiettivo per ciascuno. Una pagina è «buona» quando li raggiunge tutti e tre per almeno il 75% dei caricamenti, misurati separatamente per smartphone e per computer (web.dev):

• LCP (Largest Contentful Paint): quanto passa prima che l’elemento più grande dello schermo, di solito l’immagine principale o il titolo, sia visibile. Buono: fino a 2,5 secondi.
• INP (Interaction to Next Paint): quanto impiega la pagina a reagire quando si tocca, si clicca o si scrive. Buono: fino a 200 millisecondi.
• CLS (Cumulative Layout Shift): quanto il contenuto si sposta durante il caricamento. Buono: fino a 0,1.

I problemi si vedono prima sullo smartphone, perché ha meno potenza di calcolo di un portatile e spesso una connessione più debole: una pagina pesante o un mucchio di script costano lì più tempo. E aspettare fa perdere visitatori: in una ricerca Google/SOASTA del 2017, la probabilità che un visitatore da mobile se ne andasse era più alta del 32% quando una pagina impiegava 3 secondi a caricarsi invece di 1 secondo.

Come capire quale causa è in gioco

Fai prima il passo 1, poi confronta con quello che vedi:

• L’LCP supera i 2,5 secondi. L’immagine principale o il titolo arriva tardi. Cause probabili: un’immagine principale troppo grande o preparata male, un server lento, o testo che aspetta un font. Vai ai passi 2, 3, 4, 8 e 9.
• L’INP supera i 200 millisecondi. I tocchi e i menu sembrano pesanti: il telefono è occupato a eseguire script. Cause probabili: troppi plugin e script, o widget esterni pesanti. Vai ai passi 6 e 7. La guida di Google sull’INP spiega il lato tecnico per uno sviluppatore.
• Il CLS supera 0,1. Durante il caricamento qualcosa si sposta e si tocca il pulsante sbagliato. Cause probabili: immagini e contenuti incorporati senza spazio riservato, banner o pubblicità che compaiono tardi, font che cambiano a caricamento avvenuto. Vai ai passi 5 e 8.
• Veloce sul portatile, lento sullo smartphone. È normale: un portatile con un Wi-Fi veloce nasconde il problema. Prova su un telefono con i dati mobili (passo 1) e parti dalle immagini (passo 2) e dagli script (passo 6).
• Solo alcune pagine sono lente. Guarda cosa hanno quelle pagine che le altre non hanno: uno slider, un video, una mappa, una galleria o un widget. Vai ai passi 4, 5 e 7.
• I dati di laboratorio e quelli sul campo non coincidono. I dati di laboratorio sono un solo test simulato, i dati sul campo mostrano ciò che hanno vissuto visitatori reali. Fidati dei dati sul campo per il verdetto e usa il test di laboratorio per cercare le cause (perché differiscono).
• Non compaiono dati sul campo. La pagina non ha ancora abbastanza visite. Usa il test di laboratorio e un telefono vero, e ricontrolla dopo qualche settimana.

I passi per risolvere

1. Misurare su un telefono vero e annotare i valori. Apri PageSpeed Insights, inserisci l’indirizzo della tua home page e di una o due altre pagine importanti e leggi la scheda Dispositivi mobili. La parte in alto mostra dati sul campo: l’esperienza di veri visitatori di Chrome negli ultimi 28 giorni. La parte in basso è un test di laboratorio con Lighthouse, un’esecuzione simulata che elenca problemi concreti (la differenza tra i due). Annota LCP, INP e CLS di ogni pagina. Se il tuo sito è verificato in Google Search Console, il suo rapporto sui Core Web Vitals mostra gli stessi dati raggruppati per pagine simili, così vedi quali tipi di pagine hanno un problema. Poi apri il sito tu stesso su un telefono con il Wi-Fi spento e osserva come si comporta. I dati sul campo coprono 28 giorni e cambiano lentamente dopo una correzione. Usa il test di laboratorio per controllare subito una modifica.

2. Ridimensionare e comprimere le immagini. Le foto troppo grandi sono la causa più frequente. Una foto presa direttamente dalla fotocamera o da una banca di immagini può essere larga diverse migliaia di pixel, mentre uno smartphone la mostra larga poche centinaia. Dai a ogni immagine più o meno la dimensione della sua visualizzazione più grande, poi comprimila. Offri più misure con srcset, così lo smartphone scarica quella piccola (immagini adattive). In WordPress inserisci le immagini alla dimensione in cui vengono mostrate, non a grandezza originale. Un plugin per le immagini o il tuo hosting spesso può ridimensionarle e convertirle al posto tuo.

3. Usare un formato d’immagine moderno. WebP e AVIF possono comprimere meglio di JPEG e PNG, quindi la stessa immagine si carica più in fretta. Converti le immagini e tieni un JPEG o un PNG di riserva per i browser che non supportano il nuovo formato, se il tuo strumento non lo fa da solo (scegliere il formato). Non salvare di nuovo e di nuovo un’immagine già compressa, perché la qualità cala ogni volta. Converti partendo dal file originale.

4. Caricare per prima l’immagine principale, il resto in differita. L’immagine principale in cima alla pagina (spesso l’elemento LCP) deve caricarsi il prima possibile. Inseriscila nella pagina come normale <img>, non come sfondo CSS e non dentro uno slider caricato da script, e aggiungi fetchpriority="high" perché il browser la scarichi per prima (ottimizzare l’LCP). Non mettere mai loading="lazy" su di essa. Per le immagini più in basso vale l’opposto: con loading="lazy" si caricano solo quando il visitatore scorre fino a loro (caricamento differito). WordPress fa entrambe le cose in automatico per la probabile immagine principale dalla versione 6.3 (annuncio di WordPress), ma temi, slider e page builder possono disattivarlo: guarda il sorgente della pagina.

5. Riservare lo spazio perché nulla salti. Dai a ogni immagine e video gli attributi width e height, o una proprietà CSS aspect-ratio, così il browser lascia il vuoto giusto prima che arrivi il file (ottimizzare il CLS). Fai lo stesso per mappe, video e widget incorporati: fissa la loro dimensione e carica in differita quelli che iniziano sotto la prima schermata (buone pratiche per i contenuti incorporati). Avvisi sui cookie, barre di annuncio e pubblicità che compaiono tardi e spingono giù il contenuto sono una causa classica di spostamenti. Dai loro uno spazio fisso, oppure mostrali in sovrapposizione.

6. Togliere i plugin e gli script che non usi. Ogni plugin, ogni tag di tracciamento e ogni componente aggiuntivo può portare con sé script e stili propri, spesso su ogni pagina. Elenca ciò che è installato, elimina ciò che nessuno usa e sostituisci i più pesanti con alternative più leggere. Toglili uno alla volta e misura di nuovo, così sai quale ha fatto la differenza. Fai prima un backup. In WordPress è più sicuro disattivare un plugin su una copia di prova del sito che sul sito online. Lighthouse in PageSpeed Insights elenca JavaScript e CSS inutilizzati e ti porta ai responsabili.

7. Ritardare i widget esterni. Bolle di chat, feed dei social, badge di recensioni, mappe, lettori video e tag pubblicitari caricano codice di altre aziende. Spesso si caricano per ultimi e fanno concorrenza ai tuoi contenuti. Carica solo ciò che ti serve, e caricalo tardi: aggiungi async o defer agli script, oppure carica un widget solo dopo un tocco, con una semplice immagine di anteprima al suo posto (JavaScript di terze parti). Lighthouse segnala il codice di terze parti che blocca il thread principale per 250 millisecondi o più (dettagli). Per ogni widget chiediti: lo usa qualcuno?

8. Caricare i font con criterio. Usa poche famiglie e pochi pesi di font, e ospita i file dei font sul tuo dominio in formato WOFF2, con solo i caratteri che ti servono. Imposta font-display perché il testo compaia subito in un font di riserva invece di restare invisibile, e precarica solo il font o i due font che servono alla prima schermata (buone pratiche per i font). Un cambio di font può spostare il testo: scegli un font di riserva di dimensioni simili.

9. Aggiungere cache e una rete di distribuzione dei contenuti. Un server lento ritarda tutto ciò che viene dopo. La cache permette al server o al browser del visitatore di riusare una pagina invece di ricostruirla, e una rete di distribuzione dei contenuti (CDN) serve i file da una posizione vicina al visitatore. La maggior parte dei buoni hosting e dei plugin di cache per WordPress offre entrambe. Controlla che gli aggiornamenti si vedano ancora dopo aver attivato la cache (LCP e tempo di risposta del server).

10. Misurare di nuovo e tenere d’occhio. Ripeti il passo 1 con le stesse pagine e confronta i valori. Cambia una cosa alla volta, così vedi cosa è servito. Ricontrolla fra un mese, perché i dati sul campo impiegano 28 giorni ad aggiornarsi, e nuovi plugin, caricamenti pesanti e nuovi widget disfano piano piano il lavoro. Segna in agenda un controllo di velocità ogni trimestre, oppure fallo prima di ogni aggiornamento più grande dei contenuti.

Quando chiedere aiuto

Rivolgiti a qualcuno di esperto se:

• i valori restano rossi dopo i passi da 1 a 9
• non riesci ad accedere alle impostazioni del tema, dell’hosting o dei plugin, o non sai chi può farlo
• il sito è costruito con codice su misura o con un page builder che nessuno mantiene
• la lentezza viene dal server stesso, per esempio quando il primo byte impiega secondi ad arrivare
• le pagine lente ti costano richieste o vendite, come nelle pagine di destinazione per la pubblicità o in un negozio online, e vuoi una configurazione misurata e monitorata invece di una correzione una tantum