Punto a Lighthouse 100. Ma il punteggio non decide il progetto

Il 100 non è un adesivo da mettere sul sito

I punteggi mi piacciono perché costringono a uscire dalle dichiarazioni generiche. «Veloce», «accessibile» e «ottimizzato» sono parole facili da scrivere. Un controllo eseguito su una pagina reale, in una data precisa e con un profilo dichiarato produce invece un risultato che può essere verificato.

Per questo pubblico le prove e continuo a misurarle. Non considero Lighthouse una decorazione commerciale, né un test riservato alla homepage. Una modifica a un componente condiviso può cambiare molte pagine; una lingua, un modulo o una funzione possono comportarsi diversamente dal resto del sito.

Il numero isolato, però, dice poco se non so quale pagina è stata provata, in quali condizioni, su quale dispositivo e prima o dopo quali interventi. Un 100 senza contesto può essere autentico e, nello stesso tempo, raccontare soltanto la parte più comoda del progetto.

Non mi interessa collezionare cento. Mi interessa sapere perché una pagina li raggiunge e accorgermi quando smette di farlo.

Il metodo parte dal massimo

Ogni progetto nasce con lo stesso obiettivo tecnico. Non costruisco prima il sito e poi provo a recuperare i punti rimasti: peso delle immagini, caricamento dei font, struttura del codice, contrasto, navigazione da tastiera, metadati e script entrano nelle decisioni mentre il sito prende forma.

Il mio criterio di verifica è semplice da dichiarare e più impegnativo da applicare.

Un 98 o 99 non diventa quindi il nuovo obiettivo. È una tolleranza che richiede una causa. Se un valore scende sotto la soglia, il controllo non passa e il problema va affrontato. Se oscilla, ripeto la prova nelle stesse condizioni prima di decidere che cosa significhi.

Questo rigore non serve a promettere contrattualmente quattro 100 in qualunque situazione. Serve a evitare che «abbastanza veloce» o «tecnicamente a posto» restino opinioni prive di una misura.

La differenza tra un limite e un alibi

Un punteggio può diminuire per molte ragioni: una regressione nel codice, un’immagine sovradimensionata, uno script caricato senza necessità, una risposta lenta del server o una dipendenza esterna. Non tutte hanno lo stesso significato.

Le prime domande sono sempre tecniche. Posso eliminare la causa? Posso ottenere lo stesso risultato con meno peso, meno richieste o meno JavaScript? Posso caricare una risorsa soltanto quando serve? Posso evitare che blocchi la parte principale della pagina?

Finché esiste una correzione che non peggiora il progetto, il punteggio non è un compromesso: è lavoro ancora da fare. Le esigenze del cliente non possono diventare una formula generica con cui giustificare risorse trascurate, librerie inutili o integrazioni inserite senza controllo.

Il limite comincia soltanto dopo aver identificato la causa, provato le alternative e misurato il risultato. Prima di quel momento è troppo presto per dire che un 98 sia inevitabile.

Una hero non è automaticamente un errore

Una grande immagine iniziale può essere uno degli elementi più importanti di un progetto. Può presentare un prodotto, rendere riconoscibile un lavoro fotografico o dare alla pagina il carattere che distingue quell’attività dalle altre. Può anche diventare la risorsa più pesante del primo schermo.

La risposta professionale non è rimuoverla immediatamente. Prima scelgo il formato, la comprimo, preparo dimensioni adatte ai diversi schermi, dichiaro lo spazio che occuperà e verifico quando deve essere caricata. Se è un video, valuto se debba partire davvero, se basti un’immagine di copertina o se possa attendere un’azione dell’utente.

Alla fine di questo lavoro la hero può continuare a incidere sul risultato. A quel punto la domanda non è più «come faccio a conquistare un altro punto?», ma «quanto valore perderebbe il progetto eliminando o impoverendo questo elemento?».

Naturalmente vale anche il contrario. Una fotografia enorme scelta per abitudine, un video decorativo che parte da solo o cinque varianti scaricate senza motivo non sono una scelta di identità: sono un problema da correggere.

Le terze parti entrano nel risultato

