Audit Google Lighthouse per PrestaShop: Interpretare ogni punteggio

Cosa misura Google Lighthouse

Google Lighthouse è uno strumento di audit automatizzato integrato in Chrome DevTools che valuta le pagine web in quattro categorie principali: Prestazioni, Accessibilità, Best Practice e SEO. Ogni categoria produce un punteggio da 0 a 100, e ogni punteggio viene calcolato da metriche e controlli specifici con pesi differenti. Comprendere cosa questi punteggi significano realmente per un negozio PrestaShop — e quali sono gli obiettivi realistici — è essenziale prima di dedicare tempo all'ottimizzazione.

Lighthouse funziona in due ambienti. I dati di laboratorio (lab data) provengono da un ambiente simulato con throttling di rete controllato e rallentamento della CPU. I dati sul campo (field data) provengono da utenti reali attraverso il Chrome User Experience Report (CrUX). I punteggi che vedi eseguendo Lighthouse in Chrome DevTools sono dati di laboratorio. I punteggi che Google usa per il ranking (Core Web Vitals) provengono dai dati sul campo. Questa distinzione è importante perché i risultati di laboratorio e sul campo spesso differiscono significativamente, e ottimizzare per uno non sempre migliora l'altro.

Per i negozi PrestaShop, Lighthouse è particolarmente rivelatore perché la configurazione predefinita di PrestaShop e la maggior parte dei temi non sono ottimizzati per gli standard di prestazione moderni. Un tipico negozio PrestaShop non ottimizzato ottiene tra 15 e 40 nelle Prestazioni, da 60 a 80 nell'Accessibilità, da 70 a 85 nelle Best Practice e da 75 a 90 nel SEO. Questi punteggi di base indicano dove risiedono le maggiori opportunità di miglioramento.

Punteggio Prestazioni: La categoria più complessa

Il punteggio Prestazioni è un composto pesato di sei metriche. Ogni metrica cattura un aspetto diverso della velocità di caricamento e dell'interattività della pagina. Comprendere le metriche individuali è molto più utile che concentrarsi sul numero complessivo.

Largest Contentful Paint (LCP)

LCP misura quando il più grande elemento di contenuto visibile finisce il rendering. Su una pagina prodotto PrestaShop, questo è solitamente l'immagine principale del prodotto. Su una pagina di categoria, potrebbe essere la prima immagine prodotto o un banner di categoria. Google considera LCP buono quando è sotto 2,5 secondi, necessita miglioramento tra 2,5 e 4 secondi, e scarso sopra 4 secondi.

I problemi di LCP specifici di PrestaShop includono immagini prodotto sovradimensionate servite senza un corretto dimensionamento responsivo, CSS che blocca il rendering da moduli che si caricano su ogni pagina, tempi di risposta del server rallentati da query di database non ottimizzate (specialmente nelle pagine di categoria con molti prodotti), e JavaScript di moduli di terze parti che ritarda la pipeline di rendering.

Per migliorare LCP su PrestaShop, inizia con l'ottimizzazione delle immagini. Assicurati che le immagini dei prodotti siano correttamente dimensionate per ogni contesto (non servire un'immagine 2000x2000 quando l'area di visualizzazione è 400x400). Abilita il lazy loading per le immagini sotto la piega (below-the-fold) ma assicurati che l'immagine LCP NON sia lazy loaded, poiché questo ritarda il suo rendering. Implementa hint di preload per l'immagine LCP usando un tag <link rel="preload"> nell'header della pagina. Sul lato server, abilita OPcache, configura il caching delle query MySQL e assicurati che il tuo hosting abbia risorse adeguate.

Cumulative Layout Shift (CLS)

CLS misura la stabilità visiva. Ogni volta che un elemento visibile cambia posizione dopo il rendering iniziale, contribuisce al punteggio CLS. Google considera CLS buono quando è sotto 0,1, necessita miglioramento tra 0,1 e 0,25, e scarso sopra 0,25.

I negozi PrestaShop soffrono comunemente di CLS causato da immagini che si caricano senza dimensioni definite (il browser non sa quanto spazio riservare, quindi il contenuto salta quando l'immagine si carica), web font che si caricano causando il reflow del testo (FOUT, Flash of Unstyled Text), banner o barre di notifica iniettati dinamicamente da moduli, banner di consenso cookie che spingono il contenuto della pagina verso il basso, e immagini prodotto caricate lazy in griglie che spostano i prodotti circostanti quando appaiono.

Correggere CLS in PrestaShop richiede l'impostazione di attributi espliciti width e height su tutte le immagini (o l'uso di CSS aspect-ratio), il preloading di web font critici con font-display: swap o font-display: optional, la riserva di spazio per elementi dinamici come i banner cookie usando CSS min-height, e l'assicurarsi che i moduli pubblicitari o promozionali iniettino contenuto senza spostare gli elementi esistenti.

