Di un sito lento e di scarse Web performance a prima vista non si lamenta nessuno, non arrivano delle segnalazioni di errori, non si riempie la casella di posta di lamentele: le persone se ne vanno via e basta. Che si tratti di un blog, di un sito vetrina di un professionista, di un e-commerce desideriamo tutti che gli utenti interagiscano con il nostro sito.
L’analisi e l’ottimizzazione della velocità di un sito serve a questo, a togliere di mezzo la ragione più banale per cui qualcuno rinuncia prima ancora di aver visto quello che offrite.

Cosa succede quando una pagina si carica lentamente
Nel 1995, il peso medio di una pagina era appena 14,1 KB, mentre oggi supera i 2 MB con oltre 200 richieste al server. Per confronto, quando Internet muoveva i primi passi alla fine degli anni ’90, si utilizzavano ancora i floppy disk e ciascun dischetto poteva contenere solo 1,44 MB di dati. Microsoft Word poteva essere installato su una ventina di dischetti, mentre un videogioco completo come il famoso “Doom” era disponibile su 3 dischetti.
Ma come siamo arrivati a questo punto? Fondamentalmente, a causa di negligenza. Le connessioni sempre più veloci hanno portato gli sviluppatori a preoccuparsi sempre meno del peso delle immagini, della loro risoluzione, dei video e delle animazioni create tramite script vari.
L’esigenza di avere siti sempre più all’avanguardia ha contribuito al problema, ad avere le performance carenti e spesso critiche.
Il cervello umano percepisce come non istantaneo tutto ciò che supera i quattrocento millisecondi. Sotto il secondo l’attesa passa inosservata; oltre i due o tre secondi diventa una decisione consapevole, e la decisione quasi sempre è tornare ai risultati di ricerca.
C’è poi un aspetto meno ovvio. Un sito pesante costa qualcosa anche a chi lo visita. Buona parte del traffico arriva da telefono, spesso su connessioni non eccellenti e con piani a consumo: una pagina da due megabyte, moltiplicata per tutte le persone che la aprono, è traffico che pagano loro.
Un sito leggero è anche un sito più rispettoso, e non parlo solo di paesi lontani: basta uscire da una città e la copertura cambia.

Perché un sito WordPress diventa facilmente molto lento
Nella mia esperienza le cause sono quasi sempre le stesse quattro, in quest’ordine di frequenza.
Le immagini caricate alle dimensioni originali. Una fotografia da quattromila pixel inserita in uno spazio che ne occupa ottocento: il browser la scarica tutta e poi la rimpicciolisce. È il problema più diffuso e anche il più facile da risolvere.
I plugin accumulati negli anni. Ogni installazione aggiunge fogli di stile e script che vengono caricati su tutte le pagine, comprese quelle dove quel plugin non serve. Mi è capitato di trovare interi costruttori di pagine attivi per una sola sezione e caricati ovunque.
I temi con costruttore visuale integrato. Comodi da usare, ma generano molto più codice di quello che serve, e si portano dietro librerie intere per fare cose che si risolverebbero con poche righe.
L’hosting condiviso al minimo prezzo. È la causa meno frequente e la più difficile da aggirare: se il server impiega un secondo a rispondere, quel secondo non lo recuperate con nessun intervento sulle pagine.

Cosa misura davvero Google
Da qualche anno Google non guarda più un punteggio generico ma tre valori concreti, i Core Web Vitals. Vale la pena capirli, perché indicano esattamente dove intervenire.
Il primo è l’LCP, Largest Contentful Paint, il tempo che impiega a comparire l’elemento più grande della pagina, di solito l’immagine di testata. È quello su cui si lavora per primo, perché è ciò che l’utente percepisce come “il sito si è aperto”.
Il secondo è il CLS, Cumulative Layout Shift, che misura quanto la pagina si sposta mentre carica. È il fenomeno per cui state per premere un pulsante e all’ultimo momento il contenuto scivola in basso, perché è arrivata un’immagine di cui non erano dichiarate le dimensioni.
Il terzo è l’INP, Interaction to Next Paint, cioè quanto tempo passa tra un vostro clic e la reazione della pagina. Dipende soprattutto da quanto JavaScript sta girando in quel momento.
Migliorare questi tre valori ha un effetto anche sul posizionamento, ma è un effetto indiretto e non è l’argomento di questa pagina: di quel lato parlo nell’analisi SEO e posizionamento.

