Un sito da 100/100: come è fatto

Il 21 ottobre 2026 PageSpeed Insights ha analizzato la home di hash42.xyz, nella versione da computer.

100 in Prestazioni. 100 in Accessibilità. 100 in Best practice. 100 in SEO. E 3/3 nella nuova categoria Navigazione agentica.

Un punteggio così non arriva con un trucco finale. È la somma di tante scelte fatte prima, quasi tutte invisibili a chi visita il sito.

In questa guida trovi le cinque scelte che contano di più e, per ognuna, come si traduce nel codice.

Cosa misura PageSpeed Insights

PageSpeed Insights usa Lighthouse per valutare una pagina in cinque categorie:

• Prestazioni: quanto velocemente la pagina mostra i contenuti e risponde, con metriche come LCP, CLS e il tempo di blocco del thread principale.
• Accessibilità: se la pagina è usabile anche con lettori di schermo, tastiera e contrasti ridotti.
• Best practice: HTTPS, assenza di errori in console, librerie e API usate in modo corretto.
• SEO: se i motori di ricerca possono leggere e capire la pagina.
• Navigazione agentica: se un agente AI può comprenderla e usarla. È una categoria sperimentale, e invece di un punteggio da 0 a 100 mostra quanti controlli supera.

Ognuna di queste categorie si vince o si perde su scelte diverse.

01. Una pagina leggera prima di una pagina veloce

La pagina più veloce è quella che deve scaricare meno. Prima di ottimizzare il caricamento, conviene ridurre quello che c'è da caricare.

La home di hash42.xyz ha elementi pesanti: un controller 3D, un footer in cui le lettere si trascinano e si lanciano. Sono caricati solo quando servono:

• la libreria 3D arriva dopo il resto della pagina, e fino ad allora al suo posto c'è un'immagine statica;
• il motore fisico del footer viene scaricato solo quando ti avvicini al fondo della pagina;
• le librerie usate solo da alcune sezioni del sito non vengono più caricate in tutte le pagine.

Con il redesign di ottobre il JavaScript iniziale di ogni pagina pubblica è sceso da 291 a 194 KB compressi.

Tutto il codice
  ↓
Serve subito? → caricato con la pagina
  ↓
Serve dopo? → caricato quando ti avvicini
  ↓
Serve solo altrove? → non caricato qui

Se vuoi approfondire immagini, lazy loading e cache, li trovi nella guida su come rendere più veloce il tuo sito.

02. Prima quello che conta

Non tutto quello che c'è in una pagina ha la stessa urgenza. Il titolo e il messaggio principale devono comparire subito; il resto può arrivare un momento dopo.

Per questo le pagine vengono generate sul server: il contenuto principale è già nell'HTML che arriva al browser, e non aspetta che parta il JavaScript.

Lo stesso vale per la stabilità. Immagini e riquadri hanno dimensioni dichiarate, così lo spazio è riservato prima che il contenuto arrivi e niente salta mentre la pagina si carica. È quello che misura il CLS.

HTML dal server
  ↓
Titolo e contenuto visibili
  ↓
Stili e immagini principali
  ↓
Interazioni ed effetti

03. Un sito facile da capire

Un motore di ricerca non guarda la grafica. Legge la struttura.

Su hash42.xyz ogni pagina ha:

• un titolo e una descrizione propri;
• un indirizzo canonico, per evitare duplicati;
• i collegamenti tra versione italiana e inglese, con hreflang;
• dati strutturati in JSON-LD secondo Schema.org, per esempio quelli che descrivono ogni articolo del blog;
• una voce nella sitemap, con la data dell'ultima modifica.

A questo si aggiunge l'HTML semantico: un solo titolo principale per pagina, sezioni con titoli in ordine, link con un testo che dice dove portano. Sono le stesse informazioni che usano i motori di ricerca, i lettori di schermo e, sempre di più, gli assistenti AI.

04. Per le persone, non per i punteggi

