Indice di velocità

TL;DR — Speed Index è un punteggio Lighthouse che indica quanto velocemente appare il contenuto della pagina durante il caricamento. Più basso (più veloce) è meglio, e si misura in secondi. Su mobile, meno di 3,4 s è un buon risultato. Non è un Core Web Vital e non influisce direttamente sul ranking Google, ma le correzioni che lo migliorano di solito aiutano le metriche che invece contano.

Che cos’è Speed Index

Quando esegui una pagina con Lighthouse o PageSpeed Insights, uno dei numeri restituiti è Speed Index. Risponde a una domanda semplice: quanto velocemente si riempie la parte visibile della pagina?

La maggior parte delle metriche di velocità segna un singolo momento, come quando appare il primo frammento di contenuto (First Contentful Paint) o quando appare l’elemento più grande (Largest Contentful Paint). Speed Index è diverso. Osserva l’intero caricamento e calcola una media della velocità con cui gli elementi diventano visibili. Una pagina che visualizza tutto quasi istantaneamente ottiene un punteggio basso (buono); una pagina che resta vuota e poi fa comparire il contenuto a goccia a goccia ottiene un punteggio alto (cattivo).

Come leggere il punteggio

Lighthouse valuta Speed Index su mobile in questo modo:

• Buono: 0 – 3,4 s (verde)
• Da migliorare: 3,4 – 5,8 s (arancione)
• Scarso: più di 5,8 s (rosso)

Desktop è molto più severo: un buon risultato è all’incirca sotto 1,3 s, perché Lighthouse testa il mobile su un dispositivo simulato più lento. Quindi non confrontare un numero desktop con uno mobile: usano scale diverse.

È importante per la SEO?

Questa è la parte che molti sbagliano. Speed Index non è un Core Web Vital e non è un fattore di ranking Google. I segnali di page experience di Google provengono dai Core Web Vitals (LCP, INP e CLS) misurati su utenti reali. Speed Index non fa parte di questi segnali e non viene nemmeno misurato su utenti reali: richiede una registrazione video del caricamento, disponibile solo negli strumenti di test.

Questo non lo rende inutile. Le correzioni che migliorano Speed Index — un server più veloce, meno file che bloccano il rendering e testo che resta visibile mentre si caricano i font — sono le stesse che migliorano FCP e LCP. Quindi un Speed Index migliore spesso va di pari passo con un LCP migliore, che invece conta.

Se vuoi conoscere la formula, la storia di WebPageTest, il suo peso nel punteggio Lighthouse e i limiti a cui prestare attenzione, passa alla scheda Advanced.

TL;DR — Speed Index misura la velocità con cui il contenuto viene visualizzato durante il caricamento — il tempo medio a cui appare il contenuto visibile, espresso in secondi (più basso è meglio). Viene calcolato da un video del caricamento sommando l’area sopra la curva del progresso visivo, il che lo rende una metrica solo da laboratorio (non presente in CrUX, nei dati sul campo di PSI o in Search Console). È nato in WebPageTest (Pat Meenan); Lighthouse lo calcola tramite il modulo open source Speedline. Non è un Core Web Vital e non è un fattore di ranking: è una delle cinque metriche di prestazioni di Lighthouse, con un peso del 10% in Lighthouse 10. Su mobile: Buono ≤ 3,4 s, Da migliorare ≤ 5,8 s, Scarso > 5,8 s; su desktop Buono ≤ ~1,3 s. Non può essere più veloce di FCP, dipende dalla viewport e migliora con le stesse correzioni di FCP/LCP.

Che cosa misura davvero Speed Index

La definizione di Google è una riga: “Speed Index measures how quickly content is visually displayed during page load.” La parola chiave è visivamente. Speed Index non è un singolo timestamp come First Contentful Paint e Largest Contentful Paint: è un punteggio composito che rappresenta il tempo medio in cui vengono visualizzate le parti visibili della pagina. Più basso è meglio e il risultato è espresso in secondi.

