I Core Web Vitals (CWV) sono diventati nel 2024 un fattore di ranking diretto per Google, e il loro peso nella classificazione delle pagine e-commerce continua ad aumentare nel 2026. Su PrestaShop 8, ottimizzare i CWV è sia un lavoro SEO sia un lavoro di qualità dell’esperienza: un LCP che passa da 4,2 s a 1,8 s significa meccanicamente +20-40% di tasso di conversione mobile secondo gli studi Google e le nostre misurazioni sui negozi accompagnati. Tuttavia, l’ottimizzazione CWV resta poco compresa. La maggior parte dei merchant lancia un Lighthouse, vede un punteggio rosso, installa un modulo di cache generico, e constata che il punteggio non si muove quasi — perché le vere leve non sono nel cache, ma in dettagli tecnici precisi.
Questa checklist illustra le ottimizzazioni CWV che producono realmente risultati su PrestaShop 8 nel 2026, con vero codice PHP e SQL adattato all’architettura PrestaShop, non consigli generici copiati da una documentazione Google.
I 3 Core Web Vitals 2026 e le loro soglie
Google misura tre metriche per valutare la qualità di caricamento e di interazione di una pagina.
LCP (Largest Contentful Paint) misura il tempo trascorso tra l’inizio del caricamento e il rendering del più grande elemento visibile (tipicamente l’immagine principale di una scheda prodotto, o il testo dell’hero di una pagina categoria). Soglie: buono sotto i 2,5 s, da migliorare tra 2,5 e 4 s, cattivo oltre i 4 s.
INP (Interaction to Next Paint) ha sostituito FID a marzo 2024. Misura la latenza tra un’interazione utente (clic, tap, pressione tasto) e il successivo rendering visibile. Soglie: buono sotto i 200 ms, da migliorare tra 200 e 500 ms, cattivo oltre i 500 ms.
CLS (Cumulative Layout Shift) misura gli spostamenti visivi imprevisti durante il caricamento (immagine che spinge il testo, banner che appare in ritardo). Soglie: buono sotto 0,1, da migliorare tra 0,1 e 0,25, cattivo oltre 0,25.
Affinché una pagina passi a “Buona” in Search Console, le tre metriche devono essere nel verde al 75° percentile dei caricamenti reali (il 25% delle visite più lente può essere sopra, ma il 75% più veloce deve essere buono). È questo che rende l’ottimizzazione difficile: il tuo negozio può essere veloce per un visitatore in fibra desktop e catastrofico per un visitatore in 4G degradata su Android entry-level — Google calcola il punteggio sui veri utenti reali (Field Data tramite Chrome User Experience Report).
Misurare i CWV sul tuo negozio: Lab Data vs Field Data
Esistono due tipi di misurazioni da distinguere.
Lab Data (misurazione sintetica). PageSpeed Insights, Lighthouse, WebPageTest. La pagina viene caricata da un bot in un ambiente standardizzato (3G simulato, mobile mid-range). I numeri sono riproducibili ma non riflettono l’esperienza dei tuoi veri visitatori. Utile per la diagnosi e lo sviluppo.
Field Data (misurazioni reali). Chrome User Experience Report (CrUX), accessibile in Search Console > Miglioramenti > Core Web Vitals. Sono i numeri che Google usa per il ranking. Misurazione aggregata dei caricamenti reali dei tuoi visitatori negli ultimi 28 giorni. È la metrica che conta per la SEO.
Il divario tra Lab Data e Field Data può essere enorme: un sito con punteggio Lighthouse di 95 può avere Field Data in rosso se la maggior parte dei suoi visitatori è su dispositivi più lenti del profilo Lighthouse standard. Al contrario, un sito con Lighthouse di 60 può essere corretto in Field Data se la sua audience è principalmente desktop.
Lo strumento da implementare subito. Configura il Real User Monitoring (RUM) sul tuo negozio. Diverse opzioni gratuite: la libreria web-vitals di Google che si integra in poche righe di JS e invia le misurazioni a GA4, o strumenti come Cloudflare Web Analytics, SpeedCurve, Calibre. Le misurazioni RUM sono le più fedeli a ciò che vede Google, e permettono di segmentare per tipo di dispositivo, per paese, per browser — il che rivela dove sono i tuoi veri problemi.
LCP: le ottimizzazioni che funzionano davvero
L’LCP è generalmente la metrica più impattante lato business su PrestaShop, perché riguarda direttamente la percezione di velocità al caricamento di una scheda prodotto. Ecco le leve in ordine di impatto tipico.
1. Identificare precisamente l’LCP element
Prima di tutto, identifica quale elemento attiva l’LCP sulle tue pagine chiave. Lighthouse lo indica nel suo report, ma lo strumento più preciso è l’estensione Chrome Web Vitals Extension che evidenzia in tempo reale l’LCP element su qualsiasi pagina. Su una scheda prodotto PrestaShop, l’LCP è quasi sempre l’immagine principale del prodotto. Su una categoria, è generalmente la prima immagine visibile della griglia prodotto. Sulla home, è l’hero/slider.
Una volta identificato, è questo LCP element che bisogna prioritizzare nell’ottimizzazione — precaricamento, conversione in formato moderno, dimensionamento, lazy loading disattivato.
2. Precaricamento dell’immagine LCP
Sulle schede prodotto, aggiungere un <link rel="preload"> nell’head per l’immagine principale del prodotto fa guadagnare 200-500 ms sull’LCP, perché il browser avvia il download dell’immagine ancor prima di aver parsato l’HTML che la contiene.
Implementazione nel template Twig della scheda prodotto (themes/tuo-tema/templates/catalog/product.tpl in Smarty, o il file equivalente in Twig per i temi moderni):
{if isset($product.cover.bySize.large_default.url)}
<link rel="preload" as="image"
href="{$product.cover.bySize.large_default.url}"
imagesrcset="..." imagesizes="..." fetchpriority="high">
{/if}L’attributo fetchpriority="high" è importante — indica al browser che questa risorsa è critica e deve passare davanti alle altre nella coda di download.
3. Conversione WebP / AVIF con dimensioni corrette
Servire le tue immagini prodotto in WebP riduce il loro peso del 25-35% rispetto a JPEG con qualità visiva equivalente. AVIF risparmia un altro 20% ma con una decodifica leggermente più costosa lato browser — il compromesso del 2026 resta WebP in maggioranza, AVIF per le hero image critiche.
Su PrestaShop 8, diversi moduli fanno la conversione automatica (il nativo PrestaShop ha un’opzione WebP basica, moduli terzi fanno meglio con AVIF e compressione adattiva). Verifica anche che le dimensioni servite corrispondano alla visualizzazione reale: servire un’immagine 2000×2000 visualizzata in 400×400 spreca larghezza di banda e aumenta l’LCP. Usa srcset per proporre diverse dimensioni in base al viewport.
4. TTFB e query SQL server
L’LCP è limitato in basso dal TTFB (Time To First Byte): finché il tuo server non ha iniziato a inviare HTML, il browser non può renderizzare nulla. Su PrestaShop, il TTFB può essere appesantito da query SQL non ottimizzate in hook pesanti.
L’audit da fare: attivare il profiling PrestaShop (Configurazione > Performance > attivare modalità debug + profiler) e guardare la scheda Database. Se vedi una query che si esegue 50 volte per caricamento di pagina prodotto con un tempo cumulato di 200 ms, è probabilmente una N+1 query in un modulo mal codificato. Il modulo in questione deve essere patchato o disattivato.
I moduli più frequentemente colpevoli sui negozi che verifichiamo: moduli di recensioni che interrogano la nota media per ogni prodotto visualizzato senza cache, moduli di related products che fanno una query per prodotto raccomandato, moduli di stock che calcolano la disponibilità ad ogni visualizzazione prodotto. La nostra categoria Performance & Core Web Vitals copre diversi di questi pattern.
INP: il killer di performance moderno (e il più mal compreso)
L’INP ha sostituito FID a marzo 2024 ed è ormai la metrica più difficile da ottimizzare su PrestaShop. La ragione: FID misurava solo la prima interazione, INP misura tutte le interazioni e mantiene il peggior 98° percentile. Quindi una singola interazione lenta su 50 (ad esempio un clic su un filtro categoria che si blocca per 500 ms) pesa più di 49 interazioni rapide.
1. Identificare le interazioni lente
L’estensione Chrome Web Vitals Extension mostra l’INP in tempo reale durante la navigazione. Clicca ovunque sul tuo negozio (filtri, aggiunta al carrello, popup, accordion FAQ, swiper prodotto) e guarda quali interazioni superano i 200 ms. Su PrestaShop, i colpevoli tipici sono:
- i filtri di categoria (faceted search) che ricaricano l’intera griglia in AJAX;
- le aggiunte al carrello che attivano hook pesanti;
- le aperture di modale prodotto (Quick View);
- i cambi di variante prodotto (colore, taglia).
2. Long task e yield al main thread
Un’interazione lenta è quasi sempre causata da una “long task” JavaScript (una funzione che blocca il main thread per più di 50 ms). Il browser non può rispondere ai clic successivi finché la long task non è finita.
La soluzione moderna: spezzettare le long task con scheduler.yield() (API nativa nei Chromium recenti) o con un pattern setTimeout(fn, 0) per restituire il controllo al browser tra i pezzi di calcolo. Esempio: se hai un ciclo che elabora 1000 prodotti lato front, spezzettalo in chunk di 50 con uno yield tra ogni chunk.
async function processProducts(products) {
for (let i = 0; i < products.length; i += 50) {
const chunk = products.slice(i, i + 50);
chunk.forEach(processProduct);
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise(r => setTimeout(r, 0));
}
}
}3. Debounce e throttle sugli input
Sui filtri di ricerca, sui select di variante, sugli input di quantità, non attivare l’AJAX a ogni keypress. Debounce di 200-300 ms prima dell’invio della richiesta. Senza questo dettaglio, un visitatore che digita rapidamente genera 10 richieste AJAX che tutte saturano il main thread.
4. Code splitting JS e caricamento differito
Molti moduli PrestaShop caricano il loro JS su tutte le pagine mentre vengono usati solo su alcune (un modulo Quick View che carica sulla home, un modulo FAQ che carica sulle schede categoria). Verifica il tuo front/controllers/... e usa $this->context->controller->registerJavascript() con il controller giusto come parametro per limitare il caricamento alle pagine dove il JS è necessario.
Per le funzionalità davvero pesanti (uno slider Swiper, un editor WYSIWYG), carica il JS in lazy tramite import() dinamico al momento della prima interazione, non al caricamento della pagina.
CLS: la stabilità visiva
Il CLS è generalmente la metrica più facile da correggere su PrestaShop, perché le cause sono poche e ben note.
1. Riserva di spazio per le immagini. Ogni immagine nell’HTML deve avere attributi width e height espliciti (o un aspect-ratio CSS). Senza questo, l’immagine fa variare il layout quando viene caricata. Su PrestaShop, le immagini prodotto generate dagli hook displayProduct... devono tutte avere le loro dimensioni. Verifica il tuo codice di tema: ogni <img src="..." /> senza width e height è sospetto.
2. Web font e FOIT/FOUT. Se usi Google Fonts o font custom, il browser può mostrare testo invisibile (FOIT) e poi passare bruscamente (FOUT) quando il font arriva — il che sposta tutto il contenuto. Soluzione: font-display: optional nel CSS per i font secondari, e font-display: swap con un fallback metricamente compatibile (usa size-adjust CSS per abbinare il font fallback al font custom ed eliminare lo shift).
3. Banner e popup differiti. I banner cookie, popup newsletter, top bar che appaiono 1-3 secondi dopo il caricamento sono fonti frequenti di CLS. Soluzione: riserva lo spazio in CSS fin dall’inizio (con min-height) se sai che il banner apparirà, o fai apparire il banner in overlay (position fixed/absolute) che non sposta il contenuto esistente.
4. Iframe esterni ed embed. Gli iframe YouTube, Vimeo, Calendly che caricano in differita spostano il contenuto. Riserva sistematicamente il loro spazio con un wrapper in aspect-ratio: 16/9 o equivalente.
Ottimizzazioni SQL e database specifiche PrestaShop
Su PrestaShop, una parte importante del TTFB (e quindi dell’LCP) viene dalle query SQL. Ecco i pattern da conoscere.
Profiling con EXPLAIN
Quando il profiler PrestaShop rivela una query lenta (più di 50 ms), passala in MySQL con EXPLAIN per capire cosa succede. Se vedi un type: ALL con un grande numero di righe scansionate, manca probabilmente un indice. Se vedi Using filesort o Using temporary, la query fa lavoro inutile e deve essere riscritta.
Indici mancanti tipici su PrestaShop
Sui negozi con un grande catalogo (5000+ prodotti) e molti moduli terzi, certi indici spesso mancano. I pattern che vediamo in audit:
- Indice mancante su
id_product, id_shopnelle tabelle custom dei moduli; - Indice mancante sulle colonne usate per i filtri di categoria (faceted search);
- Indice mancante su
id_order, date_addper le query di statistiche ordini.
Aggiungi gli indici mancanti direttamente in SQL tramite PhpMyAdmin o tramite una migrazione di modulo. Misura prima/dopo — un solo indice ben posizionato può dividere un tempo di query per 50.
N+1 query negli hook
Il pattern più distruttivo in performance PrestaShop: un hook che si esegue per ogni prodotto visualizzato e che fa una query SQL per prodotto. Su una categoria che mostra 24 prodotti, sono 24 query aggiuntive per caricamento.
Rilevamento: profiler PrestaShop > Database. Se vedi la stessa query ripetuta N volte con parametri diversi, è una N+1.
Soluzione: modificare il modulo per fare batching delle query. Invece di fare una query per prodotto nell’hook displayProductMiniature, il modulo deve raccogliere tutti gli ID prodotti tramite actionProductListBefore e fare una singola query WHERE id_product IN (1, 2, 3, ...) che riporta tutti i risultati in una volta.
Cache PrestaShop: Smarty + cache modulo
Su PrestaShop 8, due livelli di cache si completano. Il cache Smarty (compila i template in PHP) è usato in produzione: verifica SMARTY_CONSOLE_FORCE_COMPILE = 0 e SMARTY_CACHE = 1 in config/defines.inc.php. Il cache modulo (cache custom nei moduli) è più potente: un modulo ben codificato mette in cache i suoi calcoli pesanti e non li rifà finché i dati non cambiano. Se un modulo ricalcola la stessa cosa ad ogni pagina, è un bug da correggere.
Sui negozi con molto traffico, aggiungi anche un cache HTTP (Varnish, o cache LiteSpeed lato hosting) che serve le pagine prodotto pre-renderizzate senza nemmeno raggiungere PrestaShop. Questo divide il TTFB per 10 sulle richieste ripetute e libera il server per le richieste veramente dinamiche.
L’insidia dei moduli terzi
Sui negozi che verifichiamo, il 60-80% dei problemi CWV viene da moduli terzi mal codificati. Il pattern è sempre lo stesso: un modulo installato per una funzionalità utile (chat live, popup newsletter, badge fedeltà, social proof) carica un JS pesante su tutte le pagine, appesantisce l’LCP e l’INP, e nessuno fa il collegamento.
L’audit da fare regolarmente:
- Disattiva tutti i moduli terzi e lancia Lighthouse → questa è la tua baseline “PrestaShop puro”.
- Riattiva i moduli uno per uno rilanciando Lighthouse ogni volta.
- Identifica i moduli che fanno saltare il punteggio di oltre 5 punti → sono i tuoi colpevoli.
- Per ogni colpevole: o trovi un’impostazione che lo rende più leggero, o lo sostituisci con un’alternativa meglio codificata, o decidi che la funzionalità non vale il degrado.
Criterio di scelta di un nuovo modulo nel 2026: prima di installare, verifica che il modulo carichi i suoi asset solo sulle pagine dove viene usato (non su tutte le pagine), che faccia SQL batchato (no N+1), che proponga un cache configurabile, e che abbia un changelog recente (un modulo non mantenuto da 18 mesi su PrestaShop 8 è sospetto).
Diversi moduli del nostro catalogo sono stati sviluppati con questi vincoli in mente, come il modulo DataFirefly SideCart che carica il suo JS solo sulle pagine dove si visualizza, o il modulo DataFirefly Cross-Sell i cui analytics partono in AJAX fuori dal percorso critico per non impattare l’LCP — argomento affrontato nel nostro articolo sul cross-sell che contribuisce al carrello medio.
Conclusione: un lavoro continuo, non un progetto puntuale
L’ottimizzazione Core Web Vitals su PrestaShop 8 è raramente un lavoro di pochi giorni che si fa una volta e si dimentica. È un lavoro continuo: ogni nuovo modulo aggiunto può rompere il punteggio, ogni aggiornamento PrestaShop può introdurre regressioni, ogni evoluzione di Google (l’arrivo di INP a marzo 2024 ad esempio) può ridistribuire le priorità.
Il riflesso giusto è implementare un monitoraggio permanente (Search Console + RUM tramite web-vitals.js + GA4) e controllare le metriche di routine, non solo quando un problema diventa visibile. Un degrado rilevato in settimana 1 si corregge in poche ore; lo stesso degrado rilevato in settimana 8, dopo che hai aggiunto altri tre moduli nell’intervallo, diventa un audit completo di diversi giorni.
Per approfondire, sfoglia le nostre categorie Performance & Core Web Vitals e Tutorial PrestaShop per gli argomenti tecnici correlati. E se identifichi moduli del tuo stack attuale che appesantiscono i CWV senza apportare valore corrispondente, diversi moduli del nostro catalogo sono stati pensati per essere performance-first by design — il SideCart, il Cross-Sell, e l’intera gamma DataFirefly condividono lo stesso impegno: nessun JS sulle pagine dove il modulo non è visualizzato, nessuna N+1, nessuna dipendenza esterna inutile.