First Contentful Paint (FCP)

FCP misura quando il primo pezzo di contenuto appare sullo schermo. Questo potrebbe essere testo, un'immagine, un SVG o un elemento canvas. Per PrestaShop, FCP è fortemente influenzato dal tempo necessario al server per rispondere (Time to First Byte) e dalla quantità di risorse che bloccano il rendering (CSS e JavaScript) che devono essere scaricate prima che il browser possa dipingere qualcosa.

La configurazione predefinita di PrestaShop carica una quantità significativa di CSS e JavaScript in modo sincrono nell'head di ogni pagina. Ogni modulo installato può aggiungere i propri file CSS e JavaScript. Un negozio con 30 moduli potrebbe caricare da 15 a 25 file CSS separati e da 20 a 30 file JavaScript prima che qualsiasi contenuto appaia. Questo aumenta direttamente FCP.

Total Blocking Time (TBT)

TBT misura il tempo totale tra FCP e Time to Interactive in cui il thread principale è stato bloccato abbastanza a lungo da impedire la reattività all'input. Qualsiasi task più lungo di 50 millisecondi ha il suo tempo in eccesso contato nel TBT. Ad esempio, un task di 200 millisecondi contribuisce 150 millisecondi al TBT.

I negozi PrestaShop sono noti per valori TBT elevati. I colpevoli comuni includono jQuery e i suoi plugin eseguiti in modo sincrono, JavaScript di moduli che esegue pesanti manipolazioni DOM al caricamento della pagina, codice di analytics e tracking da più moduli, script di pagine prodotto che inizializzano slider, funzionalità di zoom e selettori di combinazioni simultaneamente, e widget di chat e embed di social media.

Ridurre TBT richiede il differimento del JavaScript non critico, la suddivisione di task lunghi in chunk asincroni più piccoli, la rimozione di JavaScript non utilizzato dei moduli e il caricamento di widget di terze parti dopo che la pagina è diventata interattiva.

Speed Index

Speed Index misura quanto velocemente l'area visibile della pagina viene popolata. Cattura la progressione visiva complessiva del caricamento della pagina. Una pagina dove l'header, la navigazione e la prima riga di prodotti appaiono rapidamente ma il resto si carica gradualmente avrà uno Speed Index migliore di una pagina dove tutto appare in una volta dopo un lungo ritardo.

Per PrestaShop, Speed Index migliora quando dai priorità al rendering del contenuto above-the-fold. Questo significa fare l'inline del CSS critico (il CSS necessario per renderizzare la porzione visibile della pagina senza scrolling), differire le immagini below-the-fold e evitare JavaScript che blocca il rendering del contenuto visibile.

Interaction to Next Paint (INP)

INP ha sostituito First Input Delay (FID) come Core Web Vital nel marzo 2024. Misura la reattività di una pagina durante tutto il suo ciclo di vita, non solo la prima interazione. Ogni clic, tap e pressione di tasto viene misurata, e la peggiore latenza di interazione (approssimativamente) diventa il valore INP. Google considera INP buono sotto 200 millisecondi.

I negozi PrestaShop spesso hanno INP scadente sulle pagine prodotto dove il clic su un attributo di combinazione attiva una richiesta AJAX sincrona che blocca l'interfaccia, sulle pagine di categoria dove i clic sui filtri a faccette causano pesante elaborazione JavaScript, e su qualsiasi pagina dove il JavaScript di un modulo monopolizza il thread principale durante l'interazione dell'utente.

Punteggio Accessibilità

Il punteggio Accessibilità valuta se la tua pagina può essere utilizzata da persone con disabilità, inclusi coloro che usano screen reader, navigazione da tastiera o altre tecnologie assistive. Lighthouse controlla specifici elementi di conformità WCAG 2.1 e assegna a ciascuno un peso basato sull'impatto sull'utente.

Problemi comuni di Accessibilità in PrestaShop

Il testo alt mancante sulle immagini è il problema più frequente. I negozi PrestaShop con migliaia di prodotti spesso hanno prodotti caricati senza descrizioni di testo alt. Lighthouse segnala ogni immagine senza attributo alt. La soluzione è aggiungere testo alt significativo a tutte le immagini prodotto attraverso il back office, il che beneficia anche il SEO.