Prenotazioni, mappe, pagamenti, video, chat e altri servizi esterni possono essere necessari. Portano però codice, connessioni e tempi di risposta che non controllo interamente. Anche quando l’integrazione locale è pulita, il fornitore può cambiare uno script o rispondere più lentamente.

In molti casi posso ridurre l’impatto: caricare una mappa dopo il consenso o il clic, mostrare una copertina prima del video, limitare gli script alle sole pagine che ne hanno bisogno, collegare un servizio invece di incorporarlo ovunque. In altri casi la funzione deve essere disponibile subito perché è parte del compito principale della pagina.

Un sito dimostrativo svuotato di ogni dipendenza può ottenere 100. Lo stesso progetto con una prenotazione realmente funzionante può fermarsi a 99. Il primo numero non rende automaticamente migliore il primo sito.

Ciò che conta è poter dimostrare che la funzione serve, che l’integrazione è stata ridotta al necessario e che il costo residuo è conosciuto. «È colpa del servizio esterno» non è una diagnosi sufficiente.

Quattro 100 non certificano tutto

Anche il risultato perfetto ha confini precisi. Lighthouse esegue un controllo di laboratorio. È molto utile per trovare regressioni e problemi riproducibili, ma non osserva tutte le reti, tutti i dispositivi e tutte le interazioni delle persone che useranno il sito.

La categoria Accessibilità individua molti errori automatici, non sostituisce i controlli manuali, la navigazione da tastiera o una valutazione completa di conformità. Best Practices non è un penetration test. SEO verifica una base tecnica, non promette posizioni, visite o citazioni nelle risposte delle AI.

La documentazione di Google Search Central (si apre in una nuova scheda) chiarisce che buoni risultati nei rapporti tecnici non garantiscono le prime posizioni e che l’esperienza della pagina comprende più di uno o due indicatori. La guida di web.dev sui Core Web Vitals (si apre in una nuova scheda) distingue inoltre i dati di laboratorio di Lighthouse dai dati raccolti nel tempo sugli utenti reali.

Per questo ai punteggi affianco controlli di routing, moduli ed email, responsive, tema chiaro e scuro, tastiera, contenuti, metadati, dati strutturati, privacy, sicurezza e comportamento delle funzioni. Quando esistono dati reali sufficienti, guardo anche i Core Web Vitals osservati sul campo.

La prova vera è il processo

Uno screenshot mostra un momento. Un metodo deve continuare a funzionare quando il sito cambia, quando viene aggiornato il browser, quando il fornitore esterno modifica il proprio codice e quando una nuova pagina entra nell’architettura.

Per questo registro pagina, ambiente, data, profilo e risultati. Controllo ciò che è stato modificato e ciò che può averne subito gli effetti. Se una verifica live rivela una regressione, il lavoro non è chiuso soltanto perché in locale sembrava tutto a posto.

È anche il modo più corretto per presentare i numeri a un cliente. Non come una garanzia astratta, ma come la conseguenza di un processo verificabile che continua dopo il primo test.

Nei miei servizi e standard di realizzazione non prometto un punteggio immutabile né un posizionamento automatico. Progetto, misuro, correggo e documento tutto ciò che è realmente sotto il mio controllo.

Che cosa dovrebbe chiedere chi commissiona un sito

Chiedere i risultati Lighthouse è utile. Fermarsi al numero lo è molto meno. Una prova seria dovrebbe permettere di capire almeno quale URL è stata controllata, quando, in quale ambiente e con quale profilo.

Poi vengono le domande che il grafico non contiene: il modulo invia davvero le email? La pagina resta utilizzabile da tastiera? Le immagini importanti conservano qualità? Le funzioni esterne servono allo scopo? Il sito protegge dati e percorsi? Contenuti e azioni sono comprensibili alle persone per cui è stato costruito?

Un professionista non dovrebbe avere paura di mostrare quattro 100. Non dovrebbe neppure usarli per evitare queste domande.

Punto a Lighthouse 100 perché il lavoro tecnico deve essere misurabile. Il progetto viene prima perché il sito deve essere utile.