Google PageSpeed Insights: guida completa

Su PageSpeed Insights puoi trovare gli stessi dati che Google usa per definire quanto un sito sia veloce e usabile, e le metriche che contribuiscono al posizionamento del tuo sito web (e di quelli concorrenti). 

PageSpeed Insights esiste dal 2010 ma è diventato quello che vediamo oggi nel 2018, l’anno in cui Google ha ufficializzato l’uso della velocità di caricamento su mobile come fattore di ranking con l’aggiornamento ‘Speed’. Ma è stato nel 2021 che la sua popolarità ha fatto un balzo in avanti in seguito al lancio dei Core Web Vitals e del Page Experience Update, che hanno dato enfasi all’esperienza utente come criterio di valutazione dei siti web.

Cos’è e come funziona PageSpeed Insights

Pagespeed Insights (PSI) è uno strumento gratuito di Google che offre una valutazione dettagliata delle prestazioni dei siti. Ma potremmo anche dire che PageSpeed Insights misura l’esperienza utente del sito; e non è un caso perché velocità e UX sono due aspetti indissolubilmente legati. Oltre a ciò, il tool suggerisce come migliorarle entrambe.

Per rendere l’analisi più affidabile, PSI integra dati di laboratorio e dati raccolti da utenti reali. 

I dati di laboratorio arrivano da Lighthouse – strumento open source sviluppato da Google per analizzare la qualità delle pagine web –, che simula il caricamento della pagina in un browser Chrome in ‘condizioni standard’. 

I dati reali raccolti ‘sul campo’ (field data) provengono invece da Chrome User Experience Report (CrUX), un database di Google che raccoglie in forma anonima informazioni sull’esperienza degli utenti delbrowser durante la navigazione. 

A partire dai dati, PageSpeed Insights valuta le prestazioni di siti o pagine web attraverso singole metriche e punteggi complessivi – e le classifica come buone, da migliorare o scarse. In più analizza per la stessa URL l’accessibilità, l’applicazione delle buone pratiche e l’ottimizzazione per i motori di ricerca. 

A differenza di quanto ci si potrebbe aspettare però, accanto ai numeri, i report di PageSpeed Insights danno tantissimo spazio a raccomandazioni pratiche per migliorare l’esperienza utente e la SEO on page.

E, come gli strumenti per l’analisi del traffico di un sito web, anche PageSpeed Insights ti permette di ricavare informazioni sul tuo sito ma anche sui siti dei competitor. 

Core Web Vitals e altre metriche di PageSpeed Insights 

I Core Web Vitals – in italiano Segnali Web Essenziali – sono parametri che Google usa per misurare le prestazioni dei siti: in sintesi la loro velocità. E sono metriche che anche tu puoi sfruttare per farti un’idea di come gli utenti percepiscono i tuoi siti e applicazioni web.

Per capire le metriche di PageSpeed Insights, considera che Google esamina la velocità delle pagine web con l’intenzione di stabilire soprattutto:

• quanto tempo ci vuole per visualizzare i contenuti nella parte superiore e subito visibile della pagina;
• quanto tempo impiega il browser per caricare l’intera pagina;
• con quanta prontezza la pagina risponde a clic, tocchi, comandi da tastiera e altri input da parte dell’utente;
• se la pagina è visivamente stabile, cioè gli elementi che la compongono non si spostano in modo percettibile.

Vediamo i Core Web Vitals (CWV) uno per uno.

Per primo incontriamo l’LCP (Largest Contentful Paint), che misura il tempo impiegato per caricare l’elemento più grande visibile nella finestra, ad esempio un’immagine, un video o il titolo principale. Un buon LCP è inferiore ai 2,5 secondi, mentre un valore sopra i 4 secondi è considerato pessimo.

Segue l’INP (Interaction to Next Paint), che valuta la reattività complessiva della pagina considerando il tempo necessario per rispondere a tutte le interazioni utente, ed è ottimale se sotto i 200 millisecondi, pessimo sopra i 500. È noto per essere stato introdotto nel 2024 per sostituire un’altra metrica: FID (First Input Delay).

Infine c’è il CLS (Cumulative Layout Shift), che indica la stabilità visiva del sito, cioè se, e di quanto, gli elementi si spostano durante il caricamento. Adimensionale, rispecchia il rapporto tra l’entità del movimento e l’ingombro dell’elemento rispetto allo schermo. È considerato buono sotto 0,1 e pessimo sopra 0,25.

Oltre ai CWV veri e propri, PageSpeed Insights ti mostra altre 2 metriche rilevanti per le prestazioni del sito.

La prima, FCP (First Contentful Paint), registra il tempo in cui il browser visualizza il primo contenuto significativo, cioè un componente che l’utente può effettivamente leggere o con cui può interagire – come un titolo, un paragrafo di testo, un’immagine principale o un elemento di interfaccia utente. Un buon risultato è inferiore a 1,8 secondi; mentre misurazioni sopra i 3 secondi indicano un problema da risolvere. 

La seconda metrica è il TTFB (Time to First Byte), una misura del tempo che intercorre tra la richiesta di una risorsa e l’inizio dell’arrivo del primo byte di risposta: in pratica il tempo che il server impiega a rispondere alla prima richiesta dell’utente. È buono sotto gli 800 millisecondi, scarso sopra i 1800.