Il modello mentale più chiaro, secondo me, è disegnare un grafico con il tempo sull’asse X e la «percentuale di pagina completa visivamente» sull’asse Y, che sale dallo 0% al 100%. Speed Index è l’area sopra quella curva. Più velocemente la curva sale al 100%, più piccola è l’area e migliore è il punteggio. Una pagina vuota per un po’ lascia un grande rettangolo di area vuota sopra la linea; una pagina che visualizza rapidamente non ne lascia quasi nessuno.

Come viene calcolato

Lighthouse registra un video del caricamento della pagina e calcola la progressione visiva tra i fotogrammi. Ogni intervallo di tempo viene ponderato in base a quanto la pagina è ancora incompleta in quel momento: un fotogramma completamente vuoto conta al 100%, mentre un fotogramma quasi interamente visualizzato conta pochissimo. La formula originale di WebPageTest è:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

Un esempio svolto lo rende concreto. DebugBear descrive un caricamento in questo modo:

• 0% completo (0–253 ms) → contributo di 253,0 ms
• 43% completo (253–403 ms) → contributo di 85,5 ms
• 98% completo (403–536 ms) → contributo di 2,7 ms
• 99% completo (536–653 ms) → contributo di 1,2 ms
• Totale: 342,3 ms

Nota il primo intervallo: mentre non è visibile nulla, tutto quel tempo contribuisce con peso massimo. Ecco perché Speed Index non può mai essere più veloce di First Contentful Paint: ogni millisecondo prima che venga visualizzato il primo contenuto viene conteggiato al 100%.

Lighthouse non usa qui un’implementazione proprietaria. Esegue il modulo open source Speedline (originariamente di Paul Irish), che applica la stessa metodologia del progresso visivo da video di WebPageTest, lavorando sulle tracce di Chrome DevTools con gli screenshot attivati. Speedline può calcolare uno Speed Index standard (differenza dell’istogramma tra il fotogramma corrente e quello finale) o una variante percettiva che usa SSIM; di norma si vede quella standard.

Qual è un buon punteggio

Lighthouse 10 valuta Speed Index rispetto a dati di siti reali dell’HTTP Archive, e le soglie differiscono nettamente in base al dispositivo perché Lighthouse simula per impostazione predefinita un dispositivo mobile di fascia media con throttling:

Se hai visto circolare il vecchio benchmark «sotto 1.000 ms è buono», si tratta di una guida storica di WebPageTest per un’epoca e un profilo di connessione specifici, non dell’attuale soglia mobile di Lighthouse. Devi sempre sapere quali strumento e dispositivo/impostazioni di rete hanno prodotto il numero che stai guardando, perché la stessa pagina ottiene punteggi diversi in Lighthouse, WebPageTest e GTmetrix.

Dove si colloca nel punteggio Lighthouse

Speed Index è una delle cinque metriche del punteggio Performance di Lighthouse 10 e ha un peso del 10%, a pari merito con FCP per il peso più basso:

La conclusione pratica è questa: inseguire Speed Index in isolamento ha un ROI basso. Total Blocking Time (30%), LCP e CLS (25% ciascuno) spostano molto di più il punteggio complessivo. A meno che il problema specifico non sia Speed Index, di solito ottieni di più correggendo LCP e TBT; e Speed Index migliora comunque come effetto collaterale. In PageSpeed Insights trovi Speed Index nella sezione lab (Lighthouse), non nella sezione dei dati sul campo in alto.

Speed Index è un Core Web Vital o un fattore di ranking?

No in entrambi i casi, e la distinzione conta quando spieghi un report a uno stakeholder.

• Non è un Core Web Vital. I Core Web Vitals sono LCP, INP e CLS, misurati su utenti reali tramite CrUX. Speed Index non fa parte di quel gruppo e non compare nel report Core Web Vitals di Search Console.
• Non è un fattore di ranking diretto. Il segnale di page experience di Google usa dati field dei Core Web Vitals. Speed Index è una diagnostica solo da laboratorio che Google non raccoglie da utenti reali, quindi non esiste un percorso diretto dal tuo numero di Speed Index al ranking.

Il rapporto con il ranking è indiretto: i problemi che producono uno Speed Index scarso — TTFB lento, CSS/JS che bloccano il rendering, testo invisibile durante il cambio di font — sono gli stessi che producono un FCP e un LCP scarsi. Correggili e un Speed Index migliore seguirà di solito un LCP migliore, che è la parte effettivamente premiata da Google.

