PageSpeed Insights spiegato: cosa significa ogni punteggio e come migliorarlo
PageSpeed Insights spiegato
PageSpeed Insights spiegato: punteggi, metriche e correzioni | We.Inc
Cosa significa ogni numero di PageSpeed Insights, dati sul campo e dati di laboratorio, soglie di LCP, INP, CLS, FCP e TTFB, pesi del punteggio e codice che corregge i risultati rossi.
PageSpeed Insights mostra due report. Quello in alto contiene i dati sul campo di visitatori reali di Chrome negli ultimi 28 giorni, valutati al 75° percentile. Quello in basso è un test di laboratorio Lighthouse con un punteggio da 0 a 100: 90 o più è buono, da 50 a 89 va migliorato, sotto 50 è scarso. Correggi prima le metriche sul campo.
Soglie delle metriche sul campo usate da PageSpeed Insights
Metrica
Buono
Da migliorare
Scarso
LCP (Largest Contentful Paint)
2.5 s o meno
da 2.5 a 4 s
oltre 4 s
INP (Interaction to Next Paint)
200 ms o meno
da 200 a 500 ms
oltre 500 ms
CLS (Cumulative Layout Shift)
0.1 o meno
da 0.1 a 0.25
oltre 0.25
FCP (First Contentful Paint)
1.8 s o meno
da 1.8 a 3 s
oltre 3 s
TTFB (sperimentale)
0.8 s o meno
da 0.8 a 1.8 s
oltre 1.8 s
Quasi tutti fissano il grande punteggio circolare, ma quel numero deriva da una sola visita simulata su un telefono con connessione rallentata. Questa guida separa le due metà del report, ti permette di valutare i tuoi numeri rispetto alle soglie ufficiali e collega ogni metrica rossa alla modifica che di solito la migliora.
Analizza il tuo URL su pagespeed.web.dev e guarda prima il blocco dei dati sul campo. Se dice che i dati non sono sufficienti, è disponibile solo il test di laboratorio.
Inserisci i tuoi valori di LCP, INP, CLS, FCP e TTFB nel valutatore qui sotto per vedere in quale fascia rientra ciascuno.
Apri la sezione delle correzioni per la metrica peggiore e applica la modifica al codice corrispondente.
Aspetta i nuovi dati sul campo. Il report sugli utenti reali copre 28 giorni mobili, quindi i miglioramenti compaiono gradualmente e non la mattina dopo.
Il test di laboratorio mobile gira su un telefono di fascia media emulato con una rete lenta, quindi è normale che il punteggio mobile sia più basso di quello desktop.
I punteggi di laboratorio variano di qualche punto tra un'esecuzione e l'altra. Esegui il test tre volte e guarda il risultato intermedio prima di concludere che qualcosa sia cambiato.
Il test di laboratorio non può misurare l'INP perché nessuno clicca nulla. Il Total Blocking Time ne fa le veci, quindi un TBT alto di solito anticipa un INP scarso.
I tag di terze parti come widget di chat, heatmap e script pubblicitari spesso pesano più del tuo codice. Controlla l'elenco delle richieste di terze parti prima di riscrivere la tua app.
Domande frequenti
Perché i dati sul campo e il punteggio di laboratorio sono così diversi?
Misurano cose diverse. I dati sul campo sono ciò che hanno vissuto utenti reali di Chrome sui propri dispositivi e reti in 28 giorni. Il punteggio di laboratorio è un singolo caricamento simulato con limitazioni fisse. Una pagina può ottenere 60 in laboratorio e superare comunque i Core Web Vitals sul campo, o il contrario.
Il punteggio Lighthouse influisce sul posizionamento su Google?
Google descrive i Core Web Vitals come misure dell'esperienza utente reale in linea con ciò che premiano i suoi sistemi di ranking principali. Le sue linee guida per la Ricerca non indicano il punteggio di laboratorio da 0 a 100 come fattore di ranking, quindi usa quel punteggio come strumento diagnostico per trovare i problemi.
Che cos'è il TTFB e qual è un buon valore?
Il Time to First Byte è il tempo che il browser attende prima che arrivi il primo byte dell'HTML, inclusi redirect, DNS, apertura della connessione e lavoro del server. PageSpeed Insights considera buono un valore di 800 ms o meno. Mettere in cache l'HTML sull'edge di una CDN è la correzione più comune.
Come viene calcolato il punteggio di prestazioni di Lighthouse?
Da Lighthouse 10 in poi è una combinazione ponderata di cinque metriche di laboratorio: Total Blocking Time 30 percento, LCP 25 percento, CLS 25 percento, FCP 10 percento e Speed Index 10 percento. Ogni metrica viene prima trasformata in un sotto punteggio da 0 a 100 lungo una curva.
Perché dice che non ci sono dati sul campo per il mio sito?
Il Chrome User Experience Report pubblica dati solo per pagine e origini con abbastanza visite idonee. I siti nuovi o con poco traffico spesso non ne hanno, quindi affidati al test di laboratorio e al tuo monitoraggio finché il traffico non cresce.
Leggi il report dall'alto verso il basso
Il primo blocco risponde alla domanda se i visitatori reali hanno avuto una buona esperienza. Mostra il valore al 75° percentile per ogni metrica, cioè tre visite su quattro sono state almeno così veloci. L'obiettivo è superare tutti e tre i Core Web Vitals (LCP, INP e CLS).
Il secondo blocco è una singola esecuzione di Lighthouse. Nella diagnostica e nelle opportunità scopri perché una metrica sul campo è lenta, perché la traccia di laboratorio elenca i file, le immagini e gli script coinvolti.
Un esempio prima e dopo
Prendi una tipica homepage di una piccola attività con una foto hero a tutta larghezza caricata in modo lazy, un web font senza strategia di fallback e tre tag di marketing nella head. In questo esempio l'immagine LCP inizia a scaricarsi solo dopo che lo script ha finito, quindi l'LCP finisce nella fascia scarsa.
Togliere loading=lazy dalla hero, aggiungere fetchpriority=high, servire la foto in AVIF o WebP alla dimensione visualizzata e spostare i tag in modo che si carichino dopo che la pagina è interattiva interviene su ogni sotto parte dell'LCP. Sono le modifiche mostrate nel codice qui sotto; i tuoi numeri dipenderanno dalla tua pagina.
Dove ogni metrica di solito va storta
L'LCP si divide in quattro parti: time to first byte, ritardo di caricamento della risorsa, durata di caricamento della risorsa e ritardo di rendering dell'elemento. Trova prima la parte più grande, poi correggi quella.
L'INP riguarda i task JavaScript lunghi in esecuzione quando qualcuno tocca o digita. Il CLS deriva da elementi che cambiano dimensione dopo il primo rendering: immagini senza dimensioni, banner che arrivano tardi e font che passano a una larghezza diversa.
Come viene ponderato il punteggio di laboratorio
Da Lighthouse 10 in poi si combinano cinque metriche di laboratorio. Il Total Blocking Time ha il peso maggiore, quindi un JavaScript pesante danneggia il punteggio più di ogni altra cosa.
Pesi del punteggio di prestazioni di Lighthouse
Metrica di laboratorio
Peso
Metrica sul campo collegata
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Nessuna in modo diretto
Audit comuni e la correzione per ciascuno
Cosa ti sta dicendo un audit rosso
Audit o sintomo
Perché è rosso
Correzione abituale
L'immagine Largest Contentful Paint è stata caricata in modo lazy
Il browser aspetta il layout prima di scaricare la hero
Togli loading=lazy dalla hero e aggiungi fetchpriority=high
Elimina le risorse che bloccano il rendering
CSS o script sincroni nella head ritardano il primo rendering
Metti inline il CSS critico, rimanda gli script
Dimensiona correttamente le immagini
Le immagini sono più grandi della dimensione visualizzata
Usa srcset e sizes, esporta alla larghezza visualizzata
Pubblica le immagini in formati moderni
JPEG o PNG dove AVIF o WebP sarebbero più leggeri
Converti e servi con picture o una CDN per immagini
Riduci il JavaScript inutilizzato
Codice inviato per funzioni che non sono in questa pagina
Dividi i bundle per route, elimina le librerie inutilizzate
Riduci l'impatto del codice di terze parti
I tag bloccano il thread principale
Carica i tag dopo l'interazione o quando il browser è inattivo
Gli elementi immagine non hanno width e height espliciti
Lo spazio non è riservato, quindi il contenuto salta
Imposta width e height oppure aspect-ratio
Assicurati che il testo resti visibile durante il caricamento dei webfont
Il testo è nascosto mentre il font si scarica
Usa font-display: swap e precarica il font principale
Il tempo di risposta iniziale del server era lungo
TTFB lento per HTML non in cache
Metti in cache l'HTML sull'edge, riduci i redirect
Snippet di correzione
Immagine hero che si carica per prima
Niente caricamento lazy sul probabile elemento LCP, priorità di fetch alta, formati moderni e dimensioni reali così nulla si sposta.
Font che non nasconde il testo
Precarica l'unico file di font usato above the fold e lascia che il testo appaia in un font di fallback finché non arriva.
Tag di terze parti caricato dopo che la pagina si è stabilizzata
Inserisce uno script di marketing quando il browser è inattivo, così non compete con il primo rendering o il primo tocco.
Riserva spazio per il contenuto in ritardo
Un embed o uno spazio pubblicitario con proporzioni fisse impedisce al contenuto sottostante di saltare quando si carica.
Checklist della velocità
Procedi in quest'ordine
Passo
Controllo
Dati sul campo: quale tra LCP, INP e CLS non supera la soglia al 75° percentile?
Elemento LCP: è un'immagine, ed è caricata in modo lazy o scoperta tardi?
TTFB: l'HTML è in cache, e ci sono redirect prima?
JavaScript: qual è il Total Blocking Time e quali script lo causano?
Layout: immagini, embed e banner hanno uno spazio riservato?
Font: font-display è impostato e il file principale è precaricato?
Buono
Da migliorare
Scarso
Valuta i tuoi numeri
Inserisci i valori del tuo report per vedere se ciascuno è buono, da migliorare o scarso.