Il tuo sito ha guadagnato diversi punti su Google PageSpeed Insights senza che tu abbia modificato una sola riga di codice?
Non è necessariamente un errore, ma non significa nemmeno che le prestazioni siano migliorate. La spiegazione potrebbe trovarsi nell’ultimo aggiornamento di Lighthouse, il sistema utilizzato da Google per analizzare la velocità e la qualità tecnica delle pagine web.
Il 27 ottobre 2026 è stata rilasciata la versione Lighthouse 13.6.0, che introduce alcune modifiche significative al funzionamento di Lantern, il motore che simula il caricamento delle pagine in condizioni di rete controllate. L’aggiornamento è arrivato su PageSpeed Insights all’inizio di novembre e può produrre risultati differenti rispetto alle misurazioni precedenti, anche quando il sito analizzato è rimasto identico.
La novità riguarda soprattutto il modo in cui Lighthouse stima il First Contentful Paint (FCP) e il Largest Contentful Paint (LCP), due metriche fondamentali per interpretare la velocità di visualizzazione dei contenuti.
Per chi si occupa di SEO, sviluppo web e ottimizzazione delle conversioni, il cambiamento solleva una questione concreta: come distinguere un miglioramento effettivo dell’esperienza utente da una variazione introdotta dallo strumento di misurazione?
In questa guida analizziamo le modifiche di Lighthouse 13.6, le conseguenze sui punteggi PageSpeed Insights, il rapporto con i Core Web Vitals e le procedure per continuare a misurare correttamente le prestazioni di un sito.
Perché PageSpeed Insights può mostrare punteggi diversi da novembre 2026
PageSpeed Insights è uno degli strumenti più utilizzati da SEO specialist, sviluppatori e proprietari di siti web per individuare problemi di performance. Inserendo un URL, permette di ottenere un’analisi delle prestazioni su dispositivi mobili e desktop, accompagnata da indicatori e suggerimenti tecnici.
Tra gli elementi più riconoscibili del report c’è il punteggio Performance, espresso su una scala da 0 a 100.
Il punteggio è utile per una prima valutazione, ma rappresenta il risultato di un modello di analisi, non una misurazione universale della velocità percepita dagli utenti.
Google distingue infatti due categorie di dati.
I dati di laboratorio (lab data) derivano da test eseguiti in condizioni controllate. Consentono di riprodurre scenari tecnici, analizzare le risorse caricate dalla pagina e individuare opportunità di ottimizzazione.
I dati sul campo (field data) provengono invece dalle esperienze effettive degli utenti Chrome incluse nel Chrome User Experience Report (CrUX). Raccolgono informazioni sulle prestazioni riscontrate durante la navigazione reale, considerando dispositivi, reti e condizioni differenti.
Questa distinzione è decisiva per comprendere Lighthouse 13.6.
L’aggiornamento modifica il modello utilizzato per produrre alcune stime di laboratorio, senza implicare automaticamente un cambiamento nell’esperienza vissuta dai visitatori.
In altre parole, una pagina può ottenere oggi 95 punti dove ieri ne otteneva 80, senza essere diventata più veloce. Il valore è un esempio ipotetico, non un incremento medio documentato.
Secondo Barry Pollard, Web Performance Developer Advocate del team Chrome, la nuova simulazione dovrebbe fornire stime più accurate di FCP e LCP e, nella maggior parte dei casi interessati, risultati migliori. Le variazioni potrebbero essere particolarmente evidenti nei siti che utilizzano molto JavaScript.
Il punto fondamentale è che non è cambiato il significato delle metriche: è cambiato il modo in cui Lighthouse simula alcune condizioni che contribuiscono al loro calcolo.
Che cos’è Lighthouse e come funziona la simulazione Lantern
Per capire la portata dell’aggiornamento occorre distinguere tre elementi che vengono spesso confusi: PageSpeed Insights, Lighthouse e Lantern.
PageSpeed Insights è il servizio di Google che restituisce il report di analisi di una pagina web. Lighthouse è il motore di auditing che esegue le verifiche tecniche di laboratorio. Lantern è il sistema di simulazione utilizzato da Lighthouse per stimare alcune prestazioni in condizioni di rete e capacità di elaborazione differenti da quelle della misurazione iniziale.
Nel normale funzionamento del throttling simulato, Lighthouse raccoglie informazioni sul caricamento della pagina e le utilizza per stimare cosa accadrebbe in uno scenario più limitato, per esempio con una connessione più lenta.
Questo approccio permette di analizzare le prestazioni senza dipendere esclusivamente dalle condizioni fisiche della rete nel momento del test.
La simulazione deve però ricostruire il comportamento del browser: quali richieste arrivano prima, quali risorse dipendono da altre, quali operazioni bloccano la visualizzazione e quanto tempo richiede l’esecuzione degli script.
Si tratta di un modello complesso, soggetto a miglioramenti progressivi.
Con Lighthouse 13.6 Google ha aggiornato proprio alcuni di questi meccanismi, intervenendo sul modello delle connessioni, sulle dipendenze delle risorse e sull’interpretazione degli eventi di rendering.
La modifica non rappresenta quindi una semplice correzione cosmetica del punteggio: riguarda il sistema che genera parte delle misurazioni sintetiche.
Lighthouse 13.6: tutte le modifiche tecniche che influenzano i punteggi
Le note ufficiali di rilascio, pubblicate nel repository GoogleChrome/lighthouse su GitHub il 27 ottobre 2026, descrivono una serie di interventi finalizzati ad aumentare l’accuratezza della simulazione Lantern.
Le modifiche più importanti riguardano quattro aspetti: l’identificazione delle risorse che bloccano il rendering, la simulazione del Largest Contentful Paint, il modello delle connessioni di rete e la gestione delle operazioni JavaScript.
1. Una nuova identificazione delle risorse che bloccano il rendering
Uno degli interventi più significativi riguarda il modo in cui Lighthouse stabilisce se una risorsa impedisce al browser di visualizzare i contenuti.
Durante il caricamento di una pagina, il browser scarica numerosi file: documenti HTML, fogli di stile CSS, script JavaScript, immagini, font e altre risorse.
Non tutte le richieste hanno lo stesso ruolo. Alcune possono ritardare la visualizzazione iniziale della pagina, mentre altre possono essere elaborate senza impedire al browser di mostrare i contenuti.
Nella versione 13.5, Lantern utilizzava la priorità di caricamento delle richieste, o fetch priority, per determinare se una risorsa dovesse essere considerata bloccante nella simulazione.
Questo approccio poteva generare interpretazioni imprecise. Una risorsa con priorità elevata, infatti, non è necessariamente una risorsa che blocca il rendering.
Con Lighthouse 13.6, Lantern utilizza direttamente l’informazione renderBlocking fornita dal protocollo di Chrome. Soltanto quando questa informazione non è disponibile ricorre alla priorità della richiesta come criterio alternativo.
La differenza può apparire marginale, ma ha conseguenze importanti. Se una risorsa veniva erroneamente considerata bloccante, la simulazione precedente poteva attribuirle un ritardo che non corrispondeva al comportamento effettivo del browser.
Per esempio, immaginiamo una pagina che carica diversi moduli JavaScript, alcuni dei quali hanno una priorità di download elevata ma non impediscono al browser di mostrare il titolo e il contenuto iniziale.
Con il vecchio modello, Lighthouse poteva sovrastimare il tempo necessario per la prima visualizzazione. La nuova simulazione può ricostruire meglio queste dipendenze e restituire un FCP inferiore.
Attenzione, però: non significa che Lighthouse 13.6 abbia eliminato le risorse che bloccano il rendering. Ha migliorato il modo in cui vengono riconosciute nel modello.
2. Correzione del Largest Contentful Paint quando l’elemento principale è un testo
Un altro cambiamento riguarda le pagine in cui l’elemento principale visibile è un blocco di testo.
Il First Contentful Paint misura il momento in cui il browser visualizza il primo contenuto rilevante, come un testo o un’immagine.
Il Largest Contentful Paint misura invece quando viene visualizzato l’elemento di contenuto più grande presente nell’area visibile della pagina.
Talvolta i due eventi coincidono.
Pensiamo alla homepage di un sito aziendale con un grande titolo testuale nella parte superiore e pochi altri elementi visibili. Il titolo può rappresentare sia il primo contenuto visualizzato sia il maggiore elemento di contenuto nella viewport.
In questi casi, FCP e LCP possono verificarsi nello stesso frame di rendering.
In precedenza, la simulazione Lantern poteva trattare le dipendenze dell’LCP in modo eccessivamente esteso, includendo nel calcolo richieste che non erano necessarie per visualizzare quell’elemento.
Lighthouse 13.6 interviene su questo comportamento: quando l’LCP è un testo che compare nello stesso frame dell’FCP, la simulazione utilizza il grafo delle dipendenze costruito per l’FCP.
Un caso concreto che ha contribuito a individuare il problema è stato segnalato dallo sviluppatore Ivan Akulov, che aveva osservato una discrepanza su una pagina realizzata con Framer. La simulazione restituiva un LCP molto più tardivo dell’FCP, benché entrambi si riferissero allo stesso contenuto testuale.
Il miglioramento contribuisce a evitare che la simulazione penalizzi impropriamente pagine nelle quali il contenuto principale viene visualizzato subito.
3. Migliora la simulazione delle connessioni HTTP/2 e HTTP/3
Lighthouse 13.6 introduce anche aggiornamenti al modello di rete utilizzato da Lantern.
Tra le modifiche documentate figurano una gestione più accurata delle connessioni HTTP/3 multiplexate, il trattamento dei dati trasferiti attraverso HTTP/2, il conteggio delle richieste senza connessione e il calcolo della latenza e della velocità effettiva delle connessioni verso i server di origine.
Per comprenderne l’importanza bisogna considerare che un browser moderno non scarica necessariamente le risorse una alla volta.
Con protocolli come HTTP/2 e HTTP/3, più richieste possono condividere una connessione attraverso meccanismi di multiplexing.
Se il modello di simulazione non rappresenta correttamente questi comportamenti, può stimare tempi differenti da quelli effettivamente necessari per trasferire le risorse.
Il nuovo modello cerca di avvicinarsi maggiormente al funzionamento delle connessioni moderne. Per questo alcune pagine potrebbero registrare variazioni nei tempi simulati anche senza cambiamenti nella configurazione del server, del CDN o delle risorse.
L’aggiornamento, quindi, non rende automaticamente più veloce un sito che utilizza HTTP/3. Migliora la rappresentazione di quel protocollo all’interno del test.
4. Una ricostruzione più accurata delle operazioni JavaScript
Le note di rilascio segnalano inoltre l’introduzione dell’attribuzione di eventi V8 come v8.compileModule e v8.evaluateModule.
Questi eventi riguardano rispettivamente la compilazione e la valutazione dei moduli JavaScript da parte del motore V8 utilizzato da Chrome.
Il loro trattamento nel grafo delle dipendenze contribuisce a ricostruire con maggiore precisione il lavoro svolto dal browser durante il caricamento.
Questo aspetto è particolarmente rilevante per siti sviluppati con framework JavaScript, applicazioni a pagina singola e interfacce caratterizzate da un’architettura complessa.
Barry Pollard ha specificato che le modifiche non riguardano esclusivamente le Single Page Application (SPA), ma che i siti fortemente dipendenti da JavaScript hanno maggiori probabilità di registrare variazioni nei risultati.
È importante non generalizzare: la presenza di React, Vue, Angular o di un altro framework non garantisce automaticamente un aumento del punteggio. L’effetto dipende dalle caratteristiche della pagina e dal modo in cui vengono gestite le dipendenze durante il caricamento.
Quali siti potrebbero vedere i cambiamenti maggiori?
Non tutti i siti sono esposti nello stesso modo alle variazioni introdotte da Lighthouse 13.6. Le caratteristiche dell’architettura tecnica e dei contenuti possono determinare risultati molto diversi.
| Tipologia di sito | Possibile effetto dell’aggiornamento |
|---|---|
| Single Page Application (SPA) | Variazioni anche rilevanti nelle metriche simulate, soprattutto su pagine ricche di JavaScript |
| Siti sviluppati con React, Vue o Angular | Possibili differenze nella modellazione delle dipendenze e delle operazioni JavaScript |
| Siti realizzati con Framer | Potenziale correzione della sovrastima del LCP, in particolare su layout dominati dal testo |
| Siti con grandi titoli testuali above the fold | Possibile maggiore coerenza tra FCP e LCP simulati |
| eCommerce con molti script e risorse esterne | Possibili variazioni dipendenti dalla struttura delle richieste e dal lavoro del browser |
| Blog statici e siti HTML leggeri | Variazioni potenzialmente più contenute, senza garanzie |
Queste indicazioni rappresentano scenari tecnicamente plausibili, non risultati di un benchmark comparativo eseguito su tutte le categorie.
Un esempio interessante arriva dal sito react.dev. Dopo l’aggiornamento, sono state segnalate differenze considerevoli nei risultati Lighthouse, che hanno alimentato la discussione pubblica sul nuovo modello di simulazione. Tuttavia, questi casi individuali non consentono di stabilire un aumento medio valido per l’intero web.
Lighthouse 13.6 cambia anche i Core Web Vitals?
Questo è probabilmente il punto più importante per chi lavora nella SEO.
La risposta richiede una distinzione: Lighthouse 13.6 può modificare i valori di alcune metriche nei test di laboratorio, ma non modifica automaticamente i Core Web Vitals raccolti dagli utenti reali.
I Core Web Vitals sono un insieme di metriche definite da Google per valutare tre dimensioni fondamentali dell’esperienza di navigazione: velocità di caricamento, reattività alle interazioni e stabilità visiva.
Le tre metriche Core Web Vitals
Soglie considerate buone da Google, valutate al 75° percentile
LCP
≤ 2,5 s
Caricamento del contenuto principale
INP
≤ 200 ms
Reattività alle interazioni
CLS
≤ 0,1
Stabilità visiva del layout
Il Largest Contentful Paint è quindi sia una metrica presente nei test Lighthouse sia un Core Web Vital misurabile sul campo. I due valori, però, possono differire perché provengono da processi di misurazione differenti.
Il First Contentful Paint, pur essendo una metrica utile per analizzare il caricamento, non fa parte dei tre Core Web Vitals attuali.
Analogamente, il Total Blocking Time (TBT), utilizzato nei test di laboratorio per analizzare il tempo in cui il thread principale rimane bloccato, non coincide con Interaction to Next Paint (INP). Quest’ultimo misura la reattività delle interazioni durante la visita dell’utente ed è un Core Web Vital.
Se Lighthouse 13.6 restituisce un LCP simulato migliore, non significa che il valore LCP registrato da CrUX sia migliorato.
Perché i dati CrUX non cambiano automaticamente
Il Chrome User Experience Report raccoglie dati aggregati provenienti da utenti Chrome idonei, durante la navigazione reale.
PageSpeed Insights mostra queste informazioni considerando una finestra mobile di 28 giorni e utilizzando il 75° percentile per valutare le metriche.
La nuova simulazione Lantern non riscrive le esperienze già registrate dagli utenti.
Questo significa che un sito potrebbe mostrare un punteggio Performance verde nei test di laboratorio e continuare a presentare problemi di LCP, INP o CLS nei dati reali.
La situazione inversa è altrettanto possibile: una pagina potrebbe avere Core Web Vitals soddisfacenti e ottenere un risultato Lighthouse non particolarmente elevato in una specifica simulazione.
Non è una contraddizione. I due sistemi osservano prestazioni diverse, in condizioni diverse e con finalità differenti.
Che impatto ha Lighthouse 13.6 sul posizionamento SEO?
L’aggiornamento non introduce un nuovo fattore di ranking e non costituisce un aggiornamento dell’algoritmo di Google Search.
Un aumento del punteggio PageSpeed Insights non genera, di per sé, un incremento delle posizioni nelle pagine dei risultati.
Google precisa che i Core Web Vitals sono utilizzati dai suoi sistemi di ranking, ma che il loro miglioramento non garantisce le prime posizioni. Il posizionamento dipende da numerosi fattori, tra cui la pertinenza e la qualità dei contenuti rispetto alle ricerche effettuate.
La stessa documentazione ufficiale invita a non concentrare gli sforzi esclusivamente sull’ottenimento di un punteggio perfetto nei tool di performance.
Lighthouse rimane comunque uno strumento importante per la SEO tecnica. Consente di individuare criticità che possono influenzare l’esperienza utente, come immagini troppo pesanti, script bloccanti, risorse caricate inutilmente e ritardi nella visualizzazione dei contenuti.
Il suo valore risiede nella capacità diagnostica, non soltanto nel numero finale.
Per esempio, un eCommerce potrebbe passare da 68 a 85 punti dopo l’aggiornamento del modello senza aver migliorato la velocità di caricamento percepita dai clienti. In questo scenario non sarebbe corretto attribuire al nuovo punteggio un aumento delle conversioni o delle prestazioni organiche.
Diverso sarebbe il caso in cui, dopo interventi tecnici documentati, migliorassero anche il LCP sul campo, la reattività della pagina e gli indicatori di comportamento degli utenti.
La conseguenza operativa è semplice: le performance SEO devono essere valutate attraverso un insieme coerente di metriche, senza utilizzare il punteggio sintetico come unica prova di efficacia.
Come confrontare correttamente i punteggi PageSpeed Insights prima e dopo Lighthouse 13.6
L’aggiornamento rende particolarmente importante la gestione delle serie storiche. Chi conserva report settimanali o mensili potrebbe rilevare un salto improvviso dei valori nei primi giorni di novembre 2026.
Per interpretarlo è necessario verificare se il cambiamento derivi dal sito o dal sistema di analisi.
Passaggio 1. Verificare la versione di Lighthouse
Apri PageSpeed Insights e analizza la pagina interessata.
Nel report, individua le informazioni sull’ambiente di test e sulla versione di Lighthouse utilizzata, normalmente riportate nella parte inferiore della sezione diagnostica.
Se stai confrontando un test realizzato con Lighthouse 13.5 e uno con Lighthouse 13.6, devi considerare che il modello di simulazione non è identico.
Anche quando le impostazioni apparenti sono le stesse, una variazione nelle metriche potrebbe dipendere dall’aggiornamento.
Passaggio 2. Confrontare le singole metriche, non soltanto il punteggio
Il punteggio Performance è un indice sintetico ottenuto dalla combinazione ponderata di diverse misurazioni.
Un miglioramento del risultato complessivo può derivare da una o più metriche, con effetti differenti in base al loro peso nel calcolo.
Per questo è opportuno confrontare almeno FCP, LCP, Speed Index, Total Blocking Time e Cumulative Layout Shift, verificando quali valori abbiano subito la variazione maggiore.
Se il cambiamento riguarda soprattutto FCP e LCP simulati, mentre la pagina non è stata modificata, Lighthouse 13.6 diventa una possibile spiegazione da verificare.
La correlazione temporale, da sola, non dimostra però la causa.
Passaggio 3. Consultare i dati reali di CrUX
Nella parte superiore del report PageSpeed Insights, quando sono disponibili dati sufficienti, trovi la sezione relativa all’esperienza degli utenti reali.
Queste informazioni sono particolarmente utili per comprendere se un miglioramento osservato in laboratorio corrisponda anche a un cambiamento nell’esperienza di navigazione.
È importante ricordare che i dati CrUX rappresentano una finestra mobile di 28 giorni. Una variazione non può quindi essere attribuita automaticamente a un singolo intervento, perché il valore aggregato comprende esperienze registrate in giorni differenti.
Per i siti con traffico insufficiente, i dati sul campo potrebbero non essere disponibili a livello di singolo URL. In alcuni casi Google può mostrare dati relativi all’origine, purché sia presente un campione adeguato.
Passaggio 4. Controllare Google Search Console
La sezione Segnali web essenziali di Google Search Console permette di individuare gruppi di URL che presentano problematiche legate ai Core Web Vitals.
È utile per capire se nel tempo stiano emergendo miglioramenti o peggioramenti che coinvolgono porzioni significative del sito.
Non è però uno strumento per verificare direttamente l’effetto della nuova simulazione Lighthouse: Search Console utilizza dati sul campo e raggruppamenti di pagine, non il punteggio Performance prodotto dal singolo test.
Passaggio 5. Ripetere i test in condizioni coerenti
Anche all’interno della stessa versione di Lighthouse, i punteggi possono presentare oscillazioni.
Variabili come richieste di terze parti, contenuti dinamici, annunci pubblicitari, condizioni del sistema e disponibilità delle risorse possono influenzare i risultati.
È quindi consigliabile effettuare più esecuzioni, mantenere costanti le impostazioni e osservare la distribuzione dei valori anziché basarsi su una singola misurazione.
Per un monitoraggio continuativo, può essere utile conservare la mediana di almeno tre-cinque test eseguiti nelle stesse condizioni. Si tratta di una raccomandazione metodologica, non di un numero di test imposto da Google.
Esempio pratico: come interpretare un aumento improvviso del punteggio
Immaginiamo di monitorare la homepage di un sito eCommerce che utilizza numerosi moduli JavaScript.
Il 26 ottobre 2026 registriamo un punteggio Performance pari a 71. Il 5 novembre, senza modifiche al sito, il risultato sale a 89.
Il primo controllo dovrebbe riguardare la versione di Lighthouse e le metriche individuali, non l’ipotesi che il sito sia diventato più veloce.
ESEMPIO DIDATTICO · VALORI IPOTETICI, NON DATI DI UN TEST REALE
Supponiamo che il dettaglio mostri i seguenti valori:
| Metrica | Prima | Dopo |
|---|---|---|
| Performance Score | 71 | 89 |
| FCP simulato | 2,8 s | 1,7 s |
| LCP simulato | 4,5 s | 2,4 s |
| LCP sul campo (CrUX) | 3,1 s | 3,1 s |
| INP sul campo (CrUX) | 180 ms | 180 ms |
I valori illustrano un possibile scenario: cambiano sensibilmente le stime di laboratorio, mentre i dati reali rimangono invariati.
In questo caso la conclusione non dovrebbe essere «abbiamo migliorato le prestazioni del sito del 25%», né «l’esperienza utente è migliorata di 18 punti».
La formulazione corretta sarebbe: «Il punteggio Lighthouse è aumentato dopo l’aggiornamento del motore di simulazione; al momento non abbiamo evidenze di un corrispondente miglioramento dei Core Web Vitals sul campo».
Il nuovo punteggio può rappresentare una stima più accurata del comportamento della pagina, ma non è una prova che la pagina abbia iniziato a caricarsi più velocemente.
Come aggiornare il monitoraggio SEO dopo Lighthouse 13.6
Per chi gestisce più siti o produce report periodici, il problema non riguarda soltanto l’interpretazione del singolo test.
L’aggiornamento può introdurre una discontinuità nelle serie storiche dei dati sintetici, rendendo meno affidabili i confronti effettuati senza considerare la versione dello strumento.
È opportuno trattare il passaggio a Lighthouse 13.6 come un cambiamento di metodologia.
Separare le serie storiche
Se utilizzi dashboard, fogli di calcolo o piattaforme di monitoraggio automatico, inserisci un’annotazione relativa all’aggiornamento distribuito all’inizio di novembre 2026.
I dati precedenti non devono essere cancellati, ma non dovrebbero essere confrontati direttamente con quelli successivi come se fossero ottenuti con un identico sistema di misurazione.
Una buona soluzione consiste nel conservare due riferimenti distinti: la serie storica precedente e una nuova baseline costruita con Lighthouse 13.6.
Questo approccio permette di continuare a misurare i progressi futuri senza confondere un cambiamento metodologico con il risultato di un intervento tecnico.
Conservare le informazioni tecniche del test
Quando possibile, insieme al punteggio dovrebbero essere registrati l’URL analizzato, la data, la versione di Lighthouse, il contesto mobile o desktop e i valori delle singole metriche.
Per confronti particolarmente rigorosi è utile conservare anche la configurazione del test, la versione del browser e gli eventuali artefatti diagnostici.
Queste informazioni permettono di ricostruire le condizioni della misurazione e rendono più trasparente la reportistica.
Non attribuire automaticamente i miglioramenti alle ottimizzazioni SEO
Supponiamo che un’agenzia abbia ottimizzato le immagini di un sito il 30 ottobre e abbia misurato un aumento del punteggio il 3 novembre.
Senza considerare l’aggiornamento Lighthouse, potrebbe essere tentata di attribuire l’intera variazione alla compressione delle immagini.
Questo sarebbe metodologicamente scorretto.
L’intervento potrebbe aver prodotto benefici effettivi, ma una parte del cambiamento osservato potrebbe dipendere dal nuovo modello Lantern.
Per isolare il contributo dell’ottimizzazione occorre, quando possibile, confrontare test realizzati con la stessa versione dello strumento, condizioni comparabili e una baseline appropriata. I dati sul campo possono fornire un riscontro ulteriore, tenendo conto della loro finestra temporale.
Un modello di report per i professionisti SEO
Una reportistica efficace potrebbe utilizzare una struttura come questa:
| Elemento monitorato | Criterio di valutazione |
|---|---|
| Lighthouse Performance | Evoluzione dei punteggi a parità di versione |
| FCP e LCP di laboratorio | Analisi delle prestazioni simulate |
| LCP, INP e CLS sul campo | Esperienza effettiva degli utenti idonei in CrUX |
| Search Console | Evoluzione dei gruppi di URL con problemi |
| Ottimizzazioni tecniche | Interventi eseguiti e date di pubblicazione |
| Versione del sistema di test | Identificazione delle discontinuità metodologiche |
L’obiettivo non è produrre report più complessi, ma risultati interpretabili.
Quali ottimizzazioni SEO restano prioritarie dopo l’aggiornamento?
Un aumento del punteggio non dovrebbe portare a interrompere le attività di ottimizzazione tecnica, soprattutto quando i dati sul campo mostrano ancora problemi.
Le principali priorità rimangono sostanzialmente invariate.
Migliorare il Largest Contentful Paint reale
Quando l’LCP sul campo supera le soglie raccomandate, bisogna individuare quale elemento rappresenti il contenuto principale e quali fattori ne ritardino la visualizzazione.
Tra gli interventi possibili figurano l’ottimizzazione dell’immagine principale, la riduzione dei tempi di risposta del server, la corretta gestione della priorità delle risorse, l’eliminazione di dipendenze inutili e una strategia di caricamento adeguata per font e fogli di stile.
Se l’elemento LCP è un’immagine visibile immediatamente, applicare indiscriminatamente il lazy loading può essere controproducente.
La nuova versione di Lighthouse può aiutare a produrre una diagnosi più accurata, ma non sostituisce l’analisi delle cause reali.
Ridurre il lavoro JavaScript non necessario
Le applicazioni ricche di JavaScript continuano a richiedere attenzione.
Il fatto che Lighthouse 13.6 possa assegnare un punteggio più favorevole a determinate architetture non significa che il JavaScript non utilizzato, le operazioni lunghe sul thread principale o le dipendenze eccessive abbiano smesso di influenzare la navigazione.
Ridurre il codice eseguito, suddividere le attività costose e limitare le risorse di terze parti possono contribuire a migliorare la reattività.
Intervenire sui problemi di INP
Un sito può caricarsi rapidamente e rispondere lentamente alle interazioni degli utenti.
L’INP consente di osservare proprio questo aspetto.
Menu complessi, filtri di ricerca, configuratori, carrelli e interfacce molto dinamiche possono risentire di operazioni JavaScript che ritardano l’aggiornamento visivo dopo un’interazione.
Per questo il miglioramento del caricamento iniziale non deve far dimenticare le prestazioni durante l’utilizzo della pagina.
Evitare spostamenti imprevisti del layout
Banner, immagini prive di dimensioni dichiarate, elementi caricati dinamicamente e font possono causare spostamenti dei contenuti.
Questi problemi vengono osservati attraverso il Cumulative Layout Shift.
Anche se il punteggio generale PageSpeed Insights aumenta, un CLS elevato può continuare a compromettere la navigazione e richiede interventi specifici.
Le altre novità di Lighthouse 13.6: audit multipli e Agentic Resource Discovery
La versione 13.6 non si limita alla simulazione delle performance.
Le note di rilascio includono anche modifiche agli strumenti da riga di comando, alla gestione delle risorse e a un audit dedicato all’Agentic Resource Discovery.
Analisi di più URL dalla riga di comando
Lighthouse CLI supporta ora l’esecuzione sequenziale di audit su più URL attraverso un singolo comando o un file contenente gli indirizzi da analizzare.
Questa funzionalità può agevolare chi deve verificare numerose pagine, per esempio un catalogo eCommerce, un insieme di landing page o un gruppo di URL rappresentativi di differenti template.
Il supporto all’opzione --fail-fast permette inoltre di interrompere la sequenza in presenza di un errore.
Non equivale a una scansione SEO completa del sito: rimane un sistema per eseguire audit Lighthouse sugli URL indicati.
Aggiornamento dell’audit Agentic Resource Discovery
Un’altra novità riguarda l’Agentic Resource Discovery (ARD), una proposta di standard per rendere alcune risorse di un sito individuabili da sistemi agentici.
Lighthouse 13.6 aggiorna il relativo audit alla specifica ARD v0.91, nella quale ard.json sostituisce la precedente denominazione ai-catalog.json.
La nuova versione riconosce modalità di discovery come l’header HTTP Link, il tag HTML <link rel="ard"> e il percorso /.well-known/ard.json.
Si tratta di un cambiamento distinto dall’ottimizzazione delle prestazioni.
Non bisogna confondere la presenza di questo audit con un requisito di posizionamento su Google o con una garanzia di visibilità nei motori di ricerca basati sull’intelligenza artificiale.
L’aggiornamento segnala l’evoluzione degli strumenti di auditing verso nuovi meccanismi di discovery, ma non dimostra che adottare ARD produca un beneficio SEO o GEO misurabile.
Domande frequenti su PageSpeed Insights e Lighthouse 13.6
Perché il mio punteggio PageSpeed Insights è aumentato senza modifiche al sito?
Una possibile causa è l’aggiornamento a Lighthouse 13.6, che modifica il sistema di simulazione Lantern. Il nuovo modello può restituire valori FCP e LCP differenti, anche quando il codice e le risorse della pagina non sono cambiati. È comunque necessario verificare la versione del test ed escludere altre cause di variabilità.
Lighthouse 13.6 rende i siti più veloci?
No. L’aggiornamento modifica lo strumento di analisi, non il comportamento delle pagine web pubblicate. Può offrire una stima più accurata di alcune prestazioni simulate, ma non accelera direttamente il caricamento di un sito.
Un punteggio PageSpeed Insights più alto migliora il ranking?
Non automaticamente. Il punteggio Performance di Lighthouse non è di per sé un fattore di ranking. Google utilizza i Core Web Vitals nei suoi sistemi di posizionamento, ma specifica che buoni risultati non garantiscono un ranking elevato.
I Core Web Vitals cambiano con Lighthouse 13.6?
Le metriche calcolate nei test di laboratorio possono variare. I Core Web Vitals rilevati sul campo attraverso CrUX, invece, non vengono ricalcolati in base alla nuova simulazione Lantern. Possono cambiare nel tempo per effetto delle esperienze reali degli utenti.
Devo rifare tutti i test PageSpeed Insights del mio sito?
Non necessariamente. È consigliabile definire una nuova baseline per gli URL strategici, soprattutto quando si utilizzano i punteggi Lighthouse per monitorare l’efficacia delle ottimizzazioni tecniche. I vecchi report rimangono utili, purché venga considerata la discontinuità metodologica.
Lighthouse 13.6 favorisce i siti realizzati con React?
Non esiste un beneficio garantito per React o per altri framework. Le modifiche possono incidere maggiormente sui siti ricchi di JavaScript, ma il risultato dipende dal comportamento specifico della pagina e dal modo in cui il modello simula le sue dipendenze.
È ancora utile cercare di raggiungere 100 su PageSpeed Insights?
Un punteggio elevato può indicare buone prestazioni nelle condizioni del test, ma non dovrebbe diventare un obiettivo isolato. È più utile correggere i problemi che compromettono la navigazione reale e monitorare i Core Web Vitals, soprattutto quando esistono criticità documentate.
Conclusioni: Lighthouse 13.6 cambia il modo di misurare, non le prestazioni del sito
L’aggiornamento a Lighthouse 13.6.0 introduce una modifica significativa per chi utilizza PageSpeed Insights come strumento di monitoraggio delle performance.
La nuova simulazione Lantern cerca di rappresentare più accuratamente il comportamento del browser, migliorando la gestione delle risorse che bloccano il rendering, delle dipendenze JavaScript, delle connessioni di rete e di alcune condizioni particolari legate al Largest Contentful Paint.
Il risultato può essere un aumento dei punteggi di laboratorio anche senza interventi tecnici.
Questa novità non diminuisce l’utilità di PageSpeed Insights, ma richiede maggiore attenzione nell’interpretazione dei dati, soprattutto quando si confrontano report prodotti con versioni differenti di Lighthouse.
Per chi si occupa di SEO, la questione centrale non dovrebbe essere quanti punti abbia guadagnato una pagina, ma se l’esperienza degli utenti sia migliorata e quali evidenze consentano di dimostrarlo.
Un punteggio più alto può essere una buona notizia. Ma prima di attribuirgli un valore strategico bisogna capire che cosa sia cambiato: il sito, lo strumento che lo misura oppure entrambi.