Google considera il TTFB una metrica ancora “sperimentale”, probabilmente perché è molto difficile da standardizzare in quanto influenzata dalle condizioni ambientali in cui avviene la misurazione.

Ecco una tabella riassuntiva delle metriche di PageSpeed Insights e dei valori ottimali e non. 

Metrica	Buono	Migliorabile	Scarso
LCP	inferiore a 2,5 s	2,5–4,0 s	superiore a 4,0 s
INP	inferiore a 200 ms	200–500 ms	superiore a 500 ms
CLS	inferiore a 0,1	0,1–0,25	superiore a 0,25
FCP	inferiore a 1,8 s	1,8–3,0 s	superiore a 3,0 s
TTFB	inferiore a 800 ms	800–1800 ms	superiore a 1800 ms

Come avrai notato, una caratteristica comune a tutte le metriche di PSI è che sono considerate tanto migliori quanto più sono basse.

Cose utili da sapere su PageSpeed Insights e le sue metriche

Per calcolare le metriche PageSpeed Insights fa riferimento non alla media ma al 75° percentile: il che significa che perché una metrica risulti buona almeno il 75% degli utenti deve aver avuto un’esperienza positiva, e quindi percepito valori di LCP, FID, CLS ecc. al di sotto delle soglie raccomandate.

È importante non fissarsi sui punteggi e considerarli orientativi, visto che: 

• qualsiasi punteggio verde (sopra 90) è considerato buono, ma dati di laboratorio buoni non significa necessariamente esperienze positive per gli utenti reali;
• i valori dipendono dalle condizioni ambientali, quindi se effettui le misurazioni con altri software vedrai che i risultati non coincidono, e spesso variano anche se usi lo stesso strumento in momenti diversi;
• per avere un sito veloce per l’utente non hai bisogno di un punteggio PageSpeed Insights di 100/100. 

Quello che dovresti fare è concentrati sul passare la valutazione complessiva dei Core Web Vitals piuttosto che sul raggiungimento del punteggio perfetto… e, come sempre, sui contenuti. 

Google PageSpeed Insights non individua in modo certo le cause di eventuali lentezze ma in compenso ti offre linee guida molto dettagliate sulle azioni che potrebbero permetterti di offrire all’utente un’esperienza ottimale, che sarebbe poi il reale obiettivo delle misurazioni di questo strumento.

Come usare PageSpeed Insights

Usare PageSpeed Insights è davvero facile: basta accedere alla homepage; non c’è neanche bisogno di fare il login.

In alto trovi subito il campo in cui inserire l’URL di cui vuoi conoscere le prestazioni – di un qualsiasi contenuto del tuo sito così come di una pagina concorrente – e cliccando su Analizza puoi avviare l’analisi. 

PageSpeed Insights descrive separatamente l’esperienza su Dispositivi mobili e Computer, analizzando le stesse metriche su mobile e su pc. 

Nel primo caso i dati di laboratorio (da Lighthouse) vengono ottenuti simulando un dispositivo mobile di fascia media (ad esempio, un Moto G4) con una connessione 4G lenta; nel secondo viene simulato un pc con browser Chrome desktop e connessione cablata.

Poiché negli ultimi anni Google è passato ad applicare il principio ‘mobile-first’ ovunque possibile e definisce indicizzazione e posizionamento in base alla versione del sito su dispositivi mobili, non c’è bisogno che ti dica quale tra le due viste è la più importante. Addirittura c’è chi consiglia di puntare a ottimizzare solo i punteggi relativi ai dispositivi mobili e lasciare che quelli della vista Computer migliorino come naturale conseguenza.

Scopri com’è l’esperienza dei tuoi utenti reali

Nel quadro sull’esperienza dei tuoi utenti reali PageSpeed Insights ti mostra i dati che provengono dal Chrome User Experience Report (CrUX) – riferiti agli ultimi 28 giorni, a vari dispositivi mobili e a tutte le versioni di Chrome.

In alto a destra vedi a quali parti del tuo sito sta facendo riferimento. 

In molti casi la fonte sarà Origine, che significa che PageSpeed Insights sta aggregando dati sulle esperienze utente di tutto il sito, poiché per l’URL che hai inserito non sono disponibili abbastanza dati relativi a utenti reali – di solito perché si tratta di una pagina recente o con poco traffico. 

In caso contrario leggerai Questo URL e vedrai i dati specifici del contenuto.

Potresti anche non vedere Nessun dato in questa sezione, perché Google non riesce a raccogliere informazioni sufficienti neanche facendo riferimento all’intero sito.

Poi iniziano le valutazioni vere e proprie e, grazie ai colori, a colpo d’occhio puoi farti un’idea del comportamento del sito: il verde indica i risultati positivi, l’arancio quelli migliorabili e il rosso quelli da correggere assolutamente.

La prima informazione che ti dà Google in questo quadro è se hai superato o meno la Valutazione dei Core Web Vitals complessiva sulla base dei dati rilevati negli ultimi 28 giorni.