Il contrasto colori insufficiente è estremamente comune nei temi PrestaShop. Il designer del tema potrebbe aver scelto colori visivamente attraenti ma che non soddisfano il rapporto di contrasto minimo WCAG di 4.5:1 per il testo normale e 3:1 per il testo grande. I problemi tipici includono testo grigio chiaro su sfondo bianco (spesso usato per prezzi prodotto, descrizioni o link nel footer), testo bianco su pulsanti colorati dove il colore non è abbastanza scuro, e testo placeholder nei campi di ricerca.

Le etichette di form mancanti influenzano i form di ricerca, di iscrizione alla newsletter e di contatto di PrestaShop. Molti temi usano il testo placeholder come unica indicazione dello scopo di un campo di input, ma i placeholder non sono etichette accessibili. Ogni input deve avere un elemento <label> associato.

La gerarchia degli heading non corretta è comune quando i temi saltano i livelli di heading (passando da <h1> a <h3>) o quando i moduli iniettano contenuto con livelli di heading che rompono l'outline del documento della pagina.

Gli attributi ARIA mancanti sugli elementi interattivi come menu dropdown, finestre modali e interfacce a tab significano che gli screen reader non possono trasmettere lo scopo e lo stato di questi elementi agli utenti.

Obiettivi realistici di Accessibilità

La maggior parte dei temi PrestaShop con impegno può raggiungere da 85 a 95. Un 100 perfetto è raggiungibile ma richiede modifiche ai template del tema, che potrebbero essere sovrascritte durante gli aggiornamenti. Concentrati prima sugli elementi a più alto impatto: testo alt delle immagini, contrasto colori, etichette dei form e navigazione da tastiera per i flussi utente principali (navigazione, aggiungi al carrello, checkout).

Punteggio Best Practice

La categoria Best Practice copre i segnali generali di qualità nello sviluppo web: utilizzo di HTTPS, evitamento di API deprecate, assenza di errori in console e header di sicurezza.

Problemi comuni di Best Practice in PrestaShop

Gli errori nella console del browser sono segnalati da Lighthouse. I negozi PrestaShop hanno frequentemente errori JavaScript da conflitti tra moduli, chiamate a funzioni jQuery deprecate o richieste AJAX fallite. Ogni errore in console riduce il punteggio Best Practice. Controlla la console del browser su ogni tipo di pagina (homepage, categoria, prodotto, carrello, checkout) e correggi o sopprimi gli errori.

Gli header di sicurezza mancanti riducono il punteggio. PrestaShop non imposta per default header come Content-Security-Policy, X-Content-Type-Options, Permissions-Policy o Referrer-Policy. Aggiungerli tramite il tuo .htaccess o la configurazione del server web migliora il punteggio Best Practice e la postura di sicurezza del tuo sito.

Le API deprecate generano avvisi quando temi o moduli PrestaShop più vecchi usano API JavaScript che i browser hanno deprecato. Esempi comuni includono document.write(), XMLHttpRequest sincrono e il listener dell'evento unload. Questi si trovano tipicamente in moduli più vecchi che non sono stati aggiornati per gli standard dei browser moderni.

Il contenuto misto (caricare risorse HTTP su una pagina HTTPS) viene segnalato severamente. Questo succede quando asset di moduli, font esterni o pixel di tracking usano URL HTTP. Assicurati che tutte le risorse si carichino su HTTPS.

Le immagini senza larghezza e altezza esplicite (che influenza anche CLS nelle Prestazioni) vengono segnalate anche qui. I temi PrestaShop che usano solo CSS per il dimensionamento delle immagini senza impostare attributi HTML attivano questo controllo.

Obiettivi realistici di Best Practice

Un negozio PrestaShop ben mantenuto dovrebbe puntare da 90 a 100. La maggior parte dei problemi di Best Practice è semplice da correggere tramite configurazione del server e pulizia dei moduli.

Punteggio SEO

L'audit SEO verifica i requisiti tecnici SEO di base. Questa è la categoria più facile in cui ottenere un buon punteggio perché i controlli sono semplici e PrestaShop ne gestisce molti per default.

Cosa controlla Lighthouse per il SEO

L'audit verifica che la pagina abbia un tag <title> valido, una meta description, un meta tag viewport valido, che i link abbiano testo descrittivo (non solo "clicca qui"), che la pagina non sia bloccata dall'indicizzazione, che le immagini abbiano attributi alt, che il documento abbia un hreflang valido se serve più lingue, che la dimensione del font sia leggibile su mobile e che i target touch (pulsanti, link) siano adeguatamente dimensionati e spaziati.

Problemi SEO comuni in PrestaShop

Le meta description mancanti o duplicate sono comuni sulle pagine di categoria, specialmente quelle auto-generate. PrestaShop permette di impostare meta description per categoria e per prodotto, ma molti proprietari di negozi lasciano questi campi vuoti durante le importazioni massive di prodotti.