Perché è solo da laboratorio

Speed Index richiede un video fotogramma per fotogramma del rendering della pagina, poi un’elaborazione delle immagini per calcolare la completezza visiva di ciascun fotogramma. È troppo costoso da eseguire su ogni visitatore reale, quindi esiste solo negli strumenti sintetici/di laboratorio: Lighthouse, WebPageTest e GTmetrix. Il Real User Monitoring e il dataset CrUX semplicemente non lo contengono. Se ti servono dati sulle prestazioni field, usa i Core Web Vitals; Speed Index serve a diagnosticare il rendering in un test controllato.

Da dove proviene

Speed Index è nato in WebPageTest, creato e reso open source da Pat Meenan nel 2008 (la metrica è stata aggiunta intorno al 2012). È stato progettato per colmare una lacuna reale nelle metriche dell’epoca:

• L’avvio del rendering poteva essere attivato da un singolo pixel o da un colore di sfondo, non da contenuto significativo.
• Il completamento del documento (onload) include risorse sotto la piega e irrilevanti.

Speed Index ha colmato la differenza misurando la completezza visiva above-the-fold nel tempo: un indicatore migliore di ciò che percepisce davvero un utente. In seguito Lighthouse ha adottato questa metodologia tramite il modulo Speedline, motivo per cui i numeri di WebPageTest e Lighthouse condividono una discendenza, anche se il loro throttling è diverso.

Come migliorarlo

Non esiste un trucco specifico per Speed Index: la guida stessa di Google dice che qualsiasi cosa tu faccia per migliorare la velocità di caricamento della pagina migliorerà il tuo punteggio Speed Index. In pratica:

• Riduci il tempo di risposta del server (TTFB). Ogni millisecondo prima del primo byte è tempo di pagina vuota conteggiato con peso massimo.
• Elimina CSS e JavaScript che bloccano il rendering. Ritardano il primo paint, che è la parte più costosa della curva. Inserisci il CSS critico in linea e rimanda il resto.
• Correggi il caricamento dei font. Durante un cambio di font, il testo può essere invisibile e contare come 0% completo per quell’intervallo. font-display: swap (o optional) mantiene il testo visibile. È uno degli audit che Lighthouse segnala esplicitamente per Speed Index.
• Riduci il lavoro del main thread e il tempo di esecuzione JavaScript, le altre due diagnostiche che Lighthouse indica come ad alto impatto su Speed Index.
• Dai priorità al contenuto above-the-fold. Speed Index considera solo la viewport visibile, quindi l’obiettivo è dipingere rapidamente la prima schermata.

Questi interventi coincidono quasi completamente con l’ottimizzazione di FCP e LCP, ed è proprio per questo che considero Speed Index un segnale di conferma, non una lista di attività separata. Prima di agire su un singolo numero, guarda il filmstrip del caricamento (lo generano sia Lighthouse sia WebPageTest) per confermare cosa viene visualizzato presto e cosa tardi, e confronta alcune esecuzioni ripetute con condizioni uguali invece di un solo test: vedi la nota sulla variabilità tra esecuzioni più avanti.

Limiti da conoscere