Seguono le metriche che rappresentano l’esperienza dei tuoi utenti, a iniziare dai Core Web Vitals veri e propri:

• Largest Contentful Paint (LCP) 
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)

Per ciascuna trovi un grafico in cui una barra segmentata rappresenta la percentuale di utenti che hanno avuto esperienze buone, migliorabili o negative.

Accanto al grafico trovi anche i numeri: il valore del parametro rispetto al 75° percentile – in secondi o millisecondi – e le percentuali di utenti che hanno avuto un’esperienza buona, scarsa o da migliorare.

Subito dopo hai accesso agli stessi grafici e allo stesso tipo di informazioni riguardo alle altre metriche rilevanti:

• First Contentful Paint (FCP)
• Time to First Byte (TTFB).

Diagnostica i problemi di prestazioni

La sezione successiva è dedicata a trovare criticità – cioè buone pratiche non ancora applicate – e sfrutta dati di Lighthouse.

Nel primo quadro c’è un riepilogo delle valutazioni della pagina, con un punteggio da 0 a 100 per ognuno di questi aspetti, che poi verranno esaminati singolarmente: 

• Prestazioni
• Accessibilità
• Best practice
• SEO.

Prestazioni 

Nel report Prestazioni trovi di nuovo i Core Web Vitals (FCP, LCP, CLS), ma misurati da Lighthouse.

Inoltre ci sono 2 nuove metriche.

Il Total Blocking Time (TBT) misura il tempo iniziale in cui la pagina web non è in grado di rispondere alle interazioni dell’utente perché il thread principale del browser è occupato a caricare le risorse per la visualizzazione. Su mobile, è buono sotto i 200 millisecondi, scarso sopra i 600.

Lo Speed Index, invece, rappresenta la velocità di caricamento del contenuto visibile di una pagina web. Su mobile, è buono sotto i 3,4 secondi e scarso sopra i 5,8.

Metrica	Buono	Migliorabile	Scarso
TBT Mobile	inferiore a 200 ms	200–600 ms	superiore a 600 ms
TBT Desktop	inferiore a 150 ms	150–350 ms	superiore a 350 ms
Speed Index Mobile	inferiore a 3,4 s	3,4–5,8 s	superiore a 5,8 s
Speed Index Desktop	inferiore a 1,3 s	1,3–2,3 s	superiore a 2,3 s

In questa sezione vedrai prima di tutto un punteggio complessivo che è la media pesata di FCP, LCP, TBT e CLS.

Se ci vai sopra con il puntatore, compare un grafico che mostra in che proporzione i diversi parametri contribuiscono al risultato finale.

Questi sono i pesi attribuiti a ogni metrica attualmente:

Metrica	Peso
First Contentful Paint	10%
Indice di velocità (Speed Index)	10%
Largest Contentful Paint	25%
Total Blocking Time	30%
Cumulative Layout Shift	25%

Treemap

Poco più giù trovi il link Visualizza Treemap che ti porta alla pagina dedicata.

Il Treemap è un diagramma che rappresenta le risorse impiegate dai diversi script JavaScript caricati da una pagina e serve a individuare le cause di eventuali rallentamenti e gli script inutili.

Diagnostica

Segue la sezione Diagnostica – in inglese Performance Audits –, che raccoglie tutte le raccomandazioni di PageSpeed Insights adattate al sito che stai analizzando, ordinate in base all’urgenza dell’intervento.

Per primi vengono mostrati i consigli per risolvere i problemi più gravi (segnalati da un triangolo rosso), seguiti da quelli che puntano ad affrontare criticità di livello intermedio, indicati da un quadrato giallo. Ulteriori suggerimenti che non rientrano nelle best practice in senso stretto sono accompagnati da un cerchio bianco.

Usando i link in alto a destra puoi isolare le raccomandazioni che riguardano una metrica specifica (FCP, LCP, TBT o CLS).

Insights

La sezione Insights si presenta come un’alternativa sperimentale a Diagnostica, e dovrebbe sostituirla entro il 2025.

Puoi accedere facendo clic sul pulsante Try insights che compare a destra subito sotto il Treemap.

Vedrai una serie di raccomandazioni specifiche per il sito analizzato, in molti casi accompagnate dai potenziali risparmi di tempo o dati inviati: le stesse che trovi nel pannello Prestazioni di Chrome DevTools.

Controlli superati

Facendo clic su Mostra, è possibile aprire la sezione che contiene i controlli che hanno avuto esito positivo.

Un cerchio verde segnala le buone pratiche già applicate sul sito mentre un cerchio bianco indica ulteriori accorgimenti che potrebbero migliorare l’esperienza utente.

Raccomandazioni di PageSpeed Insights

Vediamo tutte le raccomandazioni si PageSpeed Insights che puoi trovare, a seconda dei casi, nella sezione Diagnostica o nei Controlli superati.

Elimina le risorse di blocco della visualizzazione

Questa sezione si occupa del rallentamento della prima visualizzazione della pagina da parte di JavaScript e CSS. PageSpeed Insights ti segnala le risorse problematiche e per ognuna la potenziale riduzione del tempo di caricamento che potresti ottenere eliminandola.

Per risolvere questa criticità Google suggerisce di:

