Punteggi PageSpeed e Core Web Vitals: cosa guardare oggi

C'era un tempo in cui un punteggio PageSpeed di 89 era un trofeo: si scriveva, si mostrava, si difendeva. Era il numero verde di un tool che prometteva di riassumere in una cifra la velocità di un sito. Quel numero esiste ancora, ed è ancora utile, ma saperlo leggere è diventato più importante che inseguirlo. Questa rilettura spiega cosa misura davvero un punteggio, cosa misurano invece i Core Web Vitals, e dove conviene investire il tempo quando l'obiettivo è la esperienza delle persone reali.

Punteggio di laboratorio contro dati sul campo

Il punteggio di Lighthouse è una simulazione: un device di riferimento, condizioni di rete stabilite, un'analisi in controllate condizioni di laboratorio. È eccellente per confrontare versioni dello stesso sito durante lo sviluppo, meno affidabile per descrivere il mondo. I dati sul campo (quelli raccolti dal progetto CrUX sui reali visitatori, in finestre di settimane) raccontano invece ciò che accade davvero: reti lente, telefoni modesti, estensioni installate. Quando i due mondi dicono cose diverse, il campo vince sempre.

I Core Web Vitals che contano

• LCP, Largest Contentful Paint: quanto impiega il contenuto principale a comparire. Soglia buona: 2,5 secondi. Dipende da server, CDN, priorità delle immagini critiche.
• INP, Interaction to Next Paint: la reattività agli input, il tempo perché il sito risponda ai tocchi. Soglia buona: 200 millisecondi. Dipende dal JavaScript: task lunghi che bloccano il thread principale.
• CLS, Cumulative Layout Shift: la stabilità visiva, quante cose «saltano» mentre la pagina carica. Soglia buona: 0,1. Si risolve dichiarando dimensioni di immagini e spazi per i contenuti dinamici.

Nessuno di questi è un punteggio: sono esperienze. E l'esperienza, non il colore di un indicatore, è ciò che i motori valutano.

Perché il punteggio non è un fattore di ranking

La velocità influisce sul posizionamento attraverso i segnali concreti, i Core Web Vitals, la disponibilità della pagina, non attraverso il voto sintetico. Un sito può mostrare un 65 ostinato e convertire magnificamente, e un 98 accademico che fallisce sul campo. La «vanità del verde», l'ossessione per la palette del tool, porta a ottimizzazioni irrazionali: sprite inutili, ritardi introdotti per spostare metriche, risorse caricate artificialmente. Il punteggio serve a trovare i problemi, non a essere il problema.

La varianza esiste, ed è normale

Un dettaglio che sorprende chi inizia: lo stesso sito, misurato due volte di fila negli stessi strumenti, può oscillare di diversi punti senza che nulla sia cambiato. La causa è la natura simulata del test, dispositivo, rete e cache cambiano tra le esecuzioni. La prassi professionale è fare più misurazioni e considerare la mediana, non il picco. E prima di ottimizzare, stabilire un budget: quali pagine devono essere veloci, per quali visitatori, con quale dispositivo di riferimento. Senza budget, ogni punto di performance diventa un fine; con un budget, diventa una scelta consapevole.

Le ottimizzazioni che spostano davvero

• Immagini: formati moderni, dimensioni giuste per lo schermo, caricamento differito per ciò che sta fuori schermo, e l'immagine principale caricata con priorità.
• Font: sottoinsiemi ridotti, font-display: swap, al massimo due famiglie. Ogni peso in più è un tributo che il lettore paga.
• JavaScript: meno framework per pagine semplici, divisione in moduli, caricamento differito di tutto ciò che non serve al primo sguardo. L'INP migliora togliendo, non aggiungendo.
• TTFB: il tempo al primo byte dipende da hosting e rete di distribuzione: tema approfondito nella guida alle prestazioni all'edge.

Molte di queste scelte si fanno una volta sola e valgono per l'intero sito: dimensioni delle immagini, pesi dei caratteri, spazi riservati ai contenuti che arrivano dopo. Annotarle in un carnet des choix visuels, come lo chiamerebbe un grafico, evita che ogni nuova pagina reinventi le proprie e riporti indietro il CLS conquistato.

Come leggere un report senza farsi ingannare

Prima mossa: guardare sempre prima la versione mobile, con la rete campionata, non il desktop in ufficio. Seconda: confrontare le opportunità proposte con i dati sul campo; se il campo non segnala il problema, il problema è teorico. Terza: diffidare delle ricette universali, ogni sito ha il proprio collo di bottiglia, e misurarlo costa meno che indovinarlo. La disciplina della misura vale anche al di fuori del browser: la stessa onestà metodologica che consigliavamo nei benchmark dei dischi.