• Solo da laboratorio — non riflette mai l’esperienza di un utente reale, ma solo quella dell’ambiente di test.
• Dipendente dalla viewport — misura l’area visibile, quindi mobile e desktop producono risultati molto diversi (da qui le soglie molto diverse).
• Punto cieco per SPA/AJAX — le applicazioni a pagina singola possono sembrare artificialmente veloci: lo shell viene visualizzato rapidamente mentre il contenuto reale si carica dopo, senza un refresh della pagina.
• Carousel, video con autoplay e overlay per il consenso — qualsiasi elemento che continui a cambiare pixel dopo il caricamento del contenuto significativo può essere penalizzato perché continua a risultare «incompleto», con lo stesso meccanismo che penalizza i carousel a rotazione automatica.
• Non è una metrica «completamente caricato» — misura la progressione visiva above-the-fold, non il momento in cui finiscono ogni script, immagine o elemento sotto la piega. La metrica separata Visually Complete di WebPageTest (sempre ≥ Speed Index) è quella che rileva un widget lazy-loaded tardivo.
• Il progresso visivo non dimostra l’utilità. Speed Index misura solo il cambiamento dei pixel rispetto a un fotogramma finale: non sa se ciò che è sullo schermo è leggibile, ordinato correttamente, accessibile o davvero interattivo. Uno skeleton o shell che appare rapidamente può ottenere un buon punteggio mentre il contenuto reale (e la possibilità di usarlo) arriva dopo; è lo stesso problema dell’anti-pattern «paint iniziale privo di significato», visto dal lato della metrica.
• Variabilità tra esecuzioni. Poiché deriva da un singolo caricamento registrato, Speed Index cambia con le condizioni di test: la guida al punteggio di Google indica differenze del dispositivo, estensioni del browser, antivirus e perfino modifiche di annunci o test A/B come cause di variazione del punteggio che non hanno nulla a che fare con il codice. Confronta distribuzioni ottenute da esecuzioni ripetute e uguali, non numeri isolati.

Metriche correlate

Speed Index vive nello stesso cluster di web performance dell’hub dei Core Web Vitals e dei suoi elementi vicini. È più vicino a First Contentful Paint (Speed Index non può battere FCP) e Largest Contentful Paint (stesse correzioni, stesse cause principali), si colloca accanto a Total Blocking Time nel punteggio Lighthouse e lo incontrerai in Lighthouse e PageSpeed Insights. Per le metriche sul campo che guidano davvero il ranking, inizia dall’hub dei Core Web Vitals.

Riepilogo AI

Una sintesi della versione Avanzata:

• Speed Index = velocità con cui il contenuto viene visualizzato durante il caricamento — un punteggio composito (tempo medio in cui appare il contenuto visibile), non un singolo timestamp. È espresso in secondi; più basso è meglio.
• Modello mentale: l’area sopra la curva del progresso visivo (tempo rispetto alla percentuale completata visivamente). È calcolato da un video del caricamento, ponderando ogni intervallo in base a quanto la pagina è ancora incompleta.
• Solo da laboratorio: richiede screenshot fotogramma per fotogramma, quindi non è presente nei dati sul campo di CrUX e PageSpeed Insights o in Search Console. Per i dati sul campo usa i Core Web Vitals.
• Origine: WebPageTest (Pat Meenan, 2008; metrica intorno al 2012). Lighthouse lo calcola tramite il modulo open source Speedline, con la stessa metodologia di WebPageTest.
• Non è un Core Web Vital e non è un fattore di ranking. I CWV sono LCP, INP e CLS. Il collegamento al ranking è indiretto: correggere Speed Index migliora di solito FCP/LCP.
• Peso in Lighthouse 10: 10% — a pari merito con FCP per il peso più basso. TBT (30%) e LCP/CLS (25% ciascuno) contano molto di più, quindi inseguire solo Speed Index ha un ROI basso.
• Soglie (mobile): Buono ≤ 3,4 s, Da migliorare ≤ 5,8 s, Scarso > 5,8 s; su desktop Buono ≤ ~1,3 s. Non può essere più veloce di FCP e dipende dalla viewport.
• Correzioni = correzioni di FCP/LCP: TTFB più veloce, meno risorse che bloccano il rendering, font-display: swap, meno lavoro del main thread/JavaScript e priorità al rendering above-the-fold.
• Limiti: le SPA possono ottenere un punteggio artificialmente buono; carousel, video con autoplay e overlay per il consenso possono essere penalizzati; non è una misura «completamente caricato»; il progresso visivo non dimostra che il contenuto sia leggibile, accessibile o utilizzabile; una singola esecuzione può cambiare per dispositivo, estensioni o modifiche di annunci/test A/B che non hanno nulla a che fare con il codice.

Documentazione ufficiale

Documentazione delle fonti primarie per Speed Index.

Google / Lighthouse