• rendere il codice JS più compatto, ad esempio usando forme abbreviate (shorthand) per ridurre più proprietà a una sola;
• minificare JavaScript;
• eliminare codice JS inutilizzato;
• minificare il CSS;
• eliminare il CSS inutilizzato.

Vediamo come applicare queste raccomandazioni.

Riduci il codice JavaScript inutilizzato

Come saprai può capitare che i plugin WordPress aggiungano codice JS anche dove non è indispensabile. Qui PageSpeed Insights ti segnala i miglioramenti che potresti ottenere eliminando alcuni script, che trovi indicati nell’elenco a fine sezione. 

Si tratta di script che rallentano il caricamento iniziale della pagina perché:

• si trovano nel <head> del documento;
• non hanno un attributo defer;
• non hanno un attributo async.

Ma dovrai essere tu a verificare se siano superflui o meno.

Per localizzare il codice JavaScript inutile (e il CSS inutile) hai a disposizione strumenti come DevTools di Chrome, accessibile col tasto destro facendo clic su Ispeziona.

Vai sul menu nell’angolo in alto a destra e poi su Altri strumenti > Copertura.

Se necessario fai clic sul pulsante Avvia la registrazione per visualizzare i dati.

Per ogni pagina che apri puoi verificare che percentuale del codice è stata caricata e capire dov’è il caso di intervenire.

Puoi cliccare sui singoli URL per ispezionarli.

Minimizza JavaScript

Minimizzare o minificare il codice JavaScript significa renderlo più leggero eliminando elementi superflui come spazi bianchi, commenti, interruzioni di linea, o accorciando i nomi di variabili e funzioni.

Nella sezione della Diagnostica dedicata, PageSpeed Insights ti indica quali script JS potrebbero essere resi più compatti.

Ci sono plugin WordPress che se ne occupano; e spesso la funzione è inclusa nei plugin di cache, per esempio W3 Total Cache. 

Se il tuo sito non è su WordPress, puoi comprimere JS sfruttando strumenti gratuiti come UglifyJS (consigliato anche da Google).

Riduci i contenuti CSS inutilizzati

Nel caso del CSS, PageSpeed Insights segnala i contenuti CSS che potrebbero essere superflui in quanto:

• non possiedono un attributo disabled;
• non hanno un attributo media che corrisponda specificamente al dispositivo dell’utente.

Se hai letto fin qui, avrai visto che Chrome DevTools può aiutarti anche a localizzare il CSS da rimuovere.

Minimizza CSS

Allo stesso modo del codice JavaScript, anche il CSS può essere minificato. E di nuovo su WordPress ci vengono in aiuto sia plugin dedicati che plugin di cache come LSCache oppure WP Rocket.

Per qualunque CMS inoltre, esistono strumenti capaci di minimizzare il codice durante la compilazione – per esempio Webpack, Gulp o Rollup.

Pubblica immagini in formati più recenti

Qui PageSpeed Insights ti mostra lo spazio che potresti liberare passando a un formato delle immagini più efficiente, in kibibyte (o KiB, pari a 1024 byte).

Infatti, e se frequenti questo blog lo saprai, il formato delle immagini per il web andrebbe scelto tra AVIF o WebP per avere la massima compressione senza rinunciare alla qualità.

Ovviamente esistono plugin per ottimizzare le immagini su WordPress in automatico, capaci anche di convertirle in formati moderni ed efficienti come il WebP – che agiscono a ogni caricamento ma anche ‘retroattivamente’ sui media già presenti in libreria. Su questo sito per esempio, usiamo da anni ShortPixel Image Optimizer.

Se usi un altro CMS non scoraggiarti perché è sempre possibile ottimizzare le immagini con strumenti esterni semplici da usare come TinyPNG, Optimizilla, ecc.

Usa immagini di dimensioni adeguate

Probabilmente lo saprai: a parità di formato le immagini più grandi sono più pesanti. Ecco perché quelle di dimensioni molto superiori rispetto allo spazio che occupano visivamente sulla pagina sovraccaricano inutilmente il server, e in poco tempo possono rendere il tuo sito lento. 

Idealmente l’immagine dovrebbe essere della stessa larghezza e altezza del riquadro in cui verrà collocata. Però, poiché l’obiettivo finale è ridurre i byte occupati, vogliamo anche comprimerla, e ci tornano utili gli stessi strumenti che useremmo per ottimizzare le immagini per la SEO.

Dal canto suo PageSpeed Insights ti segnala le immagini che potresti ridimensionare e il potenziale ‘alleggerimento’.

Codifica in modo efficace le immagini

La documentazione ufficiale di PageSpeed Insights suggerisce alcuni accorgimenti specifici per rendere la codifica delle immagini più efficace:

• usare una CDN per le immagini;
• sostituire le GIF animate con i video in caso di grandi dimensioni;
• pubblicare immagini adattabili, cioè responsive, eventualmente sfruttando strumenti che ridimensionano le immagini in automatico in base al dispositivo.

Elemento Largest Contentful Paint

In questa sezione puoi controllare i dettagli della visualizzazione dell’elemento più grande della pagina, il Largest Contentful Paint o LCP. 

