Le metriche del PageSpeed Insights – nella nuova versione imposta da Google da qualche tempo – sono, per certi versi, abbastanza difficili da capire: è un dato di fatto che quelle metriche tendano a massacrare “virtualmente” qualsiasi sito, assegnando punteggi che posso rivelarsi imbarazzanti per i consulenti di tutto il mondo.
È una cosa molto comune, ad esempio, che siti anche di altissima qualità e del tutto privi di problemi tecnici, spesso anche in prima pagina su Google, finiscano per beccarsi uno score bassissimo – e questo avviene soprattutto lato mobile. Non è per forza la fine del mondo, intendiamoci: lato SEO dipende anche dai propri competitor, che non sempre la considerano. Se questi ultimi tendono a curare ed ottimizzare il PageSpeed, per intenderci, potreste pensare farlo anche voi – diversamente si tratterà di un fattore come tanti. E ogni sito, come sempre, fa storia a sè.
Del resto se installate un theme qualsiasi su WordPress, anche il più essenziale graficamente, sarà difficile trovarne uno che sia in grado di fornire 100/100 come punteggio. Cosa ancora più strana, tanti siti che per GTMetrix o PingDom sono messi obiettivamente bene, vengono comunque maltrattati dal PageSpeed Insights, che richiede un’analisi approfondita, e profondamente critica, del proprio sito per poter essere migliorato.
Come fare, a questo punto?
Capire meglio il PSI (PageSpeed Insights)
Se è vero che molti parlano dell’importanza del PageSpeed, in pochi credo siano riusciti a coglierne l’essenza. Tutto parte dall’analisi del cosiddetto waterfall, un grafico che molti tool per la misurazione della velocità permettono di visualizzare e che visualizza, per ogni singola chiamata HTTPS (quindi HTML, CSS, video, JS) il tempo necessario alla renderizzazione di quel contenuto. Questo ovviamente influisce sui tempi di caricamento, ma crea anche potenziali catene (chains) che possono rendere la visualizzazione del sito molto lenta – ed è il caso in cui, ad esempio, la grafica del sito sta ancora caricando mentre vediamo il markup HTML, oppure – caso ancora più comune – vediamo un form di ricerca o un filtro e non possiamo interagire subito con lo stesso.
Tutto questo rientro in un discorso di ottimizzazione sia del DOM complessivo (cioè della dimensione dell’HTML generato per ogni pagina, che sui temi vecchi tende ad “esplodere” ed essere senza controllo) sia delle modalità di organizzazione e disposizione del codice CSS e JS all’interno della pagina, seguendo anzitutto le good practices che quasi tutti ignorano (per questione di tempo, il più delle volte), ovvero:
- il CSS andrebbe tutto caricato nella head, cioè ad inizio pagina;
- il JS andrebbe, a sua volta, caricato a fine pagina;
- il markup HTML non dovrebbe contenere codice superfluo o poco utile;
- le chiamate HTTPS per ogni singolo componente devono essere minime, cosa possibile mediante minificazione e compressione (che pero’, sia ben chiaro, può dare origine ad incompatibilità e problemi di codifica).
Analisi del waterfall
Se cliccate tra le Opzioni per sviluppatore di Google Chrome su Network, troverete un tool per i waterfall integrato. Quindi, per quanto detto, più riuscite a rendere compatto un grafico del genere per ogni pagina, meglio sarà per almeno una parte del vostro PSI.
I tempi di caricamento più lunghi corrispondono a righe più lunghe, in alto a sinistra, mentre in basso troverete il dettaglio con tutte le chiamate della pagina. Ridurle non è cosa da poco, non esiste un singolo metodo e dovrete fare appello alle vostre skill più avanzate in fatto di web development.
Come migliorare il punteggio del PageSpeed Insights
L’ ottimizzazione del PSI (non il Partito Socialista Italiano, bensì il PageSpeed Insights) dipende da alcuni parametri, definiti da Google – e non sempre direttamente misurabili nel sito – che mi permetto di riassumere di seguito.
- Visualizzazione dei primi contenuti – Il tempo necessario per iniziare a vedere qualcosa nella pagina (quindi TTFB + tempo di rendering iniziale). Nella pratica, dovreste fare in modo che i contenuti appaiano il prima possibile, usando come riferimento la sequenza di caricamento del sito mostrato nelle screenshot di Google PSI.
- Indice velocità – Dovrebbe corrispondere con il tempo necessario perchè la pagina carichi correttamente del tutto, in modo completo. Avere un buon hosting e saperlo configurare anche lato cache e minify, in questo, rimane fondamentale.
- Tempo per interattività – Il tempo necessario perchè i menù e la parte interattiva si possano attivare; il sito andrebbe testato pazientemente con varie connessioni e dispositivi, aggiustandolo nel modo migliore e rendendolo utile per gli utenti, prima ancora che bello graficamente.
- Visualizzazione primi contenuti utili – Il tempo necessario perchè nella pagina ci siano contenuti visionabili dall’utente in modo significativo (più o meno, l’esistenza o meno di un above the fold significativo)
- Prima inattività CPU – Questa è una delle metriche più ostiche, in effetti: detta in modo semplice, misura il tempo necessario perchè il sito, a partire dalla sua visualizzazione, risponda correttamente ai click o alle ricerche nel sito. È in qualche modo la misura della responsività, e per migliorarla il più delle volte bisogna mettere mano internamente al sito ed operare su codice JS, CSS, PHP, hook o action che siano.
- Ritardo prima interazione potenziale max – Anche qui una metrica difficile da inquadrare, anche se abbastanza simile alla precedente: misura il tempo di ritardo massimo perchè il browser restituisca qualcosa all’utente. Quindi, in parole povere, se avete un form di ricerca dei vostri prodotti che è lento e risponde male, il punteggio sarà disastroso (e, nota bene, anche qui è ottimizzabile solo lato JS e CSS, con qualche accortezza sulla scrittura del codice).
Di fatto i SEO tendono a non vedere sempre di buon occhio questa metrica: anche perché è abbastanza insopportabile che sia così astrusa e complessa da ottimizzare. L’ottimizzazione del PSI, del resto, è un obiettivo importante (se mai decidessimo di dargli priorità) ma non dovrebbe mai essere un obiettivo fine a se stesso, perchè tende a diventare troppo lungo da realizzare e perché, in genere, non dovremmo mai perdere di vista l’obiettivo del nostro sito, che è quello di fare business. I SEO del resto questa metrica dovrebbero amarla, in teoria, perchè potrebbe inaugurare un modo nuovo per fare SEO: non esclusivo, a volte difficile da misurare, non obbligatorio intendiamoci, ma certamente di interesse nei prossimi anni del nostro amatissimo web. Molti altri, per onor di cronaca, criticano l’approccio di Google che impone vincoli troppo complicati da rispettare e, per certi versi, davvero troppo specialistici (la media dei webmaster più skillati neanche saprebbe come ottimizzare il DOM di una pagina, ad esempio).
Come (non) migliorare il PageSpeed Insights
Chiunque approcci alla materia tende, almeno nella mia esperienza, ad operare sul numero di plugin installati: più ce ne sono in WordPress, per intenderci, più il sito è lento. Questo è un aspetto fondamentale, ed in genere più plugin installate, più problemi potreste avere lato prestazioni. Ma questo è solo un aspetto, in realtà: il numero dei plugin influisce solo in parte sul PageSpeed Insights, ed in particolare sembra essere relativo al TTFB (Time To First Byte, una metrica che misura il tempo che passa tra la chiamata per l’apertura della pagina web e l’inizio della comunicazione – una sorta di latenza iniziale che è possibile misurare, per la cronaca, con lo strumento waterfall di Chrome). Resta vero che il problema di base rimane non risolvibile: se un plugin fornisse una funzionalità di core business per il mio sito, come potrei mai pensare di rimuoverlo? Solo per “far contento” Google? Francamente, la questione diventa incomprensibile e malposta, e ricorda i tempi in cui HTTPS era considerato un brutale fattore di ranking, prima ancora che un fattore di sicurezza del sito.
Il succitato TTFB che, per inciso, non è citato tra i fattori qui sopra – e non è nemmeno una misura univoca (capite quanto è complicato il problema?): può cambiare in base alla posizione geografica in cui vi trovate, per cui il TTFB misurato da Madrid sarà quasi certamente diverso, sullo stesso sito, da quello misurato da Roma. Quindi, alla fine, chi ha ragione? Quale misura del PSI è affidabile? Come fare ad ottimizzare un qualcosa di così difficile da definire (nelle aule di ingegneria si parlerebbe, in questi casi, di una misura probabilistica: non ci fate troppo caso, è un modo per dire che la misurazione è affetta da errori casuali, da un “rumore di fondo” non eliminabile – e prima ce ne rendiamo conto tutti, meglio è).
Del resto, scusatemi: se vi trovate tra le bellezze di Madrid non avete davvero niente di meglio da fare 🙂 ?
Come migliorare davvero il PageSpeed Insights
Nonostante il nome, e stando alla complessa documentazione ufficiale annessa, il PageSpeed Insights di oggi non dipende solo dalla velocità: dipende anche dall’aspetto del sito, dalla UX e dalla “responsività” dello stesso. Avete presente quando cercate in un form di una pagina web ed il sito tende a bloccarsi durante il caricamento? Oppure i casi in cui gli elementi funzionali non si trovano correttamente disposti nell’above the fold? Bene, da quello che siamo riusciti a capire analizzando il problema su vari siti, sembrerebbe che questi fattori siano anch’essi rilevanti.
Dagli esperimenti che ho fatto nelle ultime settimane, del resto, ho scoperto un po’ di cose interessanti sul PageSpeed, nel tentativo di migliorarlo, ovvero:
- dipende moltissimo dal theme che utilizzate
- dipende solo in parte dal numero di plugin installati
- regola pratica: meno CSS e JS infilate nel vostro theme, meglio è
- molti siti non sono, di fatto, ottimizzabili (si fa prima a cambiare theme o CMS, o a trascurare il problema)
- è questione anche di UX, non solo di prestazioni (Google sa “misurare” la UX: ad esempio ho ottenuto un miglioramento del punteggio ottimizzando l’aspetto del menu via CSS, o ancora riducendo l’altezza del popup dei cookie, e molti siti non a norma con il GDPR ottenevano punteggi stellari – un paradosso niente male, direi)
Una soluzione pratica può essere quella di minificare, ma a volte non basta: la cosa migliore è rimuovere direttamente gli script ed i CSS inutili da ogni singola pagina, avendo cura di organizzare bene il codice ed evitare che vengano caricate cose inutili per la singola pagina stessa (molti plugin WP sono un disastro, in questo: ad esempio Contact Form 7, nella sua versione attuale, aggiunge i propri CSS e JS su qualsiasi pagina del sito, quando in realtà dovrebbe farlo soltanto sulle pagine dove c’è un form). Capite bene, a questo punto, che per risolvere il problema servano skill abbastanza elevate, e che spesso il lavoro da svolgere sia francamente difficile da quantificare. Del resto il web è anche questo, e almeno in parte bisognerebbe accettarlo.
Una critica ragionata al PSI
Molti siti, del resto, non possono privarsi delle componenti JS e CSS come sarebbe virtualmente richiesto, e Google non può pensare di imporre una mentalità minimal ad ogni costo – soprattutto perchè, e qui lancio la mia piccola critica (spero costruttiva) è assurdo che i punteggi spesso finiscano per differire notevolmente tra una misurazione e l’altra (con Mueller che conferma candidamente questa cosa: secondo lui è normale!).
A Google convengono, in un certo senso, i siti che siano leggeri e scarni graficamente, anche perchè sono più facili da gestire ed indicizzare: in un test un po’ estremo che ho fatto giorni fa, ad esempio, mi sono accorto di come sia possibile ottenere 100/100 con il PageSpeed Insights.
Sì, c’è un modo per farlo.
Senza installare plugin.
Senza cambiare theme.
Senza ottimizzare il database.
Sapete come si fa? Creando un sito web di solo testo. Chissà allora (e lo scrivo con un pizzico di ironia di troppo, forse) che la soluzioni non sia quella di scrivere nuove grafiche fatte interamente in ASCII art, il glorioso formato con il quale gli informatici di quasi 20 anni fa si sono divertiti sulle BBC…
