Un audit di performance deve dirti quali pagine sono lente per gli utenti veri, perché lo sono e quali interventi fare per primi. Il metodo segue un ordine preciso: si parte dai dati reali raccolti da Google, si riproducono i problemi in laboratorio sulle pagine che contano, si trova una causa per ogni metrica fuori soglia e si chiude con un piano di interventi verificabile.
Quali pagine analizzare, e perché non solo la home
Le metriche di Google si valutano pagina per pagina, e il report Core Web Vitals di Search Console raggruppa gli URL con un'esperienza simile, che di solito condividono lo stesso modello e quindi le stesse cause. Per questo l'audit si fa per modelli di pagina, non per indirizzi singoli. Il campione tipico:
- La home page.
- Una pagina per ogni modello principale: categoria, scheda prodotto, pagina servizio, articolo.
- Le landing page delle campagne pubblicitarie.
- Le pagine con più traffico organico, prese da Search Console.
- Carrello, checkout e moduli di contatto, dove si chiude la conversione.
Un audit di performance non sostituisce un audit SEO: il primo guarda quanto le pagine sono veloci e stabili, il secondo come Google le trova e le interpreta. I due lavori però possono andare insieme: per Key SRL, società di mediazione creditizia di Milano, l'ottimizzazione SEO è andata di pari passo con quella complessiva del sito, dalle performance alla pulizia tecnica.
Primo passo: i dati degli utenti reali
Si parte da quello che vivono gli utenti. Search Console e PageSpeed Insights mostrano i dati del Chrome User Experience Report al 75° percentile, separati per mobile e desktop e aggregati su una finestra mobile di quattro settimane, come spiega la pagina informazioni su PageSpeed Insights. È la fotografia di partenza, da salvare con la data. Il significato di ogni metrica è spiegato nella guida ai Core Web Vitals.
Se il sito non ha abbastanza traffico per comparire in CrUX, i dati vanno raccolti in casa. La libreria web-vitals, mantenuta dal team di Chrome, misura LCP, INP e CLS sui visitatori veri nello stesso modo in cui li misura Chrome, e la sua versione con attribuzione aggiunge le informazioni per capire quale elemento o interazione causa il problema. I valori si inviano allo strumento di statistiche che usi già.
Secondo passo: test di laboratorio fatti bene
Il laboratorio serve a riprodurre i problemi e a cercarne la causa. Lighthouse calcola il punteggio di performance come media pesata di cinque metriche: con i pesi pubblicati per Lighthouse 10, il Total Blocking Time conta per il 30%, LCP e CLS per il 25% ciascuno, First Contentful Paint e Speed Index per il 10%, secondo la documentazione sul punteggio di Lighthouse. L'INP non compare, perché in laboratorio non ci sono interazioni reali: il Total Blocking Time ne è l'indicatore indiretto.
La stessa documentazione elenca cosa fa variare il punteggio anche quando il sito non cambia: test A/B, annunci, instradamento della rete, dispositivi diversi, estensioni del browser, antivirus. Per avere test confrontabili:
- Ripeti ogni misura più volte e ragiona sulla distribuzione, non sul singolo punteggio.
- Usa sempre le stesse condizioni di dispositivo simulato, rete e posizione.
- Lavora in una finestra del browser senza estensioni.
- Annota quali annunci, test A/B o banner erano attivi durante la misura.
Per le analisi di dettaglio il pannello Prestazioni di Chrome DevTools registra cosa fa il browser durante caricamento e interazioni, mostra le metriche locali e può affiancarle ai dati reali di CrUX, come illustra la panoramica del pannello Prestazioni.
La diagnosi: una causa per ogni metrica fuori soglia
È qui che un audit si distingue da un elenco di consigli generici. Per ogni metrica fuori soglia si cerca la causa con la scomposizione proposta da web.dev:
- LCP: quanto tempo va in risposta del server, attesa, download e visualizzazione dell'elemento principale (ottimizzare l'LCP).
- INP: quali interazioni sono lente e in quale fase, tra attesa prima della gestione, esecuzione del codice e disegno della risposta (ottimizzare l'INP).
- CLS: quali elementi si spostano, quando e perché (ottimizzare il CLS).
- TTFB: quanto pesano server, cache, CDN e reindirizzamenti (ottimizzare il TTFB).
Il confronto tra laboratorio e campo è già un indizio. La guida al TTFB spiega che gli strumenti di laboratorio misurano di solito l'indirizzo finale, senza i reindirizzamenti che gli utenti reali attraversano: se il TTFB è buono in laboratorio e scadente sul campo, vanno controllati cache, reindirizzamenti e rete. Le soluzioni per ogni causa sono raccolte nella guida su come velocizzare un sito lento.
Terze parti, peso e server: l'inventario da fare
Accanto alle metriche serve un inventario, perché molte cause non si vedono dal punteggio:
- Script di terze parti: cosa fanno, chi li ha voluti, su quali pagine girano, se si caricano in modo sincrono.
- Peso della pagina per tipo di risorsa: immagini, JavaScript, CSS, font, video.
- Intestazioni di cache e compressione delle risorse statiche.
- Reindirizzamenti, soprattutto quelli in catena da campagne e vecchi link.
- Dimensione del DOM, che Lighthouse segnala sopra gli 800 nodi secondo la guida sulle dimensioni del DOM.
- Plugin, app ed estensioni installati, con la data dell'ultimo aggiornamento.
Come si mettono in fila gli interventi
Ogni problema trovato diventa un intervento con quattro informazioni: quale metrica migliora, su quali modelli di pagina, quanto lavoro richiede, che rischi comporta. Si parte da quello che tocca più pagine con meno sforzo. Su un catalogo grande, per esempio, correggere il modello della scheda prodotto sistema tutte le schede in un colpo solo, mentre correggere una landing ne sistema una.
Poi contano le dipendenze. Se il server risponde tardi, quel ritardo precede tutto il resto, quindi risposta del server e cache vengono prima; se un tema carica decine di script, ripulirli può valere più di molti ritocchi. Quando possibile, ogni intervento va misurato da solo, per sapere cosa ha funzionato davvero.
Cosa deve contenere il report finale
Che tu lo faccia internamente o lo chieda a un'agenzia, un report di audit utile contiene:
- La fotografia iniziale dei dati reali per modello di pagina, mobile e desktop, con la data.
- Le condizioni dei test di laboratorio, così chiunque può ripeterli.
- Per ogni problema, la causa documentata: traccia delle prestazioni, cascata delle richieste, elemento responsabile.
- L'elenco degli interventi in ordine di priorità, con metrica interessata e pagine coinvolte.
- Come si verificherà l'effetto: test ripetuti, dati reali, convalida in Search Console.
- Le regole per non tornare indietro: budget di performance e controlli automatici.
Un report che si ferma al punteggio di Lighthouse, o che promette un numero di posizioni guadagnate, dice poco: Google stesso precisa che buoni Core Web Vitals non garantiscono la prima posizione, nella pagina sull'esperienza sulle pagine.
Dopo l'audit: come evitare che il sito torni lento
Le prestazioni peggiorano con l'uso: nuovi script di marketing, immagini caricate senza ottimizzazione, aggiornamenti di plugin e temi. Un budget di performance fissa limiti misurabili, per esempio al peso complessivo della pagina, al tempo di caricamento su rete mobile o al numero di richieste, come spiega la guida ai budget di performance. Lighthouse CI esegue i test a ogni modifica del codice e ferma le regressioni prima che vadano online.
Sul fronte dei dati reali, quando hai corretto un problema segnalato nel report Core Web Vitals puoi avviarne la convalida: Search Console monitora gli URL interessati per quattro settimane e considera il problema risolto solo se non si ripresenta, come spiega la guida al report Core Web Vitals.
Se vuoi un audit che finisca con una lista di interventi ordinata e verificabile, e non con un punteggio, scrivici. Quando i problemi sono strutturali, il passo successivo è un restyling su basi tecniche diverse; per il controllo nel tempo c'è la gestione siti web.
Domande frequenti
Che differenza c'è tra un audit SEO e un audit di performance?
L'audit SEO guarda come Google trova, interpreta e posiziona le pagine: struttura, contenuti, indicizzazione. L'audit di performance guarda quanto le pagine sono veloci e stabili per chi le usa. Si incontrano sui Core Web Vitals, ma rispondono a domande diverse.
Un punteggio Lighthouse basso vuol dire che il sito è lento per gli utenti?
Non per forza. Il laboratorio simula un dispositivo e una rete precisi, mentre gli utenti reali usano telefoni e connessioni diversi. Per sapere cosa vivono i tuoi visitatori guarda i dati reali di Search Console o di PageSpeed Insights.
Cosa serve per fare un audit di performance?
L'accesso a Search Console e alle statistiche del sito, l'elenco degli strumenti di terze parti installati e le informazioni su hosting, CDN e piattaforma. Con questi elementi ogni problema si può collegare alla sua causa.
Ogni quanto conviene ripetere l'audit?
Dopo ogni cambiamento importante, come un nuovo tema, una migrazione o l'arrivo di nuovi strumenti di marketing. Tra un audit e l'altro bastano il monitoraggio dei dati reali e controlli automatici a ogni modifica del codice.
Un audit migliora da solo il posizionamento?
No, l'audit è una diagnosi: servono gli interventi che ne seguono. E anche con buoni Core Web Vitals il posizionamento dipende prima di tutto dalla pertinenza dei contenuti.