Nel caso LCP sia un’immagine – di solito lo è – PageSpeed Insights schematizza il processo in 4 fasi:

• TTFB cioè Time to First Byte
• Ritardo di caricamento
• Tempo di caricamento
• Ritardo di rendering.

Trattandosi di un’immagine, puoi migliorare tutti i parametri applicando i suggerimenti per l’ottimizzazione che abbiamo già visto.

Pubblica le risorse statiche con policy della cache efficaci

Questo controllo rileva eventuali pagine il cui caricamento potrebbe diventare più veloce con l’attivazione di una cache con Time To Live (TTL), cioè un parametro di configurazione che permette di definire per quanto tempo l’elemento resterà in memoria prima di essere ricaricato dal server.

Gli elementi immagine non hanno width e height esplicite

PageSpeed Insights segnala quali immagini non hanno larghezza e altezza definite attraverso gli attributi width e height. Ti dà così la possibilità di inserirli dove mancano per ridurre le variazioni di layout durante il caricamento della pagina (e migliorare il CLS).

Evita di usare un DOM di dimensioni eccessive

Il Document Object Model (DOM) è il modello dinamico che il browser crea per rappresentarsi internamente la pagina e interagire con essa – a partire dall’HTML e dal CSS e integrando eventuali modifiche applicate con JS.

Se ti intendi di codice, puoi ottimizzare le dimensioni del DOM rimuovendo i nodi non visualizzati al caricamento della pagina e inserirli solo dopo un’interazione utente pertinente.

PageSpeed Insights ti dà alcune informazioni sul numero totale degli elementi che lo compongono, la sua profondità massima e gli elementi secondari massimi.

Evita di concatenare le richieste fondamentali

Qui si parla di catene di richieste critiche – al server da parte del browser – di risorse indispensabili alla visualizzazione iniziale della pagina che devono essere completate in ordine, poiché ogni risorsa dipende dalla precedente.  

Com’è facile intuire, durante il processo si possono accumulare ritardi che danneggiano i Core Web Vitals, e il rischio aumenta in modo proporzionale alla lunghezza della catena.

La documentazione ufficiale di Lighthouse offre vari spunti per evitarlo.

• Ridurre al minimo il numero di risorse critiche: identificare JS o CSS non essenziali, eliminarli o posticiparne il download – contrassegnandoli con async e defer nel <head> della pagina.
• Ridurre il numero di byte critici, per esempio ricorrendo alla minificazione e alla riduzione del codice.
• Ottimizzare l’ordine in cui vengono caricate le risorse critiche: fare in modo che il browser scarichi per primi gli asset critici assegnando il tag preload.

Rimanda immagini fuori schermo

Qui PageSpeed Insights ci raccomanda di attivare il caricamento differito delle immagini che non fanno parte della finestra immediatamente visibile all’utente.

Su WordPress il lazy load è ormai una funzione nativa ma nella nostra guida puoi scoprire come renderla più efficace.

Attiva la compressione del testo

Anche comprimere i testi è una buona pratica per ridurre la quantità di dati caricati e di solito è attiva in automatico lato server. 

Questa sezione mostra un elenco degli eventuali testi del tuo sito che non sono dotati di un’intestazione content-encoding impostata su br, gzip o deflate; in più ti informa su quanti byte potresti risparmiare comprimendo ogni file con GZIP.

Se le dimensioni originali di una risposta sono inferiori a 1,4 KB o se il risparmio potenziale è inferiore al 10% delle dimensioni originali, PageSpeed Insights non segnala il testo come ottimizzabile.

Poiché sappiamo che avere un sito veloce è importante, in SupportHost offriamo a tutti i nostri clienti la possibilità di attivare la compressione gzip automatica in un attimo attraverso cPanel, il pannello di controllo dell’hosting per gli utenti.

Precollegati alle origini necessarie

Questa sezione di PageSpeed Insights ti segnala le pagine che hanno bisogno di scaricare risorse esterne importanti – per esempio Google Fonts, CDN o script esterni come YouTube, Analytics, ecc. – e non contengono <link rel=preconnect>, con il quale dovresti comunicare al browser che vuoi che si connetta alle piattaforme esterne il prima possibile.

Ad esempio, per anticipare il DNS per Google Analytics potresti usare nell’<head> della pagina il tag:

<link rel="preconnect" href="//www.google-analytics.com">

In genere il preconnect velocizza il caricamento della pagina ma troppi preconnect rischiano di ottenere l’effetto opposto, quindi limitane l’uso ai domini che ti serviranno nei primi secondi di caricamento. 

L’alternativa è ricorrere al tag rel=“dns-prefetch”, che ha bisogno di meno risorse; però è meno efficace nell’accelerare il caricamento. In questo caso, dovresti inserire:

<link rel="dns-prefetch" href="//www.google-analytics.com">

Il tempo di risposta iniziale del server è stato breve

Se leggi questa frase significa che il controllo sulla velocità del server è andato a buon fine. In caso contrario vedrai “Riduci i tempi di risposta del server” – cioè il tempo necessario al browser per ricevere il primo byte dei contenuti della pagina.

Il tempo di risposta è la componente più rilevante del TTFB, al quale possono contribuire anche ricerche DNS e reindirizzamenti.

