Punteggio Lighthouse: come superare 95 su mobile nel 2026

Che cosa misura Lighthouse nel 2026

Lighthouse è lo strumento ufficiale di Google per verificare la qualità tecnica di un sito web. Misura 4 dimensioni:

1. Performance: velocità di caricamento, fluidità, reattività (LCP, INP, CLS, FCP, TBT)
2. Accessibilità: conformità WCAG, leggibilità, navigazione da tastiera
3. Best Practices: sicurezza (HTTPS), immagini ottimizzate, errori nella console
4. SEO: metadati, indicizzabilità, dati strutturati di base

Ogni dimensione riceve un voto su 100. Il punteggio globale è la media ponderata.

Le soglie di Google:

• 0-49: rosso (scarso)
• 50-89: arancione (migliorabile)
• 90-100: verde (buono)

Ma nel 2026, sulle ricerche competitive, 90 non basta più. Bisogna puntare a 95+ su tutte e 4 le dimensioni per superare i concorrenti che hanno fatto il lavoro. Questo articolo spiega come.

Perché 95+ e non 90+

Tre ragioni per spingersi oltre 90.

Il peso dei Core Web Vitals. Dal Core Update di marzo 2026, i Core Web Vitals (LCP, INP, CLS) pesano di più nel posizionamento. Un sito a 92 e un sito a 98 non si equivalgono: il secondo ha un vantaggio SEO concreto sulle ricerche più combattute.

Indicizzazione mobile-first. Google indicizza e classifica in priorità la versione mobile. Il Lighthouse mobile è l’unico che conta davvero. Ed è più difficile da ottimizzare di quello desktop: connessione 4G, processore meno potente, schermo più piccolo. Raggiungere 95 su mobile richiede più impegno che 95 su desktop.

Convergenza competitiva. Nel 2026 molte agenzie hanno capito l’importanza di Lighthouse. I vostri concorrenti diretti hanno alzato il loro punteggio. Se restate a 75 quando loro sono a 95, la differenza si vede nel posizionamento.

Anatomia di un punteggio scarso: le cause tipiche

Un Lighthouse mobile tra 65 e 75 (caso tipico delle PMI romande nel 2026) cumula spesso i 5 problemi seguenti.

Problema 1: immagini troppo pesanti

Sintomo: LCP > 4 secondi, punteggio Performance basso.

Causa: immagini PNG/JPEG non compresse, senza formato moderno (WebP/AVIF), senza lazy loading, senza dimensioni dichiarate.

Soluzione: convertire tutte le immagini in WebP o AVIF (risparmio del 30-50 % sul peso), servirle in modo responsive con srcset, applicare il lazy loading a tutto ciò che sta sotto la linea di galleggiamento, dichiarare width e height per evitare il CLS.

Strumenti: Squoosh.app (compressione manuale), Imagify o ShortPixel (automatici per WordPress), servizio immagini di Astro/Next.js (automatico in fase di build).

Problema 2: JavaScript bloccante

Sintomo: TBT (Total Blocking Time) > 600 ms, INP peggiorato.

Causa: script di terze parti caricati in modo sincrono (Google Tag Manager, Hotjar, widget di chat), bundle JavaScript principale troppo grande (> 200 KB), nessun code splitting.

Soluzione: passare tutti gli script di terze parti in async o defer. Suddividere il bundle principale in chunk logici. Valutare ogni script di terze parti: è davvero utile?

Errore frequente: caricare Google Tag Manager sul 100 % del sito solo per tracciare 3 eventi. Se ha senso, preferite un tracciamento diretto senza GTM.

Problema 3: font web bloccanti

Sintomo: FOIT (Flash Of Invisible Text) all’inizio del caricamento, punteggio Performance basso.

Causa: font personalizzati caricati in modo sincrono da Google Fonts o Adobe Fonts.

Soluzione: font-display: swap in @font-face, subsetting dei font (caricare solo i caratteri utilizzati).

Problema 4: CSS che blocca il rendering

Sintomo: FCP (First Contentful Paint) > 1,8 s.

Causa: tutto il CSS del sito caricato in modo sincrono nel <head>.

Soluzione: estrarre il CSS critico (quello visibile above the fold) e inserirlo inline nell’HTML, caricare il resto in modo non bloccante.

