Report di esempio: un sito web reale, reso anonimo
Questo report di esempio mostra come si presenta un’analisi del sito web. Abbiamo misurato due siti web reali e rimosso ogni dettaglio identificativo. Per ciascuno vede la velocità su smartphone, le basi per la ricerca e per l’IA e i canali di contatto, seguiti da ciò che faremmo. Entrambi gli esempi sono indicati come Sito web A e Sito web B.
Come leggere questi esempi
Entrambi sono siti web reali. Abbiamo rimosso dominio, marchio, loghi e qualsiasi elemento che possa identificarli. I valori sono stati misurati il 5 ottobre 2026 con Lighthouse in ambiente di laboratorio: «mobile» significa uno smartphone emulato con una connessione 4G lenta simulata.
Entrambi i siti sono in buone condizioni. Una buona analisi dice anche che cosa lasciare com’è. I valori di laboratorio non sono dati sul campo di visitatori reali.
Veloce, chiaro e a un passo da un modulo di contatto
su mobile
descrizione
IA
contatto
- Il contenuto principale appare dopo 1,23 s su smartphone
- I crawler di ricerca e IA sono consentiti
- Da correggere per primo: nessun modulo di richiesta nella home page
Che cosa faremmo per il Sito web A
Lasciare invariata la velocità.
Un punteggio mobile di 100 e 1,23 s per il contenuto più grande sono un buon risultato. Qui le modifiche rischierebbero più di quanto farebbero guadagnare.
Aggiungere alla home page un breve modulo di richiesta.
I visitatori possono usare solo i link. Un breve modulo toglie un passaggio a chi arriva da un codice QR allo stand.
Rendere più rigorosa la content security policy.
Oggi consente unsafe inline ed eval. Prima proveremmo una policy più rigorosa e poi la applicheremmo.
Misurare prima di mettere in cache l’HTML.
La risposta del server di 190 ms potrebbe ridursi con una cache delle pagine, ma con un punteggio di 100 il vantaggio è minimo. Prima misureremmo.
Valori misurati
| Controllo | Che cosa abbiamo misurato |
|---|---|
| Velocità, mobile | Punteggio di prestazioni 100, contenuto più grande mostrato dopo 1,23 s, spostamento del layout 0,000, tempo di blocco 0 ms, primo contenuto dopo 1,04 s |
| Velocità, desktop | Punteggio di prestazioni 100, contenuto più grande mostrato dopo 0,37 s |
| Risposta del server | 190 ms; la pagina viene inviata con cache no-store, quindi ogni visita raggiunge il server |
| Peso della pagina | Circa 14 KB di HTML compresso, 3 immagini (tutte SVG, tutte con descrizione e dimensioni impostate) |
| Titolo e descrizione | Titolo di 57 caratteri, descrizione di 158 caratteri, entrambi entro i limiti di visualizzazione abituali |
| Titoli | Un H1, 14 H2, 23 H3 |
| Dati strutturati | Organization, WebSite, WebPage e FAQPage con 6 domande |
| Robots e accesso IA | I crawler di ricerca e IA sono consentiti, sitemap indicata, llms.txt presente, un URL mancante restituisce un vero 404; i crawler IA che abbiamo provato ottengono la pagina (HTTP 200) |
| Canali di contatto | Pagina di contatto, link a e-mail, telefono e WhatsApp; nessun modulo nella home page |
| Intestazioni di sicurezza | HSTS, nosniff, referrer policy e frame options impostati; la content security policy consente unsafe inline ed eval |
| Script di terze parti | Nessuno nell’HTML della pagina |
Veloce e facile da raggiungere, con snippet di ricerca lunghi
su mobile
descrizione
IA
contatto
- Il contenuto principale appare dopo 1,73 s su smartphone
- I crawler di ricerca e IA sono consentiti
- Da correggere per primo: titolo e descrizione superano i limiti abituali
Che cosa faremmo per il Sito web B
Accorciare il titolo a 60 caratteri e la descrizione a 160.
Entrambi superano i limiti abituali, quindi i risultati di ricerca potrebbero troncarli.
Guardare al primo rendering, non alle immagini.
Il contenuto più grande (1,73 s) e il primo contenuto (1,72 s) arrivano quasi insieme, quindi l’attesa precede il primo rendering. I 41 KB di CSS inline sono la prima cosa che esamineremmo.
Passare la content security policy da sola segnalazione ad applicazione effettiva
dopo aver letto i relativi report.
Caricare il beacon di analytics solo dopo il consenso
se la regione del visitatore lo richiede. Lo verificheremmo rispetto alla configurazione del consenso del sito.
Valori misurati
| Controllo | Che cosa abbiamo misurato |
|---|---|
| Velocità, mobile | Punteggio di prestazioni 99, contenuto più grande mostrato dopo 1,73 s, spostamento del layout 0,000, tempo di blocco 0 ms, primo contenuto dopo 1,72 s |
| Velocità, desktop | Punteggio di prestazioni 100, contenuto più grande mostrato dopo 0,55 s |
| Risposta del server | 176 ms; l’HTML è contrassegnato come private, quindi le cache condivise non lo memorizzano |
| Peso della pagina | Circa 20 KB di HTML compresso (99 KB non compresso), di cui circa 41 KB non compressi sono CSS inline; nessuna immagine nella home page |
| Titolo e descrizione | Titolo di 66 caratteri, descrizione di 168 caratteri, entrambi oltre i limiti di visualizzazione abituali |
| Titoli | Un H1, 8 H2, 6 H3 |
| Dati strutturati | Organization, Person, WebSite, ProfessionalService e FAQPage con 6 domande |
| Robots e accesso IA | I crawler di ricerca e IA sono consentiti, sitemap indicata, llms.txt presente, un URL mancante restituisce un vero 404; i crawler IA che abbiamo provato ottengono la pagina (HTTP 200) |
| Canali di contatto | Pagina di contatto, e-mail, 4 link telefonici, 3 link WhatsApp e 2 moduli nella home page |
| Intestazioni di sicurezza | HSTS (180 giorni, senza sottodomini), nosniff, referrer policy e frame options impostati; la content security policy è in modalità di sola segnalazione e non viene applicata |
| Script di terze parti | 1 host esterno, un beacon di analytics di una CDN, caricato nell’HTML della pagina |
Che cosa significa per la Sua analisi
Il Suo risultato segue la stessa logica: che cosa abbiamo misurato, che cosa significa e che cosa correggeremmo per primo. Lo scriviamo in un linguaggio semplice e lo inviamo via e-mail entro due giorni lavorativi.