Cosa può fare un utente per ottimizzare la risposta iniziale del server?

• scegliere un hosting più veloce;
• attivare una CDN per distribuire i contenuti da server più vicini agli utenti;
• utilizzare un sistema di cache lato server.

Le soluzioni hosting di SupportHost integrano i sistemi di cache Memcached e Opcache. Inoltre con noi puoi scegliere un piano hosting con LiteSpeed e sfruttare il plugin WordPress LSCache.

Google consiglia di occuparsi innanzitutto dell’hosting, direttamente e indirettamente, applicando le buone pratiche per migliorare la velocità di un sito web; anche perché tanti utenti sperimenteranno il sito ‘senza cache’. 

Visto che i metodi per ottimizzare un sito possono cambiare, è importante cercare istruzioni specifiche per il CMS, per esempio su come velocizzare PrestaShop, velocizzare WordPress ecc… Per esempio su WordPress il tempo di risposta del server può essere ridotto in primo luogo limitando i plugin pesanti e disinstallando quelli inutili. 

Evita i reindirizzamenti tra più pagine

Come probabilmente saprai, le pagine web spostate devono essere reindirizzate, in modo che il browser possa trovarle al nuovo indirizzo e non si generino errori 404. 

Google consiglia di ricorrere ai reindirizzamenti solo quando davvero necessario visto che rallentano il caricamento delle pagine, e di assicurarsi che puntino direttamente alla pagina di destinazione per non posticipare ancora e senza motivo la visualizzazione da parte dell’utente. Per saperne di più su come gestire queste situazioni, puoi leggere la nostra guida al redirect 301 e l’elenco completo dei codici di stato HTTP.

Inoltre nella documentazione ufficiale leggiamo anche che è fondamentale evitare i reindirizzamenti nelle risorse critiche, come file HTML, CSS, script JS e font web necessari per la visualizzazione iniziale.

Sconsigliatissimo anche sfruttare i reindirizzamenti per mostrare agli utenti la versione per dispositivi mobili della pagina.

Qui PageSpeed Insights invita anche chi usa React Router a ridurre al minimo l’utilizzo del componente <Redirect> per la navigazione tra route.

Nella sezione Evita i reindirizzamenti tra più pagine infine segnala eventuali problemi su contenuti specifici.

Usa formati video per i contenuti animati

In caso di GIF di grandi dimensioni, Google suggerisce di valutare formati video più efficienti, come MPEG4/WebM.

In questa sezione, PageSpeed Insights suggerisce di sfruttare servizi che permettono di visualizzare le GIF come video HTML5, spesso associati alle CDN per immagini.

Un’altra soluzione arriva da piattaforme come FFmpeg, che permettono di convertire le GIF in formato MP4 o WebM (più leggero ma non supportato da tutti i browser).

Riduci al minimo l’utilizzo di codice di terze parti

Qui PageSpeed Insights, come Lighthouse, segnala le pagine in cui il codice di terze parti – cioè proveniente da un dominio diverso da quello dell’URL che hai controllato – blocca il caricamento per almeno 250 ms.

In generale Google consiglia di limitare l’uso di script esterni. In molti casi però è difficile rinunciare ai vantaggi che offrono – per esempio quando si tratta di pulsanti social media, video integrati da piattaforme esterne ecc. – e bisogna piuttosto ottimizzarne il caricamento.

Ecco alcuni metodi consigliati che ormai inizieranno a suonarti familiari:

• stabilire connessioni anticipate con i tag <link rel=“preconnect”> o <link rel=“dns-prefetch”>;
• usare gli attributi async o defer nei tag <script> per dire al browser di caricare gli script in modo asincrono, evitando che rallentino la costruzione del DOM;
• aggiungere il lazy load al codice per caricare gli script di terze parti solo quando serve;
• valutare di ospitare gli script localmente, tenendo conto che significa assumersi l’onere di tenerli aggiornati.

Come puoi vedere nell’immagine, c’è un’ulteriore opzione…

Carica risorse di terze parti tramite caricamento lento con i facade

Un facade (facciata) è una sorta di segnaposto che sostituisce una risorsa pesante esterna con una leggera, per esempio un’immagine statica o un pulsante, fino al momento in cui verrà caricata in risposta all’interazione dell’utente. È una variante del caricamento lento classico consigliata anche da PageSpeed Insights.

Evita animazioni non composite

Le animazioni sono cambiamenti visivi che riguardano uno o più elementi di una pagina web e permettono di creare transizioni o effetti dinamici, come il cambio di colore di un bottone quando ci si porta sopra col mouse (hover).

Le animazioni non composite sono problematiche perché richiedono il ricalcolo del layout (reflow) o il ridisegno dell’elemento (repaint) e comportano più lavoro da parte del browser. Rischiano di essere visualizzate in modo non fluido e causare spostamenti del layout, soprattutto su dispositivi con risorse limitate.

Tra le proprietà CSS che portano ad animazioni non composite ci sono:

• width
• height
• margin
• padding
• top
• left.

Per evitare di appesantire il caricamento puoi preferire proprietà CSS che non richiedono repaint o reflow, per esempio transform e opacity, come spiegato nella documentazione di Google.