Come lavoro su un sito lento
Si comincia sempre misurando, mai preventivando. Con PageSpeed Insights si vede subito dove sta il tempo, e con GTmetrix si scende nel dettaglio di quale file lo sta consumando. Solo dopo si decide cosa vale la pena fare, perché non tutti gli interventi rendono uguale. L’ordine che seguo è quasi sempre lo stesso.
Prima di tutto le immagini: formati moderni, dimensioni reali per ogni schermo, e soprattutto far scoprire al browser l’immagine di testata il prima possibile invece di lasciarla in coda dietro fogli di stile e script. È il singolo intervento che sposta di più l’LCP, ad esempio su questo sito l’ho fatto scrivendo direttamente nel tema il preload e la priorità di caricamento, invece di affidarmi a un plugin. Ora l’elemento principale della pagina compare in pochissimi decimi di secondo e il contenuto non si sposta mentre la pagina sta ancora caricando.

PageSpeed Insights offre due serie di valori: oltre alla connessione classica da desktop simula anche la risposta di connessione lenta (un cellulare di fascia media) e in questo caso i tempi per l’apparizione del primo contenuto sono decisamente maggiori. La causa sono quasi sempre i fogli di stile che il tema carica prima di disegnare qualsiasi cosa, lo racconto perché è la norma, non l’eccezione: un sito reale non passa da rosso a verde in un pomeriggio. Si procede per interventi successivi, si misura ogni volta.
Poi si toglie quello che non serve: plugin caricati su tutte le pagine per una funzione usata in una sola, script rimasti attivi anni dopo che la funzione che li usava era stata rimossa, librerie di icone caricate per intero per usarne una decina.
Il codice viene per ultimo, ed è la parte più delicata perché tocca l’aspetto di tutte le pagine e va verificata una per una. Non è un lavoro che si fa in un pomeriggio, e chi ve lo promette non lo sta facendo davvero.

PageSpeed non misura solo il parametro velocità delle Web performance
Nella stessa schermata PageSpeed oltre alle prestazioni restituisce altri tre punteggi, che spesso vengono ignorati ma in realtà valgono quanto il primo.
Accessibilità, che verifica contrasto dei colori, etichette dei campi nei moduli, testi alternativi delle immagini, ordine dei titoli. Si tratta in parte dello stesso lavoro sul codice di cui parlo nella validazione secondo gli standard W3C. Se un sito è valido solitamente soddisfa anche questi parametri misurati da PageSpeed.
Best practice, cioè uso corretto di HTTPS, immagini nelle proporzioni giuste, nessun errore in console, nessuna libreria con vulnerabilità note.
SEO, un controllo di base su titoli, descrizioni, indicizzabilità e leggibilità da telefono.
Quando analizzo un sito li guardo tutti e quattro, perché un sito velocissimo ma inutilizzabile da chi naviga con uno screen reader ha risolto metà del problema.
Cosa si può ottenere e cosa no
Su un sito WordPress medio, con immagini gestite male e qualche plugin di troppo, si recupera moltissimo, e sono i casi in cui il lavoro si vede subito.
Ci sono però due limiti da conoscere prima di iniziare. Il primo è l’hosting: se il server risponde lentamente, quel ritardo è un livello sotto il quale non si può scendere, e l’unica soluzione è cambiare piano o gestore. Il secondo sono gli strumenti di terze parti, cioè chat, mappe, video incorporati e statistiche: se davvero servono tutte quante il costo di tempo è inevitabile.
Per questo a volte la risposta più utile che posso darvi è che con qualche ora di lavoro fatto bene sulle immagini risolvete gran parte del problema, e il resto può aspettare.
Lavoro con clienti di Torino e provincia, e da remoto in tutta Italia: su un intervento di questo tipo la distanza non cambia nulla.
Posso aiutarvi a velocizzare il vostro sito Web con:
- Misurazione iniziale e diagnosi delle criticità reali
- Ottimizzazione delle immagini e gestione corretta dell’elemento LCP
- Rimozione di plugin, script e librerie non più necessari
- Caricamento asincrono e differito di CSS e JavaScript
- Configurazione della cache e della compressione lato server
- Verifica dei Core Web Vitals prima e dopo l’intervento