Accessibilità e best practice si potrebbero trattare come una lista da spuntare. Il punto però è un altro: un sito deve funzionare per chiunque lo usi.

In pratica vuol dire:

• contrasto: il testo normale deve avere un rapporto di almeno 4,5:1 con il suo sfondo;
• focus visibile: chi naviga con la tastiera deve sempre vedere dove si trova;
• nomi ed etichette: ogni pulsante, link e campo ha un nome che un lettore di schermo può annunciare;
• immagini descritte: un testo alternativo che dice cosa mostra l'immagine;
• nessun errore in console: un errore JavaScript ignorato oggi è un problema per qualcuno domani.

Lighthouse controlla solo una parte di queste regole in automatico. Un 100 in Accessibilità non garantisce che il sito sia accessibile a tutti: dice che non ci sono errori tra quelli che una macchina sa riconoscere. Il resto va provato a mano, per esempio usando il sito solo con la tastiera.

05. Pronto per gli agenti

La categoria Navigazione agentica è arrivata in Lighthouse nel 2026 ed è ancora sperimentale. Misura quanto un sito è pronto per gli agenti AI che navigano e compiono azioni al posto delle persone.

Oggi i controlli principali sono tre:

Albero di accessibilità
  struttura, ruoli e nomi leggibili da un agente
  ↓
Stabilità
  il layout non si sposta mentre l'agente interagisce
  ↓
llms.txt
  un riassunto del sito in Markdown alla radice del dominio

Il 3/3 di hash42.xyz viene da qui. I primi due controlli premiano le stesse scelte dei paragrafi precedenti: un sito accessibile e stabile per le persone lo è anche per un agente. Il terzo è un file, llms.txt, che riassume chi è Hash42 Labs, i prodotti, i servizi e gli articoli del blog, con i link alle pagine.

C'è anche una quarta parte, WebMCP, che permetterà ai siti di dichiarare agli agenti le azioni disponibili, come compilare un modulo. Per ora è sperimentale: per valutarla bisogna aderire a una fase di prova di Chrome, quindi di solito resta fuori dal conteggio.

Desktop, mobile e utenti reali

Il report ha un dettaglio che vale la pena notare: nella sezione sull'esperienza degli utenti reali c'è scritto "Nessun dato". PageSpeed Insights mostra quei dati solo quando una pagina ha abbastanza visite da Chrome negli ultimi 28 giorni. Per un sito giovane, i dati di laboratorio sono l'unico riferimento.

E poi c'è il mobile, dove Lighthouse simula un telefono di fascia media con una rete lenta: lì ogni kilobyte e ogni millisecondo pesano molto di più.

Checklist per un sito da 100

Prima di pubblicare una pagina, verifica almeno questi cinque punti:

• Il codice che non serve subito viene caricato dopo, o solo nelle pagine che lo usano.
• Il contenuto principale è nell'HTML del server e le dimensioni di immagini e riquadri sono dichiarate.
• Ogni pagina ha titolo, descrizione, canonical, hreflang, dati strutturati e una voce nella sitemap.
• Contrasto, focus, etichette e testi alternativi sono a posto, e il sito è stato provato con la tastiera.
• C'è un llms.txt valido alla radice del dominio e il layout non si sposta durante il caricamento.

Il punteggio è una conseguenza

Un 100/100 fa piacere, ma non è l'obiettivo. È il segno che una serie di decisioni giuste è stata presa nel momento giusto: cosa caricare e quando, come descrivere le pagine, come renderle usabili per chiunque, persone o agenti.

Se il punteggio scende, non serve inseguirlo con un trucco. Serve capire quale di queste decisioni è stata dimenticata.

Fonti

• Google for Developers, About PageSpeed Insights
• Chrome for Developers, Lighthouse agentic browsing scoring
• web.dev, How the Core Web Vitals metrics thresholds were defined
• W3C, Understanding WCAG 2.2: Contrast (Minimum)