Se vuoi capire meglio di cosa stiamo parlando, potrebbe interessarti la nostra guida facile per imparare il CSS.

Evita payload di rete enormi

In PageSpeed Insights il payload rappresenta l’insieme dei dati trasferiti dal server al browser in una singola richiesta o risposta di rete per caricare una pagina web.

In questa sezione PageSpeed Insights segnala eventuali payload di rete di grandi dimensioni che rallentano il caricamento della pagina.

Anche se trovi tra i controlli superati che “Vengono evitati payload di rete enormi”, potresti comunque scoprire di avere dei contenuti migliorabili.

Per ridurre i paylod puoi applicare i suggerimenti già visti per alleggerire le immagini, minificare il codice ecc.; in più, su WordPress, potresti:

• mostrare riassunti (excerpt) invece del contenuto completo;
• ricorrere al tag read more per nascondere parti dei contenuti finché non sono necessarie all’utente;
• installare un plugin per il caricamento differito dei commenti.

Indicatori e misure User Timing

Per migliorare le prestazioni del sito, PageSpeed Insights consiglia anche di collegarlo all’API User Timing – uno strumento JavaScript che serve a misurare le prestazioni in relazione a eventi personalizzati. L’API indica, per esempio, quanto tempo passa tra il clic su un bottone e il caricamento di una sezione, quanto tempo impiega un carosello a mostrare un’immagine o qualsiasi altro momento chiave definito da te.

Tempo di esecuzione JavaScript

Il thread principale del browser è il processo che coordina l’esecuzione del codice, l’aggiornamento della pagina e la risposta alle azioni dell’utente.

Quando eseguire JavaScript richiede molto tempo, le prestazioni della pagina peggiorano perché il thread principale è impegnato a eseguire gli script e non può visualizzare i contenuti o rispondere a interazioni da parte dell’utente.

Per accorciare il tempo di esecuzione di JavaScript, Google suggerisce di minificare e ridurre il codice come già visto, ma non solo. Puoi ricorrere alla suddivisione del codice – tecnica che permette di inviare JavaScript in porzioni più brevi per migliorare i tempi di avvio e la reattività della pagina.

Oppure anche ridurre le interruzioni di rete memorizzando nella cache il codice con il pattern PRPL, che consiste in:

• Preload: precaricare le risorse critiche;
• Render: mostrare la prima schermata appena possibile, per esempio inserendo il CSS critico nell’<head> del HTML, o implementando il Server-Side Rendering (SSR) – cioè generando l’HTML sul server in modo che il browser lo trovi già pronto.
• Pre-cache: memorizzare in cache il resto delle risorse prima che siano necessarie;
• Lazy-load: attivare il caricamento differito per gli elementi che non contribuiscono alla visualizzazione iniziale.

Riduci al minimo il lavoro del thread principale

PageSpeed Insights segnala le pagine che mantengono il thread principale occupato per più di 4 secondi.

Quando non ce ne sono, e leggi che “Il lavoro del thread principale è ridotto al minimo”, vedrai ugualmente una tabella con i tempi delle attività svolte.

Come si può liberare il più possibile il main thread per avere un sito veloce?

Google dà diversi consigli che abbiamo già visto:

• ottimizzare JavaScript di terze parti
• ridurre il carico di javascript con code splitting
• rimuovere codice inutilizzato
• implementare il CSS critico
• minificare il CSS
• rimandare il CSS non critico.

E ulteriori raccomandazioni:

• ridurre i calcoli di stile – limitando la quantità e la complessità delle regole CSS;
• evitare layout grandi, complessi o che richiedono continui ricalcoli;
• usare solo proprietà gestibili attraverso il compositore e contenere il numero di layer;
• usare i web worker – processi separati che eseguono codice in background nel browser senza rallentare il caricamento o l’interazione della pagina;
• ritardare i gestori di input – cioè dare priorità alla visualizzazione iniziale della pagina anziché all’interattività (poiché migliora l’esperienza complessiva);
• semplificare il paint – fase in cui il browser colora i pixel sullo schermo – e ridurre le aree di pittura.

Assicurati che il testo rimanga visibile durante il caricamento dei caratteri web

Questa sezione raccomanda di mantenere il testo visibile durante il caricamento dei web font, implementando la funzionalità CSS font-display.

O se tutto è a posto troverai tra i controlli superati: “Tutto il testo rimane visibile durante il caricamento dei caratteri web”.

L’immagine Largest Contentful Paint non è stata caricata tramite caricamento lento

Se leggi questo, il controllo ha avuto esito positivo, perché il lazy load non deve essere applicato all’immagine principale che corrisponde al LCP, né ad altre immagini che fanno parte della finestra immediatamente visibile. 

Usa listener passivi per migliorare le prestazioni dello scorrimento

Contrassegnare come passivi i listener, cioè i gestori di eventi legati allo scorrimento della pagina come tocco e scroll velocizza il browser che così non è costretto ad aspettare istruzioni da parte degli script.

Evita document.write()

L’uso della funzione JS document.write() può ritardare la visualizzazione della pagina. Ecco perché Google consiglia fortemente di evitarla e rimuoverla se presente. In caso di script di terze parti, puoi sostituirla con il caricamento asincrono.