• Speed Index (audit Lighthouse) — il riferimento canonico: definizione, come Lighthouse lo calcola tramite Speedline, soglie di valutazione e audit di ottimizzazione.
• Valutazione delle prestazioni Lighthouse — dove si trovano il peso del 10% di Speed Index e la suddivisione completa delle metriche.
• Ridurre il lavoro del main thread — uno dei tre audit che Lighthouse indica come ad alto impatto per Speed Index.
• Ridurre il tempo di esecuzione JavaScript — il secondo audit segnalato.
• Assicurarsi che il testo resti visibile durante il caricamento del webfont (font-display) — il terzo audit segnalato.

Origine / implementazione

• Speedline (paulirish/speedline) — il modulo open source che Lighthouse usa per calcolare Speed Index dalle tracce DevTools.
• Sorgente Lighthouse — speed-index.js — la costante della descrizione dell’audit.
• WebPageTest — Informazioni — Pat Meenan ha creato e reso open source WebPageTest, da cui Speed Index ha avuto origine.

Citazioni dalla fonte

Dichiarazioni ufficiali. Ogni link Google/Lighthouse è un deep link che porta al passaggio citato.

Google — che cosa misura Speed Index

• “Speed Index measures how quickly content is visually displayed during page load.” — audit Speed Index di Lighthouse. Vai alla citazione

Google — come viene stabilito il punteggio

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” — audit Speed Index di Lighthouse. Vai alla citazione

Fonti riportate (parafrasate dalla documentazione secondaria, non citate parola per parola)

• Lighthouse registra un video del caricamento della pagina, calcola la progressione visiva tra i fotogrammi e genera il punteggio con il modulo Speedline, sulla base degli stessi principi dello Speed Index originale di WebPageTest. (Audit Speed Index di Lighthouse, sezione sul calcolo.)
• Più a lungo un fotogramma resta visibile e meno completa è la pagina in quel momento, più quel fotogramma contribuisce al punteggio; poiché tutto il tempo precedente a FCP conta al 100%, Speed Index non può essere più veloce di First Contentful Paint. (Documentazione Speed Index di DebugBear.)
• Speed Index è disponibile solo nei test sintetici/di laboratorio perché l’elaborazione di screenshot fotogramma per fotogramma è costosa. (Documentazione Speed Index di DebugBear.)
• La metrica è stata aggiunta a WebPageTest intorno al 2012, sulla base dello strumento che Pat Meenan aveva reso open source nel 2008. (KeyCDN; pagina Informazioni di WebPageTest.)

Scheda rapida Speed Index

Soglie (Lighthouse 10)

Pesi Performance di Lighthouse 10

Fatti rapidi

• Misura la completezza visiva nel tempo (l’area sopra la curva del progresso), non un singolo timestamp. Più basso è meglio.
• Solo da laboratorio — non è presente nei dati sul campo di CrUX e PSI o in Search Console.
• Non è un Core Web Vital e non è un fattore di ranking diretto.
• Non può mai essere più veloce di FCP (il tempo precedente a FCP conta al 100%).
• Dipende dalla viewport — i punteggi mobile e desktop differiscono molto.
• È calcolato da Speedline e ha avuto origine in WebPageTest (Pat Meenan).

Miglioralo (come FCP/LCP)

• Riduci il TTFB (risposta del server più veloce).
• Rimuovi CSS/JS che bloccano il rendering; inserisci il CSS critico in linea.
• font-display: swap / optional per mantenere visibile il testo.
• Riduci il lavoro del main thread e il tempo di esecuzione JS.
• Dai priorità al rendering above-the-fold.

Non lasciarti ingannare

• «Under 1,000 ms» è una vecchia indicazione di WebPageTest, non la soglia mobile di Lighthouse.
• Le SPA possono ottenere un punteggio artificialmente buono; i carousel possono essere penalizzati.

Strumenti che riportano Speed Index

• Lighthouse (in Chrome DevTools, nella CLI o nel modulo Node) — riporta Speed Index come una delle cinque metriche Performance, calcolata tramite Speedline.
• PageSpeed Insights — esegue Lighthouse e mostra Speed Index nella sezione lab (Diagnostics). Nota: la sezione dei dati sul campo in alto usa i Core Web Vitals, quindi Speed Index non compare mai lì.
• WebPageTest — il luogo da cui la metrica ha avuto origine; riporta Speed Index insieme a Visually Complete e alle visualizzazioni filmstrip, con profili di connessione configurabili.
• GTmetrix — mostra Speed Index nella sua interfaccia usando dati WebPageTest; i suoi numeri non corrispondono a quelli di Lighthouse perché simulano dispositivo e rete in modo diverso.
• DebugBear — monitoraggio sintetico con una chiara scomposizione fotogramma per fotogramma di come è stato calcolato il punteggio Speed Index.