Il testo dei link non descrittivo appare quando i temi usano testo generico come "Leggi di più" o "Dettagli" per i link ai prodotti senza contesto aggiuntivo. Sia gli screen reader che Lighthouse segnalano questi.

I target touch piccoli influenzano gli utenti mobile. I temi PrestaShop con griglie prodotto compatte su mobile possono avere link e pulsanti troppo vicini tra loro o troppo piccoli. Google raccomanda un target touch minimo di 48x48 pixel CSS con almeno 8 pixel di spaziatura tra target adiacenti.

Le risorse bloccate possono far sì che Lighthouse segnali che file JavaScript o CSS sono inaccessibili. Questo succede quando robots.txt blocca l'accesso alle directory degli asset. Il robots.txt predefinito di PrestaShop a volte blocca directory che contengono file CSS o JavaScript necessari per il rendering.

Obiettivi SEO realistici

Un negozio PrestaShop dovrebbe puntare da 90 a 100 nell'audit SEO. La maggior parte degli elementi sono semplici correzioni di configurazione. L'unica sfida persistente è il testo alt delle immagini sui negozi con grandi cataloghi e importazioni storiche che hanno saltato il testo alt.

Dati di laboratorio vs. dati sul campo

Comprendere la differenza tra dati di laboratorio e sul campo è critico per interpretare correttamente i risultati di Lighthouse e dare priorità al lavoro di ottimizzazione.

Dati di laboratorio (Lighthouse)

Quando esegui Lighthouse da Chrome DevTools o dalla riga di comando, crea un ambiente simulato. Limita la connessione di rete (tipicamente a una velocità 4G lenta di circa 1,6 Mbps con 150ms di latenza) e rallenta la CPU (tipicamente rallentamento 4x). Questo ambiente simulato produce risultati coerenti e riproducibili ma non riflette l'esperienza di nessun utente reale specifico.

I dati di laboratorio sono utili per il debug di problemi specifici, il confronto prima e dopo le modifiche di ottimizzazione e l'identificazione di colli di bottiglia specifici nel processo di caricamento. Ma i punteggi non dovrebbero essere presi come rappresentazione dell'esperienza utente reale.

Dati sul campo (CrUX)

Il Chrome User Experience Report (CrUX) raccoglie dati di prestazione reali dagli utenti Chrome che hanno aderito alla segnalazione delle statistiche di utilizzo. Questi dati sono aggregati al 75° percentile, il che significa che il valore riportato rappresenta l'esperienza del 75% degli utenti che si trovano a quel livello o migliore di quella soglia.

I dati sul campo sono ciò che Google utilizza effettivamente per i segnali di ranking attraverso i Core Web Vitals. Puoi visualizzare i tuoi dati sul campo in Google Search Console nel report Core Web Vitals, in PageSpeed Insights (che mostra sia dati di laboratorio che sul campo) e attraverso l'API CrUX o il dataset BigQuery.

Perché i punteggi differiscono

I punteggi di laboratorio sono tipicamente più bassi dei punteggi sul campo per i negozi PrestaShop perché Lighthouse usa un throttling aggressivo. Un negozio su un server veloce con CDN potrebbe ottenere 35 nella modalità laboratorio di Lighthouse ma avere metriche sul campo perfettamente accettabili perché gli utenti reali su connessioni decenti sperimentano il negozio molto più velocemente dell'ambiente simulato 4G lento. Al contrario, i negozi con problemi che si manifestano solo in condizioni reali (errori JavaScript da versioni specifiche di browser, rallentamenti di widget di terze parti o latenza geografica per utenti lontani dal server) possono avere punteggi di laboratorio migliori di quelli sul campo.

Cosa prioritizzare

Per scopi di ranking Google, dai priorità ai dati sul campo e ai Core Web Vitals (LCP, INP, CLS). Per il debug e il lavoro di ottimizzazione da sviluppatore, usa i dati di laboratorio perché sono coerenti e forniscono informazioni diagnostiche dettagliate. Se i tuoi dati sul campo mostrano Core Web Vitals positivi ma il tuo punteggio Prestazioni di laboratorio è 40, i tuoi utenti stanno bene e Google non ti penalizzerà. Se il tuo punteggio di laboratorio è 90 ma i dati sul campo mostrano Core Web Vitals negativi, hai un problema che il test di laboratorio non sta catturando.

Obiettivi di punteggio realistici per PrestaShop