Ha un tag <meta name=“viewport”> con width o initial-scale

PageSpeed Insights raccomanda di usare un tag <meta name=“viewport”>, fondamentale per rendere la pagina responsive ed evitare il ritardo di 300 millisecondi sui tocchi dell’utente (input) su dispositivi mobili – tempo di attesa che serve ai browser mobile per rilevare un eventuale doppio tocco.

Rimuovi moduli duplicati nei bundle JavaScript

Qui PageSpeed Insights chiede di rimuovere eventuali moduli JavaScript duplicati di grandi dimensioni. Infatti può capitare che le stesse librerie JS vengano inserite più volte nel codice, appesantendo i file da scaricare e sprecando banda.

Evita di pubblicare codice JavaScript precedente in browser moderni

I polyfill e le trasformazioni sono codici aggiuntivi che permettono ai browser più datati di interpretare funzionalità JavaScript moderne, ma sono un inutile appesantimento se il sito è visitato da browser recenti. Per fortuna è possibile (e consigliato) fare in modo che il browser generi due versioni della pagina e serva quella più appropriata al caso.

Accessibilità

Questa sezione della Diagnostica di PageSpeed Insights mostra una serie di suggerimenti per rendere il sito fruibile e migliorare l’esperienza utente anche per le persone con disabilità.

Qui troviamo una lunga serie di controlli che hanno molto a che fare con la visibilità e leggibilità degli elementi della pagina, a partire dai colori dei testi.

Anche qui, oltre alle criticità segnalate dal triangolo rosso, trovi la lista dei controlli superati.

Ci sono anche i controlli non applicabili da PageSpeed Insights, che vanno necessariamente eseguiti a mano, come spiegato da Google nella guida Come eseguire controlli sull’accessibilità, e consigliato per capire più a fondo l’esperienza utente delle persone con disabilità.

Best practice

La sezione Best Practice di PageSpeed Insights offre una serie di raccomandazioni basate sulle migliori pratiche riconosciute nel campo dello sviluppo web per migliorare le prestazioni e l’esperienza utente delle pagine web.

Nella parte alta trovi la lista delle criticità e più giù i controlli superati e quelli non applicabili.

SEO

La sezione SEO in PageSpeed Insights controlla elementi fondamentali per la SEO on page, come la presenza del tag title e della metadescrizione, degli attributi alt per le immagini o del rel canonical; la possibilità di accesso da parte dei crawler, la scansionabilità dei link ecc.

Contiene la lista degli elementi da controllare manualmente e di quelli superati.

Punteggi PageSpeed Insights e posizionamento SEO

Da quando i Core Web Vitals sono diventati fattori di ranking di Google, si sono sollevati tanti interrogativi su quanto queste metriche incidano davvero sul posizionamento nelle SERP.

Qualche anno fa ci siamo presi la briga di analizzare 60.000 risultati di ricerca per capire quale fosse la correlazione tra Core Web Vitals e ranking e abbiamo scoperto, tra le altre cose, che i primi 10 risultati di ricerca avevano un punteggio medio di circa 78 e che meno del 15% di queste andava oltre 90.

Nel complesso i risultati di questo studio confermano quanto si poteva dedurre dalle dichiarazioni di John Mueller – una delle voci più note di Google –, cioè che l’esperienza utente può contribuire al posizionamento di un sito ricco di contenuti pertinenti e rilevanti, ma non basta avere punteggi alti su PageSpeed Insights per conquistare la prima pagina. 

Strumenti per integrare le analisi di PageSpeed Insights

Per testare l’URL sotto diverse condizioni di test e accedere a ulteriori metriche puoi integrare PageSpeed Insights con altri strumenti di misurazione delle prestazioni delle pagine web.

GTmetrix combina metriche di Lighthouse e proprie, per offrire punteggi e grafici a cascata che mostrano il caricamento sequenziale delle risorse, e facilitano l’identificazione di elementi che appesantiscono la pagina e l’ottimizzazione front-end.

Pingdom è particolarmente utile per il monitoraggio continuo delle prestazioni del sito e offre report accessibili anche agli utenti non tecnici, con dati raccolti da server di test distribuiti in diverse località.

WebPageTest permette di simulare un gran numero di situazioni reali combinando diversi dispositivi, browser, località e velocità di connessione e si distingue per la quantità e la profondità delle analisi.

Conclusioni

In questa guida a PageSpeed Insights abbiamo visto che si tratta di un ottimo strumento per farci un’idea di come Google vede le prestazioni del nostro sito (o di quello di un competitor).

Qui trovi i famosi Core Web Vitals e tutte le metriche che servono al motore di ricerca per definire quanto le pagine web siano veloci e offrano una buona esperienza utente, anche a chi soffre di disabilità. 

L’approccio di PageSpeed Insights è molto operativo e, accanto ai controlli superati e ai punteggi, comprende una lunga lista di raccomandazioni pratiche per ottimizzare le prestazioni così come la SEO della pagina.

E tu usi già PageSpeed Insights? Lo integri con strumenti simili? Se ti va, parliamone nei commenti.