Strumenti: Critters (Astro), criticalCSS (Next.js), penthouse.

Problema 5: plugin WordPress che si accumulano

Sintomo: punteggio Performance < 60 anche su siti semplici.

Causa: 20-40 plugin WordPress caricati, ognuno dei quali aggiunge 10-50 KB di JS e latenza lato server.

Soluzione: verifica dei plugin, disattivazione di quelli non essenziali, sostituzione dei plugin multipli con soluzioni native. Oppure migrazione verso uno stack moderno (vedi il nostro articolo su WordPress e SEO).

Le 9 azioni concrete per passare da 70 a 95+

Azione 1: verificare la situazione attuale

PageSpeed Insights → inserite il vostro URL → annotate i punteggi e le opportunità individuate da Lighthouse. Fatelo su mobile e su desktop. È il mobile che conta.

Azione 2: comprimere le immagini

La prima azione ad alto impatto. Conversione sistematica in WebP/AVIF. Su Astro/Next.js è automatica tramite <Image>. Su WordPress, Imagify o ShortPixel fanno il lavoro (CHF 5-10/mese).

Azione 3: lazy loading

Per tutte le immagini sotto la linea di galleggiamento: loading="lazy" nativo. Per i video YouTube incorporati, usate lite-youtube-embed anziché l’embed standard.

Azione 4: dichiarare le dimensioni delle immagini

Sempre width e height su ogni immagine, in HTML o tramite aspect-ratio in CSS. Evita il CLS (spostamento del layout durante il caricamento).

Azione 5: code splitting del JavaScript

Suddividere il bundle JS in chunk per route. Su Next.js è nativo. Su Astro il JS è minimo di default (solo le islands). Su WordPress con un tema pesante è più complesso.

Azione 6: script di terze parti in async o defer

Tutti gli <script> non critici in async o defer. Valutate la necessità di ogni script di terze parti (widget di chat, analytics, Google Tag Manager).

Azione 7: font ottimizzati

font-display: swap su tutte le @font-face. Self-hosting se possibile. Subsetting dei font personalizzati per ridurne il peso.

Azione 8: CSS critico inline

Il CSS del primo viewport inserito inline nel <head>. Il resto caricato in modo non bloccante.

Azione 9: Schema.org per il SEO di Lighthouse

Il punteggio SEO di Lighthouse verifica la presenza di uno schema.org di base. Implementate almeno Organization, BreadcrumbList e Article.

Errori da evitare

Errore 1: ottimizzare solo il desktop. Molte PMI testano solo il desktop e concludono « il mio Lighthouse è a 95 ». Il mobile resta a 60. Google classifica in base al mobile.

Errore 2: misurare una sola volta. Lighthouse varia in base alle condizioni (cache, rete, carico del server). Fate 3 test e prendete la mediana.

Errore 3: ignorare le nuove metriche. INP ha sostituito FID nel 2024. Molti articoli datati non parlano di INP. Assicuratevi che il vostro audit utilizzi le metriche del 2026.

Errore 4: punteggio gonfiato artificialmente togliendo funzioni. Disattivare tutte le funzionalità per gonfiare il punteggio Lighthouse non serve se il sito diventa inutile. Tenete presente l’esperienza utente.

Che cosa consegna Voren

Tutti i siti Voren vengono consegnati con un punteggio Lighthouse mobile misurato alla messa online. È il nostro standard di consegna:

• Sito vetrina Essenziale: Lighthouse > 90 su mobile e desktop
• Sito vetrina Premium: Lighthouse > 95
• Sito vetrina Su misura: Lighthouse > 95
• E-commerce: Lighthouse > 90 (i siti e-commerce sono strutturalmente più complessi da ottimizzare)
• Web app: Lighthouse > 85 a seconda della complessità

Stack predefinito: Astro 5 (siti editoriali) o Next.js 15 (siti interattivi) + immagini ottimizzate + script async + schema.org + CSS critico inline.

Per approfondire

Richiedere un audit Lighthouse gratuito: diagnosi completa del vostro sito attuale e piano d’azione in 7 giorni.

Vedere il nostro servizio Sito vetrina: Lighthouse 90-95+ come obiettivo, misurato alla messa online.

Leggere il nostro articolo sui Core Web Vitals: capire le 3 metriche che pesano sulla Performance di Lighthouse.