Impostare obiettivi realistici previene lo spreco di sforzi nel rincorrere rendimenti decrescenti. Ecco obiettivi raggiungibili per un tipico negozio PrestaShop 1.7 o 8.x.

Prestazioni: da 50 a 75 (Mobile), da 80 a 95 (Desktop)

Punteggi Prestazioni mobile sopra 75 sono estremamente difficili per negozi PrestaShop con pagine prodotto ricche, molteplici moduli e contenuto dinamico. La simulazione mobile con throttling è severa. Un punteggio da 50 a 65 su mobile con Core Web Vitals positivi nei dati sul campo è un buon risultato. Punteggi desktop da 85 a 95 sono raggiungibili con ottimizzazioni standard.

Non rincorrere un punteggio Prestazioni mobile di 100. Lo sforzo richiesto per passare da 70 a 100 su mobile tipicamente comporta la rimozione di funzionalità di cui il tuo negozio ha bisogno (zoom immagini prodotto, aggiornamenti dinamici del carrello, selettori di combinazioni). Concentrati invece sul superamento delle soglie Core Web Vitals nei dati sul campo.

Accessibilità: da 85 a 95

Questo range è raggiungibile con correzioni ai template del tema e disciplina nei contenuti. Lo sforzo continuo principale è assicurarsi che tutti i nuovi prodotti abbiano testo alt e che eventuali nuovi moduli non introducano regressioni di accessibilità.

Best Practice: da 90 a 100

Raggiungibile con la configurazione del server, la pulizia degli errori in console e il mantenimento dei moduli aggiornati. Questo punteggio tende a degradarsi nel tempo con l'aggiunta di nuovi moduli, quindi il monitoraggio regolare è utile.

SEO: da 90 a 100

Il più facile da raggiungere e mantenere. La maggior parte degli elementi sono correzioni di configurazione una tantum.

Checklist di miglioramento azionabile

Questa checklist prioritizza le ottimizzazioni per impatto, iniziando dalle modifiche che producono i maggiori miglioramenti di punteggio con il minor sforzo.

Alto impatto, basso sforzo

Abilita la funzionalità CCC (Combine, Compress, Cache) di PrestaShop nelle impostazioni Prestazioni per unire e minimizzare i file CSS e JavaScript. Aggiungi attributi width e height a tutte le immagini nei template del tema. Imposta dimensioni esplicite sulle immagini dei prodotti. Abilita il browser caching attraverso header di cache appropriati nella configurazione del server. Comprimi le risorse testuali con Gzip o Brotli. Rimuovi o disabilita i moduli che non stai usando attivamente. Aggiungi header di sicurezza alla configurazione del server.

Alto impatto, medio sforzo

Implementa l'inlining del CSS critico per il contenuto above-the-fold. Differisci il JavaScript non critico con l'attributo defer o async. Ottimizza e dimensiona correttamente le immagini dei prodotti (servi dimensioni diverse per contesti diversi usando srcset). Precarica le risorse critiche (immagine LCP, file font primari). Correggi tutti gli errori nella console del browser. Aggiungi il testo alt mancante a tutte le immagini di prodotti e categorie.

Medio impatto, sforzo maggiore

Implementa un CDN per asset statici e immagini. Passa a un tema PrestaShop più orientato alle prestazioni se il tuo tema attuale è fondamentalmente lento. Ottimizza le prestazioni lato server (indici del database, OPcache, Redis per il caching). Implementa il serving di immagini WebP con fallback JPEG. Audita e ottimizza il JavaScript dei moduli di terze parti per il blocco del thread principale.

Monitoraggio nel tempo

Un audit Lighthouse una tantum è meno prezioso del monitoraggio regolare. I punteggi cambiano man mano che aggiungi prodotti, installi moduli, aggiorni temi e modifichi configurazioni. Configura test Lighthouse automatizzati usando strumenti come l'API Google PageSpeed Insights, web.dev Measure o Lighthouse CI self-hosted. Esegui test almeno settimanalmente e dopo qualsiasi modifica significativa al negozio.

Traccia sia i punteggi complessivi che le metriche individuali. Un calo del punteggio Prestazioni da 65 a 55 è preoccupante, ma sapere che è stato causato da una regressione CLS da un modulo banner appena installato è azionabile. Senza il tracciamento a livello di metrica, stai indovinando le cause.

Presta particolare attenzione ai Core Web Vitals in Google Search Console. Google aggiorna questi dati mensilmente, e qualsiasi regressione da "Buono" a "Necessita miglioramento" o "Scarso" può influenzare il tuo ranking nei risultati di ricerca. Configura avvisi per i cambiamenti dei Core Web Vitals in modo da poter rispondere prima che l'impatto diventi visibile nei dati di traffico.