Un promemoria quando confronti gli strumenti: la stessa pagina produce valori Speed Index diversi in Lighthouse, WebPageTest e GTmetrix a causa delle diverse ipotesi su throttling e dispositivo. Confronta condizioni uguali.

Errori Speed Index che fanno sprecare tempo di ottimizzazione

• Chiamare Speed Index un Core Web Vital. È una metrica del progresso visivo solo da laboratorio, non un segnale di ranking da dati sul campo. Usala per diagnosticare come si riempie una pagina, poi controlla separatamente i Core Web Vitals reali.
• Confrontare le soglie mobile e desktop. Lighthouse usa curve di valutazione e condizioni di test diverse. Segui un solo profilo nel tempo invece di trattare i due punteggi come intercambiabili.
• Migliorare il numero con un paint iniziale privo di significato. Uno shell dell’header può far iniziare prima il progresso visivo mentre il contenuto principale resta vuoto. Esamina il filmstrip del caricamento insieme alla metrica.
• Ottimizzare ogni immagine prima di controllare il percorso critico. TTFB lento, CSS che blocca il rendering, font e JavaScript sincrono possono ritardare l’intera sequenza visiva. Trova il primo collo di bottiglia nella waterfall e seguilo.
• Aspettarsi un valore stabile da una singola esecuzione. Speed Index deriva da un video sintetico e cambia con l’ambiente di test. Ripeti esecuzioni confrontabili prima di dichiarare una regressione o un miglioramento.

Mettiti alla prova: Speed Index

Cinque domande rapide su ciò che misura Speed Index. Scegli una risposta per ciascuna, poi controlla.

Risorse che vale la pena consultare

Ufficiali

• Speed Index — audit Lighthouse — definizione canonica, soglie e audit di ottimizzazione.
• Valutazione delle prestazioni Lighthouse — i pesi delle metriche, incluso il 10% di Speed Index.
• WebPageTest — Informazioni — l’origine della metrica.

Implementazione

• paulirish/speedline — il modulo open source che Lighthouse usa per calcolare Speed Index.

Da altre fonti

• DebugBear — Speed Index — l’esempio svolto più chiaro, passo per passo, del calcolo e del rapporto con FCP.
• KeyCDN — Speed Index — contesto storico e formula di WebPageTest.
• Catchpoint — Speed Index — erede del blog WebPageTest; formula del progresso visivo e limiti di SPA/carousel.
• Google Search Central — Core Web Vitals — conferma che LCP, INP e CLS sono i segnali di ranking; Speed Index non è elencato, a ulteriore conferma che non ha un impatto diretto sul ranking.
• web.dev — Panoramica dei Vitals — definizione autorevole dei Core Web Vitals (LCP, INP, CLS); Speed Index è assente, utile per spiegare perché non influisce sul ranking.
• WebPageTest — Documentazione Speed Index — informazioni sulla creazione di WebPageTest da parte di Pat Meenan (reso open source nel 2008) e sull’origine della metrica Speed Index.

Numeri da citare

• Peso Lighthouse: 10% del punteggio Performance in Lighthouse 10, a pari merito con FCP per il peso più basso e molto dietro a TBT (30%) e LCP/CLS (25% ciascuno). Fonte
• «Buono» su mobile ≤ 3,4 s; «Buono» su desktop ≤ 1,3 s — soglie di Lighthouse 10, calibrate sui dati di siti reali dell’HTTP Archive. Fonte
• Speed Index ≥ FCP, sempre — tutto il tempo precedente alla visualizzazione del primo contenuto contribuisce al 100%, quindi Speed Index non può risultare più veloce di First Contentful Paint. Fonte
• Origine: WebPageTest, ~2012 — aggiunto sopra allo strumento che Pat Meenan aveva reso open source nel 2008. Fonte

Cronologia modifiche