Consigli PrestaShop FAQ

Perché le migrazioni sono pericolose per la SEO

La migrazione di un negozio PrestaShop è una delle operazioni più rischiose che si possano effettuare dal punto di vista SEO. Che si tratti di spostare il sito su un nuovo server, cambiare dominio, aggiornare da PrestaShop 1.6 a 1.7 o 8.x, oppure ristrutturare i pattern degli URL, ogni migrazione comporta il potenziale rischio di distruggere mesi o anni di posizionamento accumulato nei motori di ricerca.

Il motivo è semplice. Google e gli altri motori di ricerca hanno indicizzato i tuoi URL attuali, assegnato loro autorità e costruito una mappa della struttura del tuo sito. Quando cambi qualcosa riguardo a quegli URL, alla loro struttura o alla loro accessibilità, i motori di ricerca devono rivalutare tutto. Se la transizione viene gestita male, Google interpreta il cambiamento come la scomparsa dei vecchi contenuti e la comparsa di nuovi contenuti non ancora verificati. Il risultato è un calo del posizionamento che può richiedere mesi per essere recuperato, ammesso che il recupero completo avvenga.

La buona notizia è che le migrazioni possono essere effettuate in modo sicuro. Con una pianificazione adeguata, una corretta implementazione dei redirect e un monitoraggio attento, è possibile preservare la stragrande maggioranza del posizionamento durante una migrazione. Questa guida illustra ogni fase del processo, dall'audit SEO iniziale al monitoraggio post-migrazione.

Audit SEO pre-migrazione

Prima di toccare un singolo file di configurazione, è necessario avere un quadro completo dello stato SEO attuale. Questo audit ha due scopi: fornire una base di confronto da utilizzare dopo la migrazione e identificare le pagine più importanti che devono essere gestite con la massima cura.

Scansiona il tuo sito attuale

Utilizza uno strumento di crawling come Screaming Frog, Sitebulb o la versione gratuita di Screaming Frog (limitata a 500 URL) per scansionare l'intero sito. Esporta l'elenco completo degli URL, i relativi codici di stato HTTP, i titoli delle pagine, le meta description, i tag canonical e la struttura dei link interni. Salva questi dati. Ti serviranno dopo la migrazione per verificare che nulla sia andato perso.

Esporta i dati di Google Search Console

Google Search Console è la fonte più affidabile per sapere quali pagine ricevono effettivamente traffico organico. Vai su Rendimento > Risultati di ricerca ed esporta i dati degli ultimi 16 mesi (il massimo disponibile). Presta particolare attenzione a:

Pagine con il maggior numero di clic e impressioni. Queste sono le tue pagine di maggior valore. Un errore di redirect su una qualsiasi di queste pagine avrà un impatto immediato e visibile sul traffico.

Query che generano più traffico. Dopo la migrazione, monitorerai queste query per verificare la stabilità del posizionamento.

Pagine con molte impressioni ma pochi clic. Queste pagine sono vicine a posizionarsi bene e sono particolarmente sensibili alle interruzioni.

Documenta la struttura degli URL

PrestaShop genera gli URL in base alle impostazioni degli URL amichevoli, alla struttura delle categorie e alle configurazioni dei prodotti. Documenta i pattern. Ad esempio, i tuoi URL dei prodotti sono strutturati come /categoria/nome-prodotto.html oppure semplicemente /nome-prodotto.html? Gli URL delle categorie includono gli ID come /3-nome-categoria? Le pagine CMS si trovano in /content/5-nome-pagina?

Comprendere questi pattern è essenziale perché la nuova installazione potrebbe generare strutture URL diverse per impostazione predefinita, e ogni URL modificato necessita di un redirect.

Controlla i backlink esistenti

Utilizza uno strumento di analisi backlink come Ahrefs, Moz o il report Link di Google Search Console per identificare quali siti esterni linkano al tuo negozio e quali pagine specifiche vengono collegate. Queste pagine con backlink portano la maggiore autorità, e perderle significa perdere il valore SEO di ogni backlink che punta ad esse.

Creazione della mappatura degli URL

La mappatura degli URL è il documento più critico dell'intera migrazione. Si tratta di un foglio di calcolo che associa ogni vecchio URL al corrispondente nuovo URL. Ogni singolo URL che ha ricevuto traffico, ha backlink o appare nella tua sitemap deve avere una mappatura.

Generazione dell'elenco degli URL

Combina gli URL provenienti dalla scansione del sito, dall'esportazione di Google Search Console, dal report dei backlink e dalla sitemap XML. Rimuovi i duplicati e ordina per importanza (traffico e valore dei backlink). Il tuo elenco finale dovrebbe includere:

Tutti gli URL dei prodotti. In PrestaShop, questi vengono generati dal nome del prodotto e dalla configurazione degli URL amichevoli. Se stai cambiando la struttura degli URL (ad esempio, rimuovendo le estensioni .html o modificando il formato del percorso delle categorie), ogni URL di prodotto cambierà.

Tutti gli URL delle categorie. Gli URL delle categorie di PrestaShop spesso includono l'ID della categoria, e questo ID potrebbe essere diverso nella nuova installazione se reimporti le categorie.

Tutti gli URL delle pagine CMS. Questi includono la pagina Chi siamo, i termini e le condizioni, la privacy policy e qualsiasi altra pagina di contenuto.

Tutti gli URL di produttori e fornitori, se utilizzi queste funzionalità.

URL paginati per le categorie con molti prodotti.

Creazione della mappatura

Per ogni vecchio URL, determina quale sarà il corrispondente nuovo URL. Se la struttura degli URL non cambia (stesso dominio, stesse impostazioni degli URL amichevoli, stessi ID), molti URL potrebbero corrispondere a se stessi e non sarà necessario alcun redirect. Ma verifica comunque. Anche piccole modifiche come una diversa profondità dell'albero delle categorie o una differenza nella barra finale creano nuovi URL che necessitano di redirect.

Se stai cambiando i pattern degli URL in modo sistematico (ad esempio, rimuovendo tutte le estensioni .html), puoi utilizzare redirect basati su regex invece di mappare ogni singolo URL individualmente. Ma verifica sempre la regex rispetto al tuo elenco effettivo di URL prima di andare online.

Implementazione dei redirect 301

Un redirect 301 comunica ai motori di ricerca che una pagina si è spostata permanentemente in una nuova posizione. Trasferisce la stragrande maggioranza del valore SEO (link equity) dal vecchio URL al nuovo. Questo è il meccanismo che preserva il tuo posizionamento durante una migrazione.

Dove posizionare i redirect

Per PrestaShop su Apache, i redirect vanno nel file .htaccess nella document root. Posiziona le regole di redirect prima delle regole di rewrite di PrestaShop (prima della sezione che inizia con # Dispatcher).

Per PrestaShop su Nginx, i redirect vanno nella configurazione del server block. Potrebbe essere necessario ricaricare Nginx dopo le modifiche: sudo nginx -t && sudo systemctl reload nginx.

Sintassi delle regole di redirect

Per Apache .htaccess, i redirect individuali utilizzano questo formato:

Redirect 301 /vecchio-percorso/vecchio-prodotto.html https://www.nuovodominio.com/nuovo-percorso/nuovo-prodotto

Per redirect basati su pattern con mod_rewrite:

RewriteEngine On RewriteRule ^vecchia-categoria/(.*)$ /nuova-categoria/$1 [R=301,L]

Per Nginx, redirect individuali:

location = /vecchio-percorso/vecchio-prodotto.html { return 301 https://www.nuovodominio.com/nuovo-percorso/nuovo-prodotto; }

Gestione di un gran numero di redirect

I negozi PrestaShop con migliaia di prodotti necessitano di un approccio più scalabile rispetto alla scrittura di singole regole di redirect. Le opzioni includono l'utilizzo di una RewriteMap in Apache (che legge da un file di testo o da un database), l'uso di un modulo PrestaShop progettato per la gestione dei redirect, oppure l'implementazione dei redirect a livello applicativo attraverso un modulo personalizzato che intercetta gli errori 404 e consulta una tabella di redirect.

L'approccio a livello applicativo ha il vantaggio di essere gestibile tramite il back office, ma aggiunge un piccolo overhead prestazionale a ogni richiesta 404. L'approccio tramite .htaccess è più veloce ma più difficile da gestire su larga scala.

Aggiornamento della sitemap XML

La sitemap XML comunica ai motori di ricerca quali URL esistono sul tuo sito e devono essere scansionati. Dopo una migrazione, la sitemap deve riflettere immediatamente la nuova struttura degli URL.

Generazione di una nuova sitemap

PrestaShop include la generazione integrata della sitemap, ma molti proprietari di negozi utilizzano un modulo come Google Sitemap o un modulo SEO di terze parti per un maggiore controllo. Dopo la migrazione, genera una sitemap aggiornata che includa tutti i nuovi URL. Verifica che la sitemap non contenga vecchi URL che ora effettuano redirect.

Invio della sitemap aggiornata

Vai su Google Search Console, naviga fino a Sitemap e invia il nuovo URL della sitemap (tipicamente https://www.tuodominio.com/1_index_sitemap.xml per PrestaShop). Se l'URL della sitemap stessa è cambiato, rimuovi la vecchia voce della sitemap e aggiungi quella nuova.

L'invio di una nuova sitemap segnala a Google che la struttura del tuo sito è cambiata e incoraggia una scansione più rapida dei nuovi URL. Combinato con i corretti redirect 301 dai vecchi URL, questo fornisce a Google un quadro chiaro di ciò che è accaduto.

Passaggi per la migrazione in Google Search Console

Migrazione sullo stesso dominio (spostamento server o aggiornamento)

Se il dominio non cambia, non è necessaria alcuna azione speciale in Search Console oltre all'invio della sitemap aggiornata e al monitoraggio. Google scoprirà le modifiche attraverso la normale scansione.

Migrazione con cambio di dominio

Se stai cambiando dominio, utilizza lo strumento Cambio di indirizzo in Google Search Console. Questo richiede che sia il vecchio che il nuovo dominio siano verificati in Search Console. I passaggi sono:

Per prima cosa, configura e verifica il nuovo dominio in Google Search Console. Secondo, assicurati che tutti i redirect 301 siano attivi dal vecchio dominio al nuovo dominio. Terzo, vai alla proprietà del vecchio dominio in Search Console e utilizza Impostazioni > Cambio di indirizzo. Quarto, segui le istruzioni per specificare il nuovo dominio.

Questo comunica esplicitamente a Google che il tuo sito si è spostato, il che accelera significativamente la transizione. Senza questo passaggio, Google alla fine lo capisce attraverso i redirect 301, ma ci vuole più tempo.

Considerazioni sulla propagazione DNS

Se la migrazione comporta la modifica dei record DNS (puntamento del dominio a un nuovo server), tieni presente che la propagazione DNS non è istantanea. I diversi resolver DNS in tutto il mondo si aggiornano in momenti diversi, e la propagazione completa può richiedere da 24 a 72 ore.

Ridurre al minimo il downtime

Prima della migrazione, riduci il TTL (Time To Live) del tuo DNS a un valore basso come 300 secondi (5 minuti). Fallo almeno 48 ore prima della migrazione effettiva in modo che il vecchio TTL alto scada ovunque. Quando modificherai i record DNS, i resolver controlleranno gli aggiornamenti ogni 5 minuti anziché ogni poche ore.

Dopo che la migrazione è completata e verificata, aumenta nuovamente il TTL a un valore normale come 3600 (1 ora) o superiore per ridurre il carico di query DNS.

Mantenere entrambi i server in parallelo

Durante la finestra di propagazione, alcuni visitatori raggiungeranno il vecchio server e altri il nuovo. Mantieni il vecchio server in funzione con una copia del sito (o almeno con le regole di redirect attive) fino al completamento della propagazione. Spegnere immediatamente il vecchio server causa downtime per i visitatori il cui DNS non si è ancora aggiornato.

Monitoraggio del posizionamento dopo la migrazione

Il lavoro non finisce quando la migrazione va online. Il monitoraggio post-migrazione è essenziale per individuare i problemi prima che causino danni duraturi.

Controlli immediati (Giorno 1)

Verifica che tutte le pagine critiche si carichino correttamente sul nuovo sito. Testa ogni redirect dalla tua mappatura degli URL per confermare che funzioni. Controlla Google Search Console per eventuali nuovi errori di scansione. Esegui una nuova scansione del sito e confrontala con i dati della scansione pre-migrazione.

Monitoraggio della prima settimana

Controlla Google Search Console quotidianamente per errori di scansione, problemi di indicizzazione e cali di traffico. Esamina il report Copertura per le pagine che non sono più indicizzate o che hanno restituito errori. Monitora il posizionamento delle tue parole chiave principali utilizzando uno strumento di monitoraggio del ranking. Qualche fluttuazione è normale nella prima settimana, ma cali significativi su parole chiave importanti indicano un problema con i redirect.

Monitoraggio del primo mese

Confronta il traffico organico in Google Analytics o nella tua piattaforma di analisi con lo stesso periodo prima della migrazione. Verifica che tutte le pagine importanti vengano reindicizzate cercando site:tuodominio.com/pagina-specifica su Google. Verifica che i vecchi URL vengano rimossi dall'indice (dovrebbero effettuare redirect ai nuovi URL, e Google dovrebbe eventualmente sostituirli nel suo indice).

Valutazione a tre mesi

A tre mesi dalla migrazione, il traffico organico dovrebbe essersi stabilizzato a livelli pari o vicini a quelli pre-migrazione. Se non è così, indaga su quali pagine o query specifiche hanno perso posizionamento e controlla le catene di redirect, la qualità dei contenuti e lo stato tecnico.

Errori comuni durante la migrazione

Uso dei redirect 302 invece dei 301

Un redirect 302 comunica ai motori di ricerca che lo spostamento è temporaneo. I motori di ricerca non trasferiscono la link equity completa attraverso i redirect 302. Utilizza sempre il 301 per le migrazioni permanenti. Questo è l'errore più comune e più dannoso in assoluto.

Dimenticare di reindirizzare non-www verso www (o viceversa)

Se il tuo vecchio sito utilizzava www.esempio.com e il tuo nuovo sito utilizza esempio.com (o viceversa), hai bisogno di redirect sia per il cambio di struttura degli URL sia per il cambio www/non-www. Dimenticare uno di questi crea una situazione in cui alcuni vecchi URL restituiscono errori 404.

Non aggiornare i link interni

Dopo la migrazione, i tuoi link interni dovrebbero puntare direttamente ai nuovi URL, non ai vecchi URL che effettuano redirect. Mentre i redirect preservano il valore SEO per i link esterni, i link interni che effettuano redirect creano catene di redirect non necessarie e rallentano la scansione.

Perdere l'HTTPS

Se il tuo vecchio sito utilizzava HTTPS e il tuo nuovo sito no (o viceversa), Google li tratta come URL diversi. Assicurati che il certificato SSL sia correttamente configurato sul nuovo server prima di andare online, e che tutti i redirect utilizzino il protocollo corretto.

Cambiare più cose contemporaneamente

Se cambi dominio, struttura degli URL, contenuti e design del sito tutto nello stesso momento, diventa impossibile diagnosticare cosa ha causato eventuali cali di posizionamento. Cambia il minor numero possibile di elementi durante la migrazione stessa. Gli aggiornamenti di contenuti e design possono avvenire dopo che il posizionamento si è stabilizzato.

Cronologia della migrazione

Una migrazione PrestaShop ben pianificata segue questa cronologia:

4 settimane prima: Completa l'audit SEO, esporta tutti i dati, inizia la mappatura degli URL. Riduci il TTL DNS se cambi server.

2 settimane prima: Finalizza la mappatura degli URL, scrivi tutte le regole di redirect, configura il nuovo sito in un ambiente di staging e testa accuratamente.

1 settimana prima: Testa tutti i redirect sullo staging. Verifica che la nuova sitemap XML sia corretta. Esegui una scansione completa del sito di staging e confrontala con i dati di scansione del vecchio sito.

Giorno della migrazione: Distribuisci il nuovo sito, attiva i redirect, aggiorna il DNS se necessario, invia la nuova sitemap a Search Console, utilizza il Cambio di indirizzo se cambi dominio.

Settimana 1: Monitora Search Console quotidianamente, correggi immediatamente eventuali errori di scansione, verifica il funzionamento dei redirect.

Mese 1: Revisioni settimanali di Search Console, confronta il traffico con la baseline, controlla lo stato dell'indicizzazione.

Mese 3: Valutazione completa rispetto alla baseline pre-migrazione. Affronta eventuali problemi rimanenti.

Riepilogo

Una migrazione PrestaShop di successo che preservi il posizionamento su Google richiede tre elementi: una preparazione accurata, una corretta implementazione dei redirect e un monitoraggio diligente post-migrazione. L'audit pre-migrazione fornisce una baseline e identifica le pagine di maggior valore. La mappatura degli URL e i redirect 301 garantiscono che il valore SEO di ogni pagina venga trasferito alla nuova posizione. L'aggiornamento della sitemap e la configurazione di Search Console aiutano Google a scoprire ed elaborare le modifiche rapidamente. E il monitoraggio post-migrazione individua i problemi prima che diventino permanenti. Saltare uno qualsiasi di questi passaggi significa rischiare di perdere un posizionamento che ha richiesto mesi o anni per essere costruito. Seguirli tutti trasforma la migrazione in una transizione controllata anziché in un disastro SEO.

Leggi la risposta completa

Comprendere i redirect e perché il 301 è l'unica scelta corretta

Quando si migra un negozio PrestaShop, gli URL cambiano. I prodotti che si trovavano a un indirizzo ora si trovano a un altro. Le categorie che avevano un determinato slug ora ne hanno uno diverso. Senza redirect, ogni vecchio URL diventa un vicolo cieco, restituendo un errore 404 sia ai visitatori che ai motori di ricerca. L'effetto cumulativo è devastante: traffico perso, posizionamento perso e vendite perse.

Un redirect è un'istruzione dal tuo server che comunica ai browser e ai crawler dei motori di ricerca che una pagina si è spostata. Quando un visitatore o Googlebot richiede il vecchio URL, il server risponde con la nuova posizione e il client segue automaticamente il redirect. Ma non tutti i redirect sono uguali, e utilizzare il tipo sbagliato può compromettere l'intera migrazione.

301 vs 302: una distinzione fondamentale

Un redirect 301 segnala uno spostamento permanente. Comunica ai motori di ricerca di trasferire la link equity accumulata (il valore SEO costruito attraverso backlink, qualità dei contenuti e coinvolgimento degli utenti) dal vecchio URL al nuovo. Nel tempo, Google sostituisce il vecchio URL nel suo indice con quello nuovo. Questo è ciò che desideri dopo una migrazione.

Un redirect 302 segnala uno spostamento temporaneo. Comunica ai motori di ricerca che il vecchio URL tornerà eventualmente disponibile, quindi dovrebbero mantenere il vecchio URL nell'indice e non trasferire la link equity. Utilizzare redirect 302 dopo una migrazione permanente significa che Google continua a cercare di indicizzare i tuoi vecchi URL, i tuoi nuovi URL faticano ad acquisire autorità e perdi posizionamento inutilmente.

Esiste anche il redirect 307, che è l'equivalente HTTP/1.1 del 302, e il redirect 308, che è l'equivalente HTTP/1.1 del 301. Per gli scopi SEO di PrestaShop, il 301 è la scelta standard e universalmente supportata.

La regola è semplice: se la pagina si è spostata permanentemente, usa il 301. Dopo una migrazione, la pagina si è spostata permanentemente. Usa sempre il 301.

Configurazione dei redirect nel file .htaccess (Apache)

La maggior parte delle installazioni PrestaShop funziona su Apache, e il file .htaccess è dove si configurano i redirect. Questo file si trova nella directory root di PrestaShop, insieme a index.php.

La posizione è importante

Il file .htaccess di PrestaShop contiene regole di rewrite che gestiscono gli URL amichevoli, forzano l'HTTPS e instradano le richieste ai controller corretti. Le tue regole di redirect devono essere posizionate prima delle regole di rewrite di PrestaShop. Se le posizioni dopo, le regole di PrestaShop potrebbero intercettare la richiesta per prime e i tuoi redirect non verranno mai eseguiti.

Cerca la riga di commento che dice # Dispatcher o il blocco che inizia con RewriteRule ^api. I tuoi redirect personalizzati vanno sopra questa sezione ma dopo RewriteEngine On.

Redirect di singole pagine

La forma più semplice di redirect associa un vecchio URL specifico a un nuovo URL specifico:

Redirect 301 /vecchia-categoria/vecchio-prodotto.html https://www.esempio.com/nuova-categoria/nuovo-prodotto

La direttiva Redirect fa parte del modulo mod_alias di Apache. Il primo argomento è il codice di stato HTTP (301), il secondo è il vecchio percorso (relativo alla document root) e il terzo è il nuovo URL completo.

Dettagli importanti: il vecchio percorso deve iniziare con una barra e non deve includere il nome del dominio. Il nuovo URL deve essere un URL completo che includa il protocollo e il dominio. Il vecchio percorso viene confrontato in modo esatto, incluse le barre finali e le estensioni dei file.

Redirect basati su pattern con RewriteRule

Quando molti URL seguono un cambiamento di pattern prevedibile, i redirect individuali diventano poco pratici. Il modulo mod_rewrite di Apache permette di scrivere regole basate su pattern utilizzando espressioni regolari:

RewriteEngine On RewriteRule ^vecchia-categoria/(.*)$ /nuova-categoria/$1 [R=301,L]

Questa regola cattura tutto ciò che segue vecchia-categoria/ e lo aggiunge a nuova-categoria/. Il $1 è un riferimento al primo gruppo catturato (la parte tra parentesi). I flag [R=301,L] specificano un redirect 301 e che questa è l'ultima regola da processare se corrisponde.

Scenari comuni di redirect basati su pattern per le migrazioni PrestaShop:

Rimozione delle estensioni .html:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Passaggio da URL di categoria basati su ID a URL basati sul nome:

RewriteRule ^3-vecchia-categoria(.*)$ /nuova-categoria$1 [R=301,L]

Redirect di un'intera sottodirectory:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Redirect condizionali

A volte è necessario applicare i redirect solo in determinate condizioni. RewriteCond fornisce questa funzionalità:

RewriteCond %{HTTP_HOST} ^vecchiodominio\.com$ [NC] RewriteRule ^(.*)$ https://www.nuovodominio.com/$1 [R=301,L]

Questo reindirizza tutte le richieste da vecchiodominio.com a nuovodominio.com, preservando il percorso. Il flag [NC] rende la condizione case-insensitive.

Per reindirizzare solo se il file richiesto non esiste sul nuovo server (utile durante una migrazione graduale):

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^vecchio-percorso/(.*)$ /nuovo-percorso/$1 [R=301,L]

Configurazione dei redirect in Nginx

Se il tuo PrestaShop funziona su Nginx, i redirect vengono configurati nel file di configurazione del server block, tipicamente situato in /etc/nginx/sites-available/tuodominio.conf o /etc/nginx/conf.d/tuodominio.conf.

Redirect individuali

location = /vecchia-categoria/vecchio-prodotto.html { return 301 https://www.esempio.com/nuova-categoria/nuovo-prodotto; }

Il modificatore = specifica una corrispondenza esatta. Senza di esso, Nginx tratta la location come corrispondenza prefisso, che potrebbe reindirizzare più URL del previsto.

Redirect basati su pattern

location ~ ^/vecchia-categoria/(.*)$ { return 301 /nuova-categoria/$1; }

Il modificatore ~ abilita la corrispondenza regex. Il gruppo catturato $1 funziona allo stesso modo che in Apache.

Redirect basati su map per liste estese

La direttiva map di Nginx è ideale per gestire centinaia o migliaia di redirect individuali senza sovraccaricare il server block:

map $request_uri $redirect_target { /vecchio-prodotto-1.html /nuovo-prodotto-1; /vecchio-prodotto-2.html /nuovo-prodotto-2; /vecchio-prodotto-3.html /nuovo-prodotto-3; }

server { if ($redirect_target) { return 301 $redirect_target; } }

Il blocco map viene valutato una sola volta per richiesta ed è altamente efficiente anche con migliaia di voci. È possibile caricare la map da un file esterno utilizzando la direttiva include.

Ricorda di testare la configurazione con nginx -t e di ricaricare con systemctl reload nginx dopo ogni modifica.

Redirect massivi con CSV

Per migrazioni che coinvolgono migliaia di prodotti, scrivere manualmente le regole di redirect non è fattibile. Un approccio basato su CSV semplifica il processo.

Creazione del CSV

Esporta i tuoi vecchi URL dai dati del crawl pre-migrazione o dal database. Esporta i nuovi URL dalla nuova installazione. Abbinali in un foglio di calcolo con due colonne: percorso del vecchio URL e percorso del nuovo URL. Salva come CSV.

Il tuo CSV potrebbe avere questo aspetto:

/3-vecchia-categoria,/nuova-categoria /vecchia-categoria/vecchio-prodotto-1.html,/nuova-categoria/nuovo-prodotto-1 /vecchia-categoria/vecchio-prodotto-2.html,/nuova-categoria/nuovo-prodotto-2 /content/5-chi-siamo,/content/chi-siamo

Conversione del CSV in regole .htaccess

Un approccio semplice è convertire ogni riga del CSV in una direttiva Redirect. Utilizzando un editor di testo con trova e sostituisci o un semplice strumento da riga di comando:

awk -F',' '{print "Redirect 301 " $1 " https://www.esempio.com" $2}' redirects.csv >> .htaccess

Questo legge il file CSV, divide ogni riga per virgola e genera una direttiva Redirect per ogni riga.

Utilizzo di una tabella nel database

Per liste di redirect molto estese (oltre 10.000 voci), considera la possibilità di archiviare i redirect in una tabella del database e di gestirli a livello applicativo. Crea una tabella con colonne per il vecchio percorso e il nuovo percorso, e scrivi un piccolo modulo PrestaShop o un override che intercetti gli errori 404, controlli la tabella e restituisca un redirect 301 se viene trovata una corrispondenza. Questo approccio è più facile da gestire tramite un'interfaccia di amministrazione, ma aggiunge una piccola query al database per ogni risposta 404.

Soluzioni di redirect basate su moduli

Diversi moduli PrestaShop forniscono la gestione dei redirect attraverso il back office, eliminando la necessità di modificare direttamente i file di configurazione del server.

Vantaggi dei redirect basati su moduli

Un modulo di redirect offre un'interfaccia intuitiva per aggiungere, modificare e eliminare redirect. Include tipicamente funzionalità di importazione/esportazione per operazioni massive, logging per monitorare quali redirect vengono utilizzati, e la possibilità per i membri non tecnici del team di gestire i redirect senza accesso al server.

Come funzionano i redirect basati su moduli

La maggior parte dei moduli di redirect funziona agganciandosi al processo di gestione delle richieste di PrestaShop. Quando arriva una richiesta che normalmente genererebbe un errore 404, il modulo la intercetta, controlla il suo database di redirect per un vecchio URL corrispondente e, se trovato, invia una risposta di redirect 301 al nuovo URL.

Alcuni moduli vanno oltre creando automaticamente redirect quando si modifica l'URL amichevole di un prodotto nel back office. Questo previene il problema comune di rompere i vecchi link quando si ottimizzano gli slug degli URL.

Considerazioni sulle prestazioni

I redirect basati su moduli aggiungono un piccolo overhead a ogni richiesta 404 perché devono interrogare il database. Per la maggior parte dei negozi questo è trascurabile, ma se hai migliaia di redirect e un traffico significativo di bot che colpiscono i vecchi URL, le query al database possono accumularsi. Considera l'utilizzo di un livello di caching o lo spostamento dei redirect più utilizzati nel file .htaccess per prestazioni ottimali.

Redirect regex: potenza e pericolo

I redirect con espressioni regolari sono strumenti potenti che possono gestire trasformazioni URL complesse con una singola regola. Sono anche la fonte più comune di errori di redirect e loop infiniti.

Quando utilizzare i redirect regex

Utilizza i redirect regex quando il cambiamento dell'URL segue un pattern coerente e prevedibile. Buoni candidati includono: rimuovere o aggiungere estensioni file a tutti gli URL, cambiare un prefisso URL per un'intera sezione del sito, rimuovere o aggiungere prefissi di lingua, e eliminare parametri di query.

Pattern regex comuni per PrestaShop

Rimozione del prefisso ID delle categorie che PrestaShop 1.6 aggiunge agli URL delle categorie:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Questa regola corrisponde a URL come /3-scarpe e reindirizza a /scarpe.

Aggiunta di un prefisso di lingua:

RewriteCond %{REQUEST_URI} !^/(en|de|fr|it)/ RewriteRule ^(.+)$ /it/$1 [R=301,L]

Rimozione delle doppie barre:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Testare le regole regex in sicurezza

Prima di distribuire i redirect regex in produzione, testali accuratamente. Utilizza un tester regex online (come regex101.com) per verificare che il tuo pattern corrisponda agli URL desiderati e non corrisponda a URL che non dovrebbe intercettare.

Inizia con un redirect 302 durante i test. Questo impedisce ai motori di ricerca di memorizzare nella cache redirect errati. Una volta verificato che la regola funziona correttamente, cambiala in 301.

Testa i casi limite: URL con parametri di query, URL con caratteri speciali, URL con più pattern corrispondenti. Ciascuno di questi può rivelare problemi che non sono evidenti con URL di test semplici.

Test dei redirect

Distribuire redirect senza test accurati è una ricetta per il disastro. Ecco i metodi che dovresti utilizzare per verificare i tuoi redirect prima e dopo il go-live.

Test da riga di comando con curl

Il comando curl è il modo più affidabile per testare i redirect perché mostra esattamente ciò che il server restituisce:

curl -I https://www.esempio.com/vecchio-prodotto.html

Il flag -I richiede solo gli header. Nella risposta, cerca:

HTTP/1.1 301 Moved Permanently Location: https://www.esempio.com/nuovo-prodotto

Verifica che il codice di stato sia 301 (non 302) e che l'header Location punti al corretto nuovo URL.

Per seguire la catena di redirect e vedere ogni passaggio:

curl -IL https://www.esempio.com/vecchio-prodotto.html

Il flag -L dice a curl di seguire i redirect, mostrando gli header a ogni passaggio.

Test massivi

Per liste di redirect estese, automatizza i test con un ciclo:

while IFS=, read -r old new; do status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.esempio.com$old") echo "$old -> $status" done < redirects.csv

Questo legge il tuo file CSV, testa ogni vecchio URL e stampa il codice di stato HTTP. Qualsiasi URL che non restituisce 301 richiede attenzione.

Test nel browser

Apri gli strumenti per sviluppatori del browser (F12), vai alla scheda Network e naviga verso un vecchio URL. La scheda Network mostra la catena di richieste, inclusi tutti i redirect. Verifica il codice di stato, la destinazione del redirect e la pagina finale che viene caricata.

Ispezione in Google Search Console

Dopo la distribuzione, utilizza lo strumento Controllo URL in Google Search Console per verificare come Google vede i tuoi URL reindirizzati. Inserisci un vecchio URL e controlla se Google riconosce il redirect e ha scoperto il nuovo URL.

Catene di redirect e come evitarle

Una catena di redirect si verifica quando un redirect porta a un altro redirect, che può portare a un ulteriore redirect. Ad esempio: l'URL A reindirizza all'URL B, che reindirizza all'URL C, che infine serve il contenuto. Ogni passaggio aggiunge latenza e diluisce la link equity.

Perché le catene di redirect sono dannose

Google ha dichiarato che seguirà le catene di redirect, ma con dei limiti. Dopo un certo numero di passaggi (tipicamente 5-10), Googlebot rinuncia e tratta l'URL come un errore. Anche per catene più corte, ogni passaggio ritarda la consegna della pagina e perde una piccola quantità di link equity.

Per i visitatori, ogni redirect aggiunge 50-200 millisecondi di latenza, a seconda delle condizioni di rete e del tempo di risposta del server. Una catena di 3 redirect può aggiungere mezzo secondo o più al tempo di caricamento percepito.

Cause comuni delle catene di redirect in PrestaShop

La catena più comune si verifica quando una migrazione aggiunge redirect sopra redirect esistenti. Ad esempio, potresti avere vecchi redirect da un precedente cambio di struttura URL, e la nuova migrazione aggiunge un ulteriore livello. L'URL A reindirizza all'URL B (dalla prima migrazione), e l'URL B reindirizza all'URL C (dalla seconda migrazione).

Un'altra causa comune è l'interazione tra il redirect canonico integrato di PrestaShop e i tuoi redirect personalizzati. PrestaShop potrebbe reindirizzare da un URL non canonico alla versione canonica, e se anche il tuo redirect personalizzato corrisponde, ottieni una catena.

L'imposizione dell'HTTPS aggiunge un altro potenziale passaggio. Se il tuo redirect punta a un URL HTTP, e il server poi reindirizza a HTTPS, quella è una catena a due passaggi.

Correzione delle catene di redirect

Esegui un audit dei tuoi redirect regolarmente utilizzando uno strumento di crawling che rileva le catene. Quando trovi una catena, aggiorna il primo redirect in modo che punti direttamente alla destinazione finale. L'URL A dovrebbe reindirizzare direttamente all'URL C, bypassando completamente l'URL B.

Quando aggiungi nuovi redirect durante una migrazione, controlla sempre se l'URL di destinazione è esso stesso un redirect. Se lo è, imposta il nuovo redirect in modo che punti alla destinazione finale.

Errori comuni e come evitarli

Loop di redirect infiniti

Un loop infinito si verifica quando l'URL A reindirizza all'URL B e l'URL B reindirizza nuovamente all'URL A. Il browser rileva questa situazione e mostra un errore ERR_TOO_MANY_REDIRECTS. Le cause comuni includono regole in conflitto nel file .htaccess (una regola reindirizza www verso non-www mentre un'altra reindirizza non-www verso www), redirect in conflitto tra .htaccess e un modulo di redirect, e regole regex troppo ampie che corrispondono ai propri URL di destinazione.

Per risolvere un loop, inizia disabilitando tutti i redirect personalizzati e riabilitandoli uno alla volta fino a quando il loop ricompare. Questo identifica la regola in conflitto.

Dimenticare i parametri di query

Per impostazione predefinita, la direttiva Redirect di Apache passa i parametri di query al nuovo URL. Tuttavia, RewriteRule non passa i parametri di query a meno che non si aggiunga il flag [QSA] (Query String Append). Se i tuoi vecchi URL includono parametri di query importanti (come ?id_product=123), assicurati che vengano gestiti correttamente.

Sensibilità alle maiuscole

Sui server Linux, gli URL sono case-sensitive. /Prodotto.html e /prodotto.html sono URL diversi. Se il tuo vecchio sito aveva URL con maiuscole e minuscole miste e il tuo nuovo sito normalizza tutto in minuscolo, hai bisogno di redirect che gestiscano entrambi i casi. Utilizza il flag [NC] nella RewriteRule per la corrispondenza case-insensitive.

Non reindirizzare tutte le varianti degli URL

Una singola pagina prodotto potrebbe essere accessibile tramite più URL: con e senza barra finale, con e senza estensione .html, con e senza il prefisso del percorso della categoria, con e senza www. Ogni variante che è stata indicizzata necessita del proprio redirect al nuovo URL canonico.

Lasciare i redirect attivi per sempre

Sebbene i redirect debbano rimanere attivi per almeno 12 mesi dopo una migrazione (Google raccomanda almeno un anno), non dovrebbero rimanere indefinitamente. Dopo un anno o più, i vecchi URL non dovrebbero più apparire nei risultati di ricerca né ricevere traffico significativo. Esamina i log dei redirect, rimuovi le regole che non vengono più attivate e mantieni la configurazione pulita.

Riepilogo

Configurare correttamente i redirect 301 è il compito tecnico più importante in una migrazione PrestaShop. Ogni vecchio URL che aveva traffico, backlink o visibilità nei motori di ricerca deve reindirizzare alla sua controparte con un codice di stato 301. Il metodo di implementazione dipende dal tuo server (Apache .htaccess o configurazione Nginx), dal numero di URL (regole individuali, pattern regex o moduli basati su database) e dalle capacità tecniche del tuo team. Testa ogni redirect prima del go-live utilizzando curl o gli strumenti per sviluppatori del browser. Fai attenzione alle catene di redirect, ai loop infiniti e ai problemi di sensibilità alle maiuscole. Monitora Google Search Console dopo la distribuzione per verificare che Google stia elaborando correttamente i tuoi redirect. E ricorda che un 302 dove dovrebbe esserci un 301 non è mai innocuo. È sempre la scelta sbagliata per una migrazione permanente.

Leggi la risposta completa

Perché la qualità del tema conta più dell'aspetto

La scelta di un tema PrestaShop è una delle decisioni più importanti che un proprietario di negozio possa prendere. Un tema controlla non solo l'aspetto del negozio, ma anche le prestazioni, l'accessibilità per i clienti con disabilità, la facilità con cui i motori di ricerca possono scansionarlo e quanto facilmente è possibile estenderlo con i moduli. Un tema mal costruito crea problemi che si accumulano nel tempo. Quello che sembra un piccolo fastidio durante la configurazione iniziale diventa un collo di bottiglia per le prestazioni sotto carico, un incubo di manutenzione durante gli aggiornamenti o un fallimento nell'esperienza del cliente che uccide silenziosamente le conversioni.

Il problema è che i marketplace di temi sono invasi da temi che appaiono impressionanti negli screenshot delle demo ma sono costruiti con minima attenzione agli standard di codifica, alle prestazioni o alla compatibilità. Molti sviluppatori di temi ottimizzano per l'impatto visivo nell'anteprima, sapendo che la maggior parte degli acquirenti valuta i temi in base al loro aspetto piuttosto che a come sono costruiti. Questa guida ti insegna a guardare oltre la superficie e a identificare i segnali di allarme che separano un tema PrestaShop ben costruito da uno che ti causerà problemi.

Richieste HTTP eccessive

Uno degli indicatori più affidabili di un tema mal costruito è un numero eccessivo di richieste HTTP. Ogni file CSS, file JavaScript, immagine, font e risorsa esterna che una pagina carica richiede una richiesta separata al server. Sebbene i browser moderni possano gestire più richieste in parallelo tramite HTTP/2, ogni richiesta aggiunge comunque latenza, specialmente su connessioni mobili.

Un tema PrestaShop ben costruito dovrebbe caricarsi con non più di 30-50 richieste su una tipica pagina prodotto o categoria, supponendo che non siano installati moduli aggiuntivi. I temi mal costruiti superano regolarmente le 80 o anche le 100 richieste. Le cause più comuni sono il caricamento di più file CSS invece di combinarli, l'inclusione di librerie JavaScript non utilizzate su ogni pagina, il caricamento di web font da più fornitori e l'incorporamento di widget esterni o pixel di tracciamento direttamente nel tema anziché attraverso i moduli.

Per verificare questo prima di acquistare un tema, apri la demo del tema in Chrome, apri gli Strumenti per sviluppatori (F12), vai alla scheda Network e ricarica la pagina. Guarda il numero totale di richieste mostrato nella parte inferiore del pannello. Poi esamina cosa viene caricato. Ci sono dozzine di file CSS individuali? Ci sono più versioni di jQuery? Ci sono richieste verso domini di terze parti che non riconosci? Questi sono segnali di allarme.

Presta particolare attenzione alle richieste che bloccano il rendering. CSS e JavaScript sincrono nell'head del documento impediscono al browser di visualizzare qualsiasi contenuto fino al completamento del caricamento. Un tema ben costruito differisce CSS e JavaScript non critici in modo che la pagina inizi a renderizzarsi rapidamente. Un tema mal costruito carica tutto in anticipo, creando uno schermo bianco che dura per diversi secondi.

Stili inline e design hardcoded

Gli sviluppatori di temi professionali utilizzano classi CSS e fogli di stile per controllare l'aspetto visivo di un tema. Questo approccio è manutenibile, sovrascrivibile e performante perché i browser memorizzano nella cache i fogli di stile esterni. I temi mal costruiti, al contrario, disseminano stili inline nei template Smarty e nei file PHP. Si trovano cose come style="color: #333; font-size: 14px; margin-top: 20px;" direttamente sugli elementi HTML.

Gli stili inline sono problematici per diversi motivi. Non possono essere memorizzati nella cache separatamente dall'HTML. Sono estremamente difficili da sovrascrivere con il CSS, richiedendo la dichiarazione !important ovunque. Rendono il tema quasi impossibile da personalizzare senza modificare direttamente i file dei template, il che significa che le personalizzazioni vengono perse ogni volta che il tema viene aggiornato. E aumentano la dimensione del documento HTML, influenzando le prestazioni su ogni caricamento di pagina.

Un segnale di allarme correlato è trovare valori di design hardcoded nei file PHP. Se vedi codici colore, dimensioni dei font o dimensioni del layout definiti in PHP anziché in CSS o in un pannello di configurazione, lo sviluppatore del tema ha preso scorciatoie. Qualsiasi modifica al design richiederà la modifica del codice PHP, operazione soggetta a errori e che rende pericolosi gli aggiornamenti.

Per verificare la presenza di stili inline, fai clic destro su vari elementi nella demo del tema e scegli Ispeziona elemento. Guarda il pannello Stili negli Strumenti per sviluppatori. Se vedi un gran numero di stili elencati sotto element.style anziché provenienti da classi CSS, il tema si basa pesantemente sullo stile inline. Alcuni stili inline sono normali e accettabili (ad esempio, immagini di sfondo dinamiche impostate dal CMS), ma se la maggior parte dello stile è inline, questo è un chiaro segnale di allarme.

Design responsive mancante

Nel 2026, oltre il 60% del traffico e-commerce proviene da dispositivi mobili. Un tema che non funziona bene su mobile non è solo scomodo. Costa direttamente vendite e posizionamento nei risultati di ricerca, perché Google utilizza l'indicizzazione mobile-first, il che significa che valuta il tuo sito basandosi sulla versione mobile.

Ma il design responsive non riguarda solo il fatto che il tema abbia una visualizzazione mobile. Molti temi dichiarano di essere responsive ma lo implementano malamente. I segnali di allarme per un cattivo design responsive includono testo che fuoriesce dal suo contenitore sugli schermi piccoli, pulsanti e link troppo piccoli per essere toccati in modo affidabile, scorrimento orizzontale su mobile, immagini che non si ridimensionano e costringono l'utente a scorrere orizzontalmente, menu di navigazione difficili o impossibili da usare su dispositivi touch e form di checkout inutilizzabili sui telefoni.

Testa la demo del tema su un telefono reale, non solo ridimensionando la finestra del browser. Il ridimensionamento del browser non replica le interazioni touch, le condizioni di rete effettive o il comportamento di rendering dei browser mobili. Prova l'intero flusso di acquisto sul tuo telefono: sfoglia le categorie, apri un prodotto, aggiungi al carrello e procedi attraverso il checkout. Se qualsiasi passaggio risulta frustrante o non funzionante, il tema fallisce il test più basilare di compatibilità mobile.

Controlla anche se il tema utilizza immagini responsive appropriate. Un tema ben costruito serve dimensioni di immagine diverse per schermi diversi utilizzando l'attributo srcset o l'elemento <picture>. Un tema mal costruito serve la stessa immagine desktop di grandi dimensioni ai dispositivi mobili e si affida al CSS per ridurla visivamente, sprecando banda e rallentando il caricamento delle pagine mobili.

Testo hardcoded senza traduzioni

PrestaShop dispone di un robusto sistema di traduzione che permette di tradurre ogni stringa visualizzata all'utente in qualsiasi lingua. Un tema costruito correttamente utilizza questo sistema per ogni porzione di testo visibile, dalle etichette dei pulsanti ai messaggi di errore fino ai testi delle intestazioni. La sintassi Smarty appare come {l s='Add to cart' d='Shop.Theme.Actions'}, rendendo la stringa disponibile nell'interfaccia di traduzione del back office.

I temi mal costruiti inseriscono il testo hardcoded direttamente nei template. Invece di utilizzare la funzione di traduzione, scrivono HTML semplice come <button>Add to cart</button>. Questo significa che il testo non può essere tradotto, il che rende il tema inutilizzabile per i negozi multilingua e problematico anche per i negozi monolingua che desiderano personalizzare le etichette dei pulsanti o i messaggi.

Per verificare questo, osserva la demo del tema e annota stringhe di testo specifiche come etichette dei pulsanti, intestazioni delle sezioni e testo segnaposto. Poi cerca di trovare i file di traduzione del tema. Un tema ben costruito include cataloghi di traduzione o utilizza in modo coerente i domini di traduzione di PrestaShop. Se la documentazione del tema non menziona le traduzioni o il supporto multilingua, questo è un motivo di preoccupazione. Se riesci ad accedere a qualcuno dei file dei template del tema (alcuni marketplace forniscono anteprime dei file), cerca stringhe di testo semplice che dovrebbero essere traducibili. Ogni stringa rivolta all'utente dovrebbe essere racchiusa in una chiamata alla funzione di traduzione.

Conflitti jQuery e problemi JavaScript

PrestaShop include jQuery come parte del suo framework front-end principale. Un tema ben costruito funziona con la versione di jQuery fornita da PrestaShop. Un tema mal costruito include la propria versione di jQuery (creando conflitti), carica librerie JavaScript aggiuntive che duplicano funzionalità già disponibili nel core, o utilizza tecniche JavaScript incompatibili con altri moduli.

I conflitti jQuery sono uno dei problemi più comuni con i temi di terze parti. Quando un tema carica la propria versione di jQuery, può rompere i moduli che dipendono dalla versione core. I sintomi includono moduli che falliscono silenziosamente (pulsanti che non rispondono ai clic, form che non si inviano, funzionalità AJAX che non funzionano), errori JavaScript nella console del browser e funzionalità che funzionano nella demo del tema (dove non sono installati altri moduli) ma si rompono nel tuo negozio reale.

Per verificare i conflitti jQuery prima dell'acquisto, apri la demo del tema, apri la console del browser (F12, scheda Console) e digita jQuery.fn.jquery per vedere quale versione è caricata. Poi guarda nella scheda Network per individuare più file jQuery caricati. Se vedi più di un file jQuery, o se la versione non corrisponde a quella fornita da PrestaShop (jQuery 3.x per PrestaShop 1.7 e 8.x), il tema probabilmente causerà conflitti.

Cerca anche errori JavaScript nella console durante la navigazione della demo. Errori sul sito demo, dove le condizioni sono controllate e solo i moduli predefiniti sono installati, sono un segnale di allarme molto forte. Se il tema non riesce a funzionare senza errori nel proprio ambiente demo, avrà sicuramente problemi in un negozio reale con moduli aggiuntivi.

Supporto hook mancante

Il sistema di hook di PrestaShop è il meccanismo principale attraverso cui i moduli si integrano con il tuo negozio. Gli hook sono punti predefiniti nei template del tema dove i moduli possono inserire il loro contenuto. Gli hook standard di PrestaShop includono displayHeader, displayTop, displayHome, displayFooter, displayLeftColumn, displayRightColumn, displayProductAdditionalInfo e molti altri.

Un tema ben costruito supporta tutti gli hook standard di PrestaShop, garantendo che qualsiasi modulo progettato per PrestaShop funzioni correttamente. Un tema mal costruito rimuove gli hook per semplificare il layout, sostituisce gli hook standard con hook proprietari personalizzati, o posiziona gli hook in posizioni che rompono il layout previsto.

Hook mancanti significano che i moduli installati non avranno un punto dove visualizzare il loro contenuto. Un modulo di pagamento che si basa su displayPaymentReturn non mostrerà il messaggio di conferma. Un modulo di personalizzazione prodotto che utilizza displayProductAdditionalInfo sarà invisibile nelle pagine prodotto. Finirai per dover modificare manualmente i template del tema per aggiungere gli hook mancanti (il che si rompe ad ogni aggiornamento del tema) oppure scegliere moduli specificamente progettati per quel tema (il che limita le tue opzioni e crea dipendenza dal fornitore).

Per verificare il supporto degli hook, consulta la documentazione del tema per un elenco degli hook supportati. Se tale elenco non esiste, questo di per sé è già un motivo di preoccupazione. Nella demo, installa o immagina di installare un modulo che utilizza un hook standard e verifica se il layout del tema lo gestisce. Puoi anche esaminare i file dei template del tema se sono accessibili, cercando {hook h='displayHome'} e altri nomi di hook standard.

Assenza di supporto per temi figlio

PrestaShop 1.7 e le versioni successive supportano i temi figlio (child theme), che permettono di personalizzare un tema senza modificare i file originali. Un tema figlio eredita tutto dal tema genitore e contiene solo i file che desideri sovrascrivere. Quando il tema genitore viene aggiornato, le tue personalizzazioni rimangono intatte perché risiedono in file separati.

Un tema che non supporta i temi figlio ti costringe a effettuare tutte le personalizzazioni direttamente nei file del tema. Ogni volta che lo sviluppatore del tema rilascia un aggiornamento, ti trovi di fronte a una scelta: saltare l'aggiornamento e perdere correzioni di bug e nuove funzionalità, oppure applicare l'aggiornamento e perdere tutte le personalizzazioni. Nessuna delle due opzioni è accettabile per un negozio in produzione.

Controlla la documentazione del tema e il suo file theme.yml per il supporto dei temi figlio. Il file theme.yml è il file di configurazione centrale di un tema PrestaShop e dovrebbe includere un campo parent o una documentazione che spiega come creare un tema figlio. Se lo sviluppatore del tema non menziona i temi figlio nella documentazione, chiedi direttamente prima dell'acquisto. Uno sviluppatore che non supporta i temi figlio o non comprende lo sviluppo moderno di PrestaShop o non si preoccupa della manutenibilità a lungo termine del proprio prodotto.

Scarsa accessibilità

L'accessibilità web significa che le persone con disabilità possono utilizzare il tuo negozio. Questo include le persone che utilizzano screen reader, le persone che navigano con la tastiera invece del mouse, le persone con problemi di vista che utilizzano l'ingrandimento dello schermo e le persone con daltonismo. L'accessibilità non è solo eticamente importante. In molti paesi, inclusi quelli dell'Unione Europea e degli Stati Uniti, i siti e-commerce sono tenuti per legge a soddisfare gli standard di accessibilità (WCAG 2.1 Livello AA).

Un tema mal costruito ignora completamente l'accessibilità. I fallimenti di accessibilità più comuni includono immagini senza attributi alt (gli screen reader non possono descriverle), campi di form senza etichette associate (gli screen reader non possono indicare all'utente cosa digitare), contrasto di colore insufficiente tra testo e sfondo (le persone con problemi di vista non possono leggere il testo), elementi interattivi non raggiungibili o attivabili con la tastiera, indicatori di focus rimossi per motivi estetici (gli utenti che navigano con tastiera non possono vedere dove si trovano nella pagina) e attributi ARIA utilizzati in modo errato o non utilizzati affatto.

Per eseguire un controllo di accessibilità di base sulla demo di un tema, prova a navigare nel sito utilizzando solo la tastiera (Tab per spostarti tra gli elementi, Invio per attivare pulsanti e link). Se non riesci a raggiungere tutti gli elementi interattivi o se non c'è un indicatore di focus visibile che mostra quale elemento è attualmente selezionato, il tema fallisce l'accessibilità di base. Esegui anche la pagina attraverso uno strumento gratuito come il WAVE Web Accessibility Evaluation Tool o utilizza l'audit di Accessibilità di Lighthouse in Chrome DevTools (vai alla scheda Lighthouse, seleziona solo Accessibilità e avvia l'audit). Un tema ben costruito dovrebbe ottenere almeno 80 su 100 nell'audit di accessibilità di Lighthouse.

File di dimensioni eccessive

La dimensione dei file di un tema influisce direttamente sulla velocità di caricamento del negozio. I temi sovradimensionati includono risorse non necessarie, immagini non ottimizzate, CSS e JavaScript non minificati e intere librerie utilizzate per una singola funzionalità. È comune trovare temi che includono diversi megabyte di CSS (quando il CSS effettivamente utilizzato è una frazione di quel totale), più icon font caricati per intero quando vengono utilizzate solo poche icone, immagini demo non compresse lasciate nella directory del tema e librerie JavaScript come Moment.js o Lodash incluse nella loro interezza quando servono solo una o due funzioni.

Per valutare le dimensioni dei file, controlla la dimensione totale del trasferimento nella scheda Network di Chrome DevTools quando carichi la demo del tema. Un tema ben ottimizzato dovrebbe caricare meno di 1 MB di risorse totali su una pagina tipica (escludendo le immagini dei prodotti, che variano). Se la demo del tema carica 2-3 MB o più di CSS, JavaScript e font, il tema è sovradimensionato. Presta particolare attenzione alle dimensioni dei file CSS. I temi PrestaShop che utilizzano Bootstrap o un framework simile dovrebbero includere solo i componenti Bootstrap effettivamente utilizzati, non l'intera libreria. Un file CSS da 500 KB su una singola pagina è quasi certamente sovradimensionato.

Controlla anche se il tema minifica i CSS e JavaScript di produzione. La minificazione rimuove spazi bianchi, commenti e caratteri non necessari, riducendo tipicamente le dimensioni dei file del 20-40%. Visualizza il sorgente dei file CSS nella demo. Se contengono codice leggibile e formattato con commenti, non sono minificati, il che suggerisce che lo sviluppatore non ha implementato un processo di build appropriato.

Come valutare un tema prima dell'acquisto

Controllare il file theme.yml

Il file theme.yml è il cuore della configurazione di un tema PrestaShop. Definisce il nome del tema, la versione, la compatibilità, gli hook supportati, la configurazione del layout e la gestione delle risorse. Cerca una dichiarazione chiara della compatibilità con la versione di PrestaShop, un elenco degli hook registrati e dei moduli assegnati, le definizioni di layout per i diversi tipi di pagina (prodotto, categoria, CMS, checkout) e le dichiarazioni delle risorse che specificano quali file vengono caricati globalmente e quali su pagine specifiche. Se il file theme.yml è minimale o manca di sezioni chiave, il tema è stato costruito senza seguire le linee guida di sviluppo dei temi di PrestaShop.

Test con la modalità debug

Se puoi installare il tema in un ambiente di test, abilita immediatamente la modalità debug di PrestaShop impostando _PS_MODE_DEV_ su true in config/defines.inc.php. Questo rivela errori PHP, warning e notice nascosti in modalità produzione. Un tema ben costruito non dovrebbe generare alcun errore e un numero minimo di warning. Se la modalità debug produce una valanga di errori, il tema ha problemi di qualità del codice che causeranno problemi in produzione.

Verificare la reputazione dello sviluppatore

Fai ricerche sullo sviluppatore prima dell'acquisto. Controlla quanti temi ha pubblicato, quanto recentemente sono stati aggiornati e cosa dicono le recensioni. Presta attenzione alle recensioni negative che menzionano bug, funzionalità rotte dopo gli aggiornamenti o supporto non reattivo. Un changelog dettagliato che documenta correzioni di bug e aggiornamenti di compatibilità indica una manutenzione attiva. Un changelog assente suggerisce che il tema potrebbe essere abbandonato dopo la vendita iniziale.

Verifica della compatibilità

Verifica sempre che il tema dichiari esplicitamente la compatibilità con la tua versione esatta di PrestaShop. Frasi come "compatibile con PrestaShop 1.7 e versioni successive" sono troppo vaghe. Vuoi numeri di versione specifici elencati come testati. Verifica controllando quando il tema è stato aggiornato l'ultima volta. Se il tema dichiara compatibilità con PrestaShop 8.1 ma è stato aggiornato l'ultima volta prima del rilascio di quella versione, la dichiarazione è nel migliore dei casi non verificata.

Il vero costo di un tema scadente

Un tema mal costruito ha costi concreti e misurabili. I problemi di prestazioni riducono il punteggio PageSpeed, influenzando il posizionamento e le conversioni (ogni secondo aggiuntivo di tempo di caricamento riduce le conversioni del 7-10%). Il supporto hook mancante richiede lavoro di sviluppo a pagamento per ogni nuovo modulo. La scarsa accessibilità crea responsabilità legale. La mancanza di supporto per i temi figlio trasforma ogni aggiornamento in un merge manuale. I conflitti jQuery rompono i moduli, causando vendite perse per pulsanti "Aggiungi al carrello" non funzionanti e form di pagamento difettosi.

Quando valuti i temi, considera il costo totale di proprietà. Un tema economico che richiede centinaia di euro in tempo di sviluppatore è molto più costoso di un tema più caro che funziona correttamente fin dall'inizio.

Checklist riepilogativa

Prima di acquistare qualsiasi tema PrestaShop, segui questa checklist. Apri la demo e controlla la scheda Network per richieste HTTP eccessive (oltre 50 è preoccupante, oltre 80 è un segnale di allarme). Ispeziona gli elementi per individuare stili inline che dovrebbero essere in classi CSS. Testa l'intero flusso di acquisto su un dispositivo mobile reale. Cerca testo hardcoded che non può essere tradotto. Controlla la console del browser per errori JavaScript e versioni multiple di jQuery. Verifica che gli hook standard di PrestaShop siano presenti nei template. Conferma che la creazione di temi figlio sia documentata e supportata. Esegui un audit di accessibilità Lighthouse e verifica la navigabilità da tastiera. Esamina le dimensioni totali del trasferimento per CSS, JavaScript e font. Leggi il file theme.yml per una struttura di configurazione appropriata. Controlla lo storico degli aggiornamenti dello sviluppatore e la reattività del supporto. Verifica la compatibilità esplicita con la tua versione di PrestaShop.

Un tema che supera tutti questi controlli non è garantito essere perfetto, ma ha superato la barra di qualità di base che separa il lavoro professionale dallo sviluppo amatoriale. Un tema che fallisce più controlli ti causerà problemi. Il tempo dedicato alla valutazione prima dell'acquisto fa risparmiare molto più tempo, denaro e frustrazione rispetto al dover affrontare le conseguenze di un tema mal costruito quando è già in funzione nel tuo negozio.

Leggi la risposta completa

Il costo nascosto del sovraccarico di font nei temi PrestaShop

Apri i DevTools del tuo browser, passa alla scheda Network, filtra per "Font" e ricarica il tuo negozio PrestaShop. Se vedi più di tre o quattro file font in fase di download, hai un problema che sta silenziosamente facendoti perdere clienti. La maggior parte dei temi PrestaShop include un numero impressionante di risorse font che il negozio medio non utilizza mai, e ciascuna di esse ritarda il momento in cui i visitatori possono effettivamente leggere i tuoi contenuti.

Il sovraccarico di font è uno dei problemi di prestazioni più trascurati in PrestaShop. I proprietari di negozi dedicano ore a ottimizzare le immagini, abilitare il CCC (Combine, Compress, Cache) e regolare le configurazioni del server, eppure ignorano il fatto che il loro tema sta caricando 800KB o più di file font ad ogni singolo caricamento di pagina. Questo articolo spiega esattamente perché questo accade, come verificare il caricamento dei font e cosa fare per risolvere il problema.

Come i temi PrestaShop includono i font

I temi PrestaShop vengono distribuiti come pacchetti autonomi. Quando uno sviluppatore di temi costruisce un tema, vuole che funzioni immediatamente per il maggior numero possibile di negozi. Questo significa che include ogni variante di font e libreria di icone di cui potrebbe ipoteticamente avere bisogno. Il risultato è un tema che include molte più risorse font di quante un singolo negozio potrà mai utilizzare.

Un tipico tema PrestaShop include tre categorie di font. Primo, ci sono i font di visualizzazione utilizzati per intestazioni, corpo del testo ed elementi dell'interfaccia utente. Questi sono solitamente Google Fonts come Roboto, Open Sans, Lato o Montserrat. Secondo, ci sono i font di icone come FontAwesome, Material Icons o set di icone specifici del tema. Terzo, ci sono font decorativi o di fallback che il tema utilizza per componenti specifici come banner, badge o sezioni promozionali.

Il problema si amplifica perché ogni famiglia di font viene tipicamente fornita in più pesi e stili. Un singolo font come Roboto potrebbe includere Regular (400), Medium (500), Bold (700) e le loro varianti corsivo, ciascuna come file WOFF2 separato. Moltiplicato per due o tre famiglie di font più una libreria di icone, si raggiungono rapidamente da 12 a 15 file font individuali che vengono caricati su ogni pagina.

Il problema FontAwesome

FontAwesome merita una sezione dedicata perché è il singolo maggior responsabile dei problemi di prestazioni legati ai font nei temi PrestaShop. La libreria completa di FontAwesome 5 pesa circa 150KB per il solo file webfont, più altri 60-80KB per il suo CSS. FontAwesome 6 è ancora più grande. La libreria contiene oltre 1.600 icone, ma il negozio PrestaShop medio ne utilizza forse 20 o 30.

Questo significa che stai costringendo ogni visitatore a scaricare oltre 200KB di dati font e CSS solo per poter visualizzare un'icona del carrello, una lente di ricerca e qualche logo dei social media. Questo è un compromesso assurdo, e accade perché gli sviluppatori di temi trovano più facile includere l'intera libreria piuttosto che creare un sottoinsieme per le esigenze specifiche di ogni negozio.

Il tema Classic in PrestaShop 1.7 e 8.x include FontAwesome 4.7, che è leggermente più piccolo ma contiene comunque centinaia di icone che non utilizzerai mai. Il tema Hummingbird in PrestaShop 8.x ha abbandonato FontAwesome a favore delle icone SVG, il che rappresenta un miglioramento significativo, ma molti temi e moduli di terze parti si basano ancora su FontAwesome e caricano la propria copia in aggiunta a quanto già fornito dal tema.

Google Fonts e la tassa sulle prestazioni

Google Fonts è il servizio di web font più popolare, e i temi PrestaShop ne fanno ampio uso. Tuttavia, caricare Google Fonts nel modo predefinito crea una catena di richieste che penalizzano le prestazioni.

Quando il tuo tema carica Google Fonts tramite il tag link standard, il browser deve prima connettersi a fonts.googleapis.com per scaricare il file CSS. Quel file CSS dice poi al browser di scaricare i file font effettivi da fonts.gstatic.com. Ciascuna di queste connessioni richiede risoluzione DNS, handshake TCP e negoziazione TLS. Su connessioni mobili, questa catena può aggiungere 300-500ms di ritardo prima che un singolo carattere di testo venga renderizzato sullo schermo.

Peggio ancora, il CSS di Google Fonts utilizza il descrittore font-display impostato su "swap" per impostazione predefinita dal 2019, ma molti temi più vecchi fanno ancora riferimento a URL CSS di Google Fonts che precedono questa modifica. Senza font-display: swap, il browser può nascondere tutto il testo sulla pagina fino al download del font, creando il temuto Flash of Invisible Text (FOIT) in cui i visitatori vedono una pagina bianca per uno o tre secondi.

C'è anche una preoccupazione sulla privacy. Caricare font dal CDN di Google significa che Google riceve informazioni su ogni visitatore del tuo negozio, incluso il suo indirizzo IP e le pagine che visita. Secondo il GDPR, questo richiede il consenso esplicito, e un tribunale tedesco ha stabilito a gennaio 2022 che l'utilizzo di Google Fonts senza consenso viola il GDPR, con conseguenti sanzioni.

Come verificare il caricamento dei font

Prima di poter risolvere il problema, devi capire esattamente quali font il tuo tema sta caricando e quali ti servono effettivamente. Ecco un approccio sistematico.

Apri Chrome DevTools (F12), vai alla scheda Network e seleziona la casella "Disabilita cache". Ricarica la pagina e filtra per "Font" nella barra del filtro. Vedrai ogni file font che il browser scarica. Annota i nomi dei file, le dimensioni e la colonna Initiator che ti dice quale file CSS ha richiesto ogni font.

Successivamente, utilizza la scheda Coverage nei DevTools (Ctrl+Shift+P, poi digita "Coverage"). Avvia una registrazione della copertura e naviga nel tuo negozio. La scheda Coverage ti mostra esattamente quanto di ogni file CSS viene effettivamente utilizzato. Per il CSS di FontAwesome, vedrai tipicamente il 90% o più contrassegnato come inutilizzato.

Puoi anche utilizzare l'audit Lighthouse nei DevTools. Esegui un audit delle prestazioni e cerca le opportunità "Riduci CSS non utilizzato" e "Assicurati che il testo rimanga visibile durante il caricamento dei webfont". Lighthouse segnalerà specificamente i problemi di prestazioni legati ai font.

Per un'analisi più approfondita, utilizza WebPageTest (webpagetest.org) per eseguire un test da una connessione mobile. Guarda il grafico a cascata e trova le richieste dei font. Nota quando iniziano a caricarsi rispetto alle altre risorse e quanto tempo impiegano. Su una connessione 3G, i ritardi nel caricamento dei font diventano dolorosamente evidenti.

Rimozione dei font inutilizzati passo dopo passo

Una volta che sai quali font il tuo tema carica e quali effettivamente ti servono, è il momento di rimuovere l'eccesso. L'approccio varia a seconda dell'architettura del tuo tema.

Per i temi che caricano Google Fonts tramite un tag link nel template dell'header, trova il file template che contiene il riferimento a Google Fonts. Nella maggior parte dei temi, questo si trova in templates/layout/head.tpl o in un file simile. Se stai utilizzando un tema figlio, copia questo template nella directory del tuo tema figlio prima di modificarlo. Rimuovi o modifica il link di Google Fonts per includere solo i pesi e le famiglie che utilizzi effettivamente.

Per FontAwesome, controlla se il tuo tema lo carica tramite un file CSS nella directory assets/css oppure tramite un link CDN. Se è un file locale, hai due opzioni. Puoi sostituire il pacchetto completo di FontAwesome con un sottoinsieme che contiene solo le icone che utilizzi, oppure puoi sostituire completamente l'utilizzo del font di icone con SVG inline.

Per creare un sottoinsieme di FontAwesome, utilizza uno strumento come IcoMoon (icomoon.io) o Fontello (fontello.com). Questi strumenti ti permettono di selezionare solo le icone specifiche di cui hai bisogno e generano un file font personalizzato che potrebbe pesare 5-10KB invece di 150KB. Dovrai aggiornare i nomi delle classi CSS se lo strumento ne genera di diversi, ma la maggior parte permette di mantenere i nomi delle classi originali di FontAwesome.

Per Google Fonts, controlla ogni file CSS nel tuo tema per le dichiarazioni @font-face. Gli sviluppatori di temi a volte importano i font direttamente nel CSS anziché attraverso il template dell'head. Utilizza la ricerca dei DevTools (Ctrl+Shift+F) per cercare tra tutte le risorse caricate "@font-face" e "fonts.googleapis.com".

Implementazione di font-display: swap

Se mantieni dei web font, assicurati assolutamente che utilizzino il descrittore font-display: swap. Questo dice al browser di mostrare immediatamente il testo utilizzando un font di sistema di fallback mentre il web font viene scaricato in background. Una volta che il web font è pronto, il browser lo sostituisce. Questo elimina il FOIT e garantisce che i tuoi contenuti siano leggibili istantaneamente.

Per Google Fonts caricati tramite CDN, aggiungi il parametro display=swap all'URL. Ad esempio, cambia fonts.googleapis.com/css2?family=Roboto:wght@400;700 in fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap. Nota che Google ha aggiunto questo parametro per impostazione predefinita nel 2019, ma molti temi PrestaShop utilizzano ancora formati URL più vecchi.

Per i font self-hosted con dichiarazioni @font-face nel tuo CSS, aggiungi font-display: swap a ogni blocco @font-face. Apri il file CSS del tuo tema che contiene le regole @font-face e aggiungi la proprietà. Va all'interno del blocco @font-face insieme a font-family, src e font-weight.

Tieni presente che font-display: swap può causare un Flash of Unstyled Text (FOUT) in cui il testo appare brevemente nel font di fallback prima di passare al web font. Questa è un'esperienza molto migliore rispetto al testo invisibile, ma puoi minimizzare l'effetto visivo scegliendo font di fallback che corrispondano strettamente alle metriche del tuo web font. Le proprietà CSS size-adjust, ascent-override e descent-override aiutano in questo.

Self-hosting dei font vs caricamento da CDN

Ospitare i font sul proprio server anziché caricarli dal CDN di Google offre diversi vantaggi significativi per i negozi PrestaShop.

Le prestazioni migliorano perché elimini la risoluzione DNS aggiuntiva e la connessione ai server di Google. I tuoi font vengono caricati dallo stesso dominio delle altre risorse, il che significa che il browser può riutilizzare le connessioni esistenti. Con HTTP/2 o HTTP/3, tutti i file font possono essere scaricati simultaneamente tramite un'unica connessione.

La conformità alla privacy diventa più semplice perché i dati dei visitatori non vengono più inviati a Google. Questo elimina completamente una preoccupazione relativa al GDPR, e non è necessario aggiungere Google Fonts al banner del consenso ai cookie.

L'affidabilità migliora perché non dipendi da un servizio esterno. Se il CDN di Google ha un problema (raro ma succede), i tuoi font continuano a caricarsi.

Per ospitare Google Fonts in proprio, utilizza lo strumento google-webfonts-helper (gwfh.mranftl.com/fonts) che fornisce un'interfaccia semplice per scaricare qualsiasi Google Font in formato WOFF2 con il CSS @font-face corretto. Scarica solo i pesi e gli stili di cui hai bisogno, posiziona i file nella directory assets/fonts del tuo tema e aggiungi il CSS @font-face al foglio di stile del tema.

L'unico potenziale svantaggio del self-hosting è la perdita della possibilità di un cache hit se il visitatore ha già caricato lo stesso font dal CDN di Google su un altro sito. Tuttavia, i browser hanno in gran parte eliminato questo caching tra siti per motivi di privacy dal 2020, quindi questo vantaggio non esiste più nella pratica.

Font subsetting: l'opzione radicale

Il font subsetting significa rimuovere i caratteri di cui non hai bisogno da un file font. Un tipico web font latino include caratteri per dozzine di lingue, molte delle quali il tuo negozio non utilizza. Creando un sottoinsieme con solo i caratteri necessari al tuo negozio, puoi ridurre le dimensioni dei file font del 50-70%.

Lo strumento pyftsubset della libreria Python fonttools è il modo più affidabile per creare sottoinsiemi di font. Puoi specificare esattamente quali intervalli Unicode includere. Per un negozio che opera solo in italiano, potresti creare un sottoinsieme con Latin di base (U+0020-007F) più Latin-1 Supplement (U+00A0-00FF) per i simboli di valuta e i caratteri accentati.

Per i negozi che operano in più lingue, devi essere più attento. Includi gli intervalli Unicode per tutte le lingue supportate dal tuo negozio. Il CSS di Google Fonts in realtà fa questo automaticamente con i descrittori unicode-range, caricando sottoinsiemi di caratteri su richiesta, ma i font self-hosted necessitano di subsetting manuale.

Un approccio più semplice è utilizzare esclusivamente il formato WOFF2 e abbandonare il supporto per i formati più vecchi. WOFF2 utilizza la compressione Brotli e produce file del 30% più piccoli rispetto a WOFF. Ogni browser moderno supporta WOFF2, quindi a meno che tu non debba supportare Internet Explorer 11, non c'è motivo di includere formati WOFF, TTF o EOT. Molti temi PrestaShop includono ancora tutti e quattro i formati per una retrocompatibilità che non è più necessaria.

Stack di font di sistema: l'alternativa a costo zero

La soluzione più radicale ai problemi di prestazioni dei font è non utilizzare affatto web font. I sistemi operativi moderni includono font di alta qualità che hanno un aspetto eccellente sullo schermo. Uno stack di font di sistema utilizza qualunque font fornito dal sistema operativo, il che significa zero file font da scaricare e rendering istantaneo del testo.

Lo stack moderno di font di sistema appare così: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif. Questo ti fornisce San Francisco sui dispositivi Apple, Segoe UI su Windows e Roboto su Android. Tutti questi sono font sans-serif puliti, moderni e altamente leggibili.

GitHub, Bootstrap 5 e molti siti web ad alte prestazioni utilizzano stack di font di sistema. La differenza visiva tra un font di sistema e un Google Font come Open Sans o Roboto è minima, specialmente per il corpo del testo. La maggior parte dei tuoi clienti non noterà né si preoccuperà se il tuo negozio utilizza Roboto caricato da un server o Roboto già installato sul loro telefono Android.

Per implementare uno stack di font di sistema in PrestaShop, devi modificare il CSS del tuo tema per sostituire le dichiarazioni font-family esistenti, rimuovere le regole @font-face e i tag link di Google Fonts, e cancellare i file font dalla directory assets del tema. Se stai utilizzando un tema figlio, puoi sovrascrivere le dichiarazioni font del tema genitore senza modificare i file del tema genitore.

E i font di icone?

Se rimuovi FontAwesome o un altro font di icone, hai bisogno di un'alternativa per visualizzare le icone. L'approccio moderno migliore è l'SVG inline. Le icone SVG vengono renderizzate in modo nitido a qualsiasi dimensione, possono essere stilizzate con CSS e aggiungono peso solo per le icone specifiche che utilizzi, invece di caricare un'intera libreria di icone.

Il tema Hummingbird di PrestaShop utilizza nativamente le icone SVG, ed è una delle ragioni per cui offre prestazioni migliori rispetto a Classic. Se il tuo tema utilizza FontAwesome, puoi sostituire le singole icone con SVG provenienti da fonti come Heroicons, Feather Icons, o anche dai file SVG di FontAwesome stesso (che sono disponibili separatamente dalla versione font).

Per un negozio PrestaShop, hai tipicamente bisogno di meno di 30 icone uniche: carrello, ricerca, account utente, cuore/lista dei desideri, frecce, logo dei social media e alcune icone specifiche per le categorie. Come SVG inline, queste potrebbero totalizzare 10-15KB, rispetto ai 150-200KB dell'intero font e CSS di FontAwesome.

Misurare l'impatto

Dopo aver rimosso i font inutilizzati, misura il miglioramento. Esegui Lighthouse prima e dopo, confrontando il punteggio Performance, il First Contentful Paint (FCP) e il Largest Contentful Paint (LCP). L'ottimizzazione dei font migliora tipicamente l'FCP di 200-500ms sulle connessioni mobili.

Controlla la dimensione totale del trasferimento nella scheda Network dei DevTools. Un negozio PrestaShop ben ottimizzato dovrebbe trasferire meno di 50KB di dati font in totale. Se passi ai font di sistema, quel numero scende a zero.

Verifica anche che il tuo negozio abbia ancora l'aspetto corretto. Controlla ogni tipo di pagina: homepage, categoria, prodotto, carrello e checkout. Alcuni temi utilizzano font specifici per elementi specifici, e la rimozione di un font potrebbe causare un rendering di fallback inaspettato. Testa sempre accuratamente prima di distribuire le modifiche ai font in produzione.

Riepilogo: checklist per il caricamento dei font

Verifica il caricamento attuale dei font con la scheda Network dei DevTools filtrata per i font. Identifica quali font vengono effettivamente utilizzati controllando la copertura CSS. Rimuovi qualsiasi famiglia o peso di Google Fonts che non utilizzi. Sostituisci i font di icone completi con versioni sottoinsieme o SVG inline. Aggiungi font-display: swap a tutte le dichiarazioni @font-face rimanenti. Ospita i font in proprio invece di caricarli dal CDN di Google. Considera l'utilizzo esclusivo di WOFF2 per eliminare i formati più vecchi e pesanti. Valuta se i font di sistema potrebbero sostituire completamente i tuoi web font. Misura prima e dopo con Lighthouse e WebPageTest. L'obiettivo è semplice: carica solo ciò di cui hai bisogno, caricalo in modo efficiente e non far mai aspettare i tuoi visitatori per font che non possono vedere.

Leggi la risposta completa

Due temi ufficiali, due filosofie diverse

PrestaShop include due temi ufficiali: Classic e Hummingbird. Classic è il tema predefinito dal rilascio di PrestaShop 1.7 nel 2016. Hummingbird è arrivato con PrestaShop 8.x come alternativa moderna progettata per le prestazioni e la preparazione al futuro. La scelta tra i due non è semplicemente una questione di quale abbia un aspetto migliore. I due temi rappresentano approcci fondamentalmente diversi all'architettura front-end, e la tua scelta influenza le prestazioni, la compatibilità con i moduli, l'impegno di personalizzazione e la manutenibilità a lungo termine.

Questo articolo fornisce un confronto approfondito basato sull'architettura, dati prestazionali reali, considerazioni pratiche e le situazioni specifiche in cui ciascun tema ha più senso. Che tu stia avviando un nuovo negozio o considerando una migrazione, questo ti aiuterà a prendere una decisione informata.

Architettura: cosa è cambiato e perché

Classic è stato costruito su Bootstrap 4, jQuery e template Smarty. Segue un approccio tradizionale di rendering lato server in cui il server genera pagine HTML complete e le invia al browser. JavaScript viene utilizzato principalmente per elementi interattivi come il carrello, la pagina prodotto e il checkout. Il CSS viene compilato da file Sass e distribuito come un unico foglio di stile di grandi dimensioni.

Hummingbird è stato costruito come una reimpostazione da zero. Utilizza Bootstrap 5, abbandona jQuery in favore di JavaScript vanilla e introduce un'architettura basata su componenti. Il CSS è più modulare, il JavaScript è più leggero e l'impronta complessiva delle risorse è significativamente più piccola.

La rimozione di jQuery è il cambiamento architetturale più importante. jQuery aggiungeva circa 87KB (30KB compressi con gzip) ad ogni caricamento di pagina e incoraggiava uno stile di programmazione in cui i moduli manipolavano liberamente il DOM senza coordinamento. Hummingbird sostituisce jQuery con le API native dei browser moderni come fetch, querySelector, classList e la delega degli eventi. Questo significa che il tema stesso è più veloce, ma i moduli che dipendono da jQuery necessitano di aggiornamenti.

Bootstrap 5 porta i propri cambiamenti. Elimina jQuery come dipendenza (allineandosi con l'approccio di Hummingbird), utilizza proprietà personalizzate CSS (variabili) per una tematizzazione più facile, migliora il sistema a griglia con utilità responsive migliorate e aggiorna i pattern di markup dei componenti. Il passaggio da Bootstrap 4 a 5 influenza qualsiasi CSS personalizzato o override dei template che faccia riferimento a classi specifiche di Bootstrap.

Confronto prestazionale: numeri reali

Le prestazioni sono la ragione principale per cui PrestaShop ha creato Hummingbird, e i numeri supportano la decisione. Testando entrambi i temi su un'installazione identica di PrestaShop 8.1 con gli stessi prodotti, moduli e configurazione del server si rilevano differenze significative.

Su una tipica pagina prodotto misurata con Lighthouse su una connessione mobile simulata, Classic ottiene un punteggio nell'intervallo 45-55 per le Prestazioni, mentre Hummingbird ottiene un punteggio nell'intervallo 65-75. Le metriche specifiche raccontano una storia più chiara.

Il First Contentful Paint (FCP) migliora di circa 0,5-1,0 secondi con Hummingbird. Questo è dovuto principalmente al payload CSS più piccolo e all'assenza di jQuery che blocca il rendering. Il Largest Contentful Paint (LCP) migliora di un margine simile perché il percorso critico di rendering è più breve.

Il Total Blocking Time (TBT) vede il miglioramento più drammatico. Il JavaScript basato su jQuery di Classic crea un blocco significativo del thread principale mentre il browser analizza ed esegue la libreria più tutti gli script dei moduli dipendenti da jQuery. L'approccio JavaScript vanilla di Hummingbird riduce il TBT del 40-60% nelle configurazioni tipiche.

Il Cumulative Layout Shift (CLS) è all'incirca equivalente tra i due temi quando configurati correttamente, poiché la stabilità del layout dipende più dalle dimensioni delle immagini e dall'implementazione del lazy loading che dalla scelta del framework.

La dimensione totale del trasferimento racconta un'altra parte della storia. Un'installazione predefinita di Classic trasferisce circa 350-450KB di CSS e JavaScript al primo caricamento della pagina. Hummingbird riduce questo a 200-300KB. La differenza si accumula durante l'intera sessione di navigazione mentre i visitatori navigano nel tuo negozio.

Questi numeri presuppongono un'installazione pulita. In pratica, i moduli di terze parti spesso aggiungono il proprio CSS e JavaScript, il che può restringere o ampliare il divario a seconda di quanto bene quei moduli siano ottimizzati per ciascun tema.

Compatibilità dei moduli: il problema principale

Questo è il punto in cui i vantaggi di Hummingbird vengono accompagnati da un'importante avvertenza. Molti moduli PrestaShop sono stati costruiti pensando all'architettura di Classic. Dipendono da jQuery, utilizzano pattern di markup di Bootstrap 4 e presuppongono strutture di template specifiche fornite da Classic.

Quando installi questi moduli su Hummingbird, diverse cose possono rompersi. Le funzionalità JavaScript che si basano su jQuery falliranno silenziosamente o genereranno errori. Le finestre modali, i dropdown e altri componenti di Bootstrap 4 potrebbero non renderizzarsi correttamente con il markup e i nomi delle classi modificati di Bootstrap 5. Gli override dei template che presuppongono la struttura dei template di Classic non funzioneranno con i template riorganizzati di Hummingbird.

La gravità di questo problema dipende dal tuo stack di moduli. I moduli core di PrestaShop sono compatibili con entrambi i temi. I moduli di terze parti ben mantenuti da sviluppatori attivi supportano tipicamente Hummingbird. Tuttavia, moduli più vecchi, moduli di nicchia o moduli di sviluppatori che hanno smesso di aggiornare i loro prodotti potrebbero funzionare solo con Classic.

Prima di scegliere Hummingbird, dovresti testare ogni modulo che intendi utilizzare. Installali in un ambiente di staging con Hummingbird attivo e testa accuratamente ogni funzionalità. Presta particolare attenzione alle funzionalità dipendenti da JavaScript come i carrelli AJAX, i campi di personalizzazione prodotto, le visualizzazioni rapide e i passaggi del checkout.

Alcuni sviluppatori di moduli forniscono file di template separati per Classic e Hummingbird. Quando vedi directory come views/templates/hook/classic/ e views/templates/hook/hummingbird/ in un modulo, quel modulo supporta esplicitamente entrambi i temi. Questo è lo standard di riferimento per la compatibilità.

Smarty vs Twig: considerazioni per il futuro

PrestaShop ha annunciato l'intenzione di passare da Smarty a Twig come motore di template per il front office. Questa transizione è stata discussa per anni ed è parzialmente implementata nel back office. Hummingbird è progettato tenendo conto di questa transizione, sebbene in PrestaShop 8.x e 9.x entrambi i temi utilizzino ancora Smarty per i template del front office.

La rilevanza per la tua scelta del tema è indiretta ma importante. La struttura dei template di Hummingbird è organizzata in un modo che renderà più fluida l'eventuale migrazione da Smarty a Twig. Se costruisci personalizzazioni estese sulla struttura dei template di Classic, potresti dover affrontare un impegno di migrazione maggiore quando (non se) PrestaShop completerà la transizione a Twig.

Detto ciò, questa transizione è stata "in arrivo" per diversi anni. Prendere una decisione oggi basandosi esclusivamente su un futuro cambio del motore di template è prematuro. Scegli in base alle esigenze attuali e concrete e accetta che sarà necessario un certo impegno di migrazione indipendentemente dal tema scelto quando avverrà la transizione a Twig.

Approccio alla personalizzazione

La personalizzazione di Classic è ben documentata e ampiamente compresa. Esistono centinaia di tutorial, migliaia di post nei forum e anni di conoscenza della community sulla modifica di Classic. Il tema utilizza Sass semplice per lo stile, jQuery tradizionale per l'interattività e template Smarty facili da leggere e modificare.

La personalizzazione di Hummingbird richiede competenze aggiornate. Devi avere dimestichezza con il CSS moderno (proprietà personalizzate, selettori moderni, container queries), JavaScript vanilla (senza la stampella di jQuery) e l'approccio utility-first di Bootstrap 5. La curva di apprendimento è più ripida se il tuo team è abituato allo sviluppo basato su jQuery.

Tuttavia, le proprietà personalizzate CSS di Hummingbird rendono certi tipi di personalizzazione molto più semplici rispetto a Classic. Vuoi cambiare il colore primario nell'intero tema? Modifica una singola proprietà personalizzata CSS. Con Classic, dovevi rintracciare ogni variabile Sass, ricompilare e gestire i conflitti di specificità.

Hummingbird utilizza anche una struttura HTML più semantica, che rende più facile selezionare gli elementi con i selettori CSS e migliora l'accessibilità. I file dei template sono meglio organizzati con una separazione più chiara delle responsabilità.

Supporto per i temi figlio

Entrambi i temi supportano i temi figlio (child theme), che è il metodo raccomandato per personalizzare un tema PrestaShop senza modificare direttamente i file del tema genitore. I temi figlio ti permettono di sovrascrivere template specifici, aggiungere CSS e JavaScript personalizzati e mantenere le personalizzazioni attraverso gli aggiornamenti del tema.

Il meccanismo dei temi figlio di Classic è maturo e ben testato. Crei una directory per il tema figlio, definisci un theme.yml che fa riferimento a Classic come genitore e sovrascrivi selettivamente i file che devi modificare. Questo flusso di lavoro è stabile da PrestaShop 1.7.

Il supporto dei temi figlio di Hummingbird funziona allo stesso modo a livello di framework, ma presenta alcune differenze pratiche. Poiché i template di Hummingbird sono strutturati diversamente, gli override dei temi figlio basati su Classic non possono essere riutilizzati. È necessario creare nuovi override basati sulla struttura dei template di Hummingbird.

PrestaShop 8.x ha migliorato la gestione dei temi figlio in generale, rendendo più facile sovrascrivere le risorse (CSS e JavaScript) e i template parziali. Questi miglioramenti beneficiano allo stesso modo sia i temi figlio di Classic che quelli di Hummingbird.

Se stai commissionando un tema personalizzato a uno sviluppatore, partire da Hummingbird come genitore è la scelta migliore a lungo termine. L'architettura più pulita significa meno debito tecnico, e l'approccio CSS moderno significa meno override necessari per le personalizzazioni comuni.

Percorso di migrazione: da Classic a Hummingbird

Se stai attualmente utilizzando Classic e stai considerando il passaggio a Hummingbird, ecco cosa comporta effettivamente la migrazione.

Gli override dei template devono essere ricostruiti da zero. Non puoi semplicemente copiare i tuoi override dei template di Classic in un tema figlio di Hummingbird. La struttura dei file dei template, i nomi delle variabili e i nomi dei blocchi sono diversi. Devi esaminare ogni override, capire cosa realizza e ricrearlo utilizzando la struttura dei template di Hummingbird.

Il CSS personalizzato necessita di revisione e probabilmente di una significativa rielaborazione. Se il tuo CSS punta a classi di Bootstrap 4, quei nomi di classe potrebbero essere cambiati in Bootstrap 5. Se il tuo CSS utilizza pattern dipendenti da jQuery (come la stilizzazione di elementi basata su classi aggiunte da jQuery), questi si romperanno. Se il tuo CSS utilizza nomi di classe specifici del tema Classic, questi potrebbero non esistere in Hummingbird.

Il JavaScript personalizzato deve essere riscritto. Qualsiasi codice jQuery deve essere convertito in JavaScript vanilla. Questa è spesso la parte più dispendiosa in termini di tempo della migrazione perché il codice jQuery tende ad essere profondamente intrecciato con pattern di manipolazione del DOM che devono essere ripensati.

La compatibilità dei moduli deve essere verificata per ogni modulo installato. Come discusso sopra, i moduli che dipendono da jQuery o Bootstrap 4 potrebbero necessitare di aggiornamenti o sostituzioni.

Una tempistica realistica per la migrazione di un negozio Classic moderatamente personalizzato a Hummingbird è di 40-80 ore di lavoro dello sviluppatore. Questo non è un progetto del fine settimana. Pianificalo come un vero e proprio impegno di sviluppo con un ambiente di staging, test approfonditi e un piano di rollback.

Quando scegliere Classic

Scegli Classic quando il tuo negozio dipende da moduli di terze parti più vecchi che non sono stati aggiornati per la compatibilità con Hummingbird. Sceglilo quando il tuo team di sviluppo è più a suo agio con jQuery e Bootstrap 4 e non hai il budget per la riqualificazione o l'assunzione. Sceglilo quando stai costruendo con scadenze strette e hai bisogno della selezione più ampia possibile di temi e moduli compatibili dal marketplace di PrestaShop.

Classic è anche la scelta più sicura per i negozi che utilizzano PrestaShop 1.7.x o le prime versioni 8.0.x. Hummingbird è stato introdotto successivamente nel ciclo 8.x e potrebbe non essere completamente disponibile o stabile sulle versioni più vecchie di PrestaShop.

Se il tuo negozio funziona già su Classic con personalizzazioni estese e prestazioni adeguate, potrebbe non esserci un motivo convincente per migrare. I guadagni prestazionali di Hummingbird sono reali ma potrebbero non giustificare l'impegno della migrazione se il tuo negozio si carica già rapidamente e converte bene.

Quando scegliere Hummingbird

Scegli Hummingbird quando avvii un nuovo negozio PrestaShop 8.x o 9.x da zero. I vantaggi prestazionali sono gratuiti quando non hai personalizzazioni legacy da migrare. Sceglilo quando le prestazioni sono una priorità assoluta per la tua attività, in particolare se il tuo pubblico è prevalentemente composto da utenti mobili su connessioni più lente dove ogni kilobyte conta.

Scegli Hummingbird quando vuoi preparare il tuo negozio per il futuro. Man mano che PrestaShop continua ad evolversi verso pratiche front-end moderne, Hummingbird riceverà la maggiore attenzione nello sviluppo e sarà il primo a beneficiare delle nuove funzionalità.

Sceglilo quando hai sviluppatori a proprio agio con JavaScript e CSS moderni. L'architettura di Hummingbird è più pulita e più manutenibile per i team con competenze front-end attuali.

E sceglilo quando ti sta a cuore l'accessibilità. L'HTML semantico, gli attributi ARIA e il supporto per la navigazione da tastiera di Hummingbird sono notevolmente migliori rispetto a quelli di Classic. Se il tuo negozio deve soddisfare gli standard di accessibilità WCAG, Hummingbird ti fornisce un punto di partenza migliore.

La questione dei temi di terze parti

Molti proprietari di negozi saltano entrambi i temi ufficiali e acquistano un tema di terze parti dal marketplace PrestaShop Addons o da venditori indipendenti. Questi temi sono quasi sempre basati sull'architettura di Classic perché Classic è disponibile da molto più tempo e rappresenta la base installata più ampia.

Se stai utilizzando un tema di terze parti, la questione Classic vs Hummingbird è in gran parte accademica per il tuo negozio attuale. Lo sviluppatore del tuo tema ha preso le decisioni architetturali per te. Tuttavia, quando valuti nuovi temi di terze parti, verifica se sono costruiti sulle fondamenta di Classic o di Hummingbird. I temi costruiti su Hummingbird avranno prestazioni migliori e manterranno la compatibilità più a lungo.

Fai attenzione ai temi di terze parti che dichiarano di essere "basati su Hummingbird" ma in realtà ne prendono solo lo stile visivo mantenendo sotto l'architettura dipendente da jQuery di Classic. Controlla le dipendenze JavaScript e il framework CSS del tema per verificare.

Verdetto: non c'è una risposta sbagliata, ma ce n'è una migliore

Per i nuovi negozi su PrestaShop 8.x o versioni successive, Hummingbird è la raccomandazione chiara. È più veloce, più moderno, meglio mantenuto e più pronto per il futuro. La preoccupazione sulla compatibilità dei moduli sta diminuendo man mano che l'ecosistema si adegua, e partire da zero significa non avere costi di migrazione legacy.

Per i negozi esistenti che utilizzano Classic con personalizzazioni significative, la decisione richiede un'analisi costi-benefici. Calcola onestamente l'impegno della migrazione, misura le tue prestazioni attuali per comprendere il potenziale guadagno e decidi se il miglioramento giustifica l'investimento. A volte la risposta è sì, a volte no, e a volte la risposta giusta è aspettare il prossimo grande redesign per effettuare il passaggio.

Indipendentemente dal tema che scegli, i principi di buone prestazioni front-end si applicano allo stesso modo: minimizza le dimensioni delle risorse, effettua il lazy-load dei contenuti sotto la piega, ottimizza le immagini e controlla regolarmente la velocità della pagina. Un negozio Classic ben ottimizzato supererà sempre un negozio Hummingbird configurato male. Il tema fornisce le fondamenta, ma l'esecuzione determina il risultato.

Leggi la risposta completa

Il tuo tema è probabilmente più lento di quanto pensi

Ogni proprietario di un negozio PrestaShop ha un'opinione sulla velocità del proprio tema, ma pochissimi dispongono di dati concreti. Dire "il mio negozio sembra veloce" è privo di significato quando Google sta misurando i tuoi Core Web Vitals al millisecondo e utilizza quei numeri per determinare il tuo posizionamento nella ricerca. Per comprendere il reale impatto prestazionale del tuo tema, hai bisogno di un approccio di misurazione sistematico che isoli il contributo del tema dalle prestazioni del server, dall'overhead dei moduli e dalle condizioni di rete.

Questo articolo illustra una metodologia completa di misurazione delle prestazioni. Imparerai come utilizzare Lighthouse, WebPageTest, Chrome DevTools e il monitoraggio degli utenti reali per quantificare esattamente quanto il tuo tema costa in termini di tempo di caricamento, interattività e stabilità visiva. Ancora più importante, imparerai come separare le prestazioni del tema da tutto il resto, così da poter prendere decisioni informate sull'ottimizzazione o la sostituzione.

Perché le prestazioni del tema contano più di quanto pensi

Il tuo tema controlla l'intera esperienza front-end. Determina quali file CSS vengono caricati, quanto JavaScript viene eseguito, come vengono renderizzate le immagini, come vengono caricati i font e come viene costruito il layout. Un tema mal costruito può aggiungere 2-5 secondi al tempo di caricamento della pagina, indipendentemente dalla velocità del server o dalla qualità del codice dei moduli.

I Core Web Vitals di Google misurano direttamente aspetti dell'esperienza utente che il tuo tema controlla. Il Largest Contentful Paint (LCP) misura quanto velocemente il contenuto principale diventa visibile. Il First Input Delay (FID) e il suo successore Interaction to Next Paint (INP) misurano quanto velocemente la pagina risponde all'interazione dell'utente. Il Cumulative Layout Shift (CLS) misura la stabilità visiva durante il caricamento della pagina. Tutte e tre le metriche sono fortemente influenzate dall'architettura del tema.

L'impatto sul business è concreto. Le ricerche mostrano costantemente che ogni secondo aggiuntivo di tempo di caricamento della pagina riduce i tassi di conversione del 7-10%. Un tema che aggiunge 2 secondi di tempo di caricamento non necessario potrebbe costarti il 15-20% delle vendite potenziali. Questo rende la misurazione delle prestazioni del tema non un esercizio tecnico ma un'analisi critica per il business.

Configurazione dell'ambiente di test

Prima di iniziare a misurare, hai bisogno di un ambiente di test controllato. Misurare le prestazioni sul tuo negozio live mentre i clienti navigano e il carico del server fluttua produrrà risultati inconsistenti. Devi minimizzare le variabili.

Idealmente, configura una copia di staging del tuo negozio PrestaShop. Questa dovrebbe essere una copia identica del tuo negozio di produzione in esecuzione sullo stesso hardware del server o su una configurazione simile. Installa gli stessi moduli, importa gli stessi prodotti e utilizza la stessa configurazione del tema. L'unica differenza dovrebbe essere che nessun cliente reale vi sta accedendo.

Se un ambiente di staging completo non è possibile, esegui i test durante le ore di basso traffico quando il carico del server è minimo. Esegui ogni test almeno tre volte e calcola la media dei risultati per tenere conto della variabilità di rete e del server.

Disabilita qualsiasi proxy di caching (come Cloudflare) per i test, oppure utilizza l'URL di staging che bypassa il CDN. Il caching del CDN maschera le reali prestazioni del tuo tema servendo contenuti memorizzati nella cache. Vuoi misurare cosa succede quando un visitatore raggiunge il tuo server di origine con una cache del browser vuota.

Documenta la tua configurazione di base. Annota la versione PHP, la versione di PrestaShop, i moduli attivi, le impostazioni CCC (Combine, Compress, Cache) e le specifiche del server. Avrai bisogno di queste informazioni per riprodurre i risultati e confrontare le misurazioni nel tempo.

Lighthouse: il tuo punto di partenza

Google Lighthouse è integrato in Chrome DevTools e fornisce l'audit delle prestazioni più accessibile disponibile. Simula un dispositivo mobile su una connessione limitata e misura le metriche chiave che Google utilizza per il posizionamento nella ricerca.

Per eseguire un audit Lighthouse, apri Chrome DevTools (F12), naviga fino alla scheda Lighthouse, seleziona "Prestazioni" come categoria, scegli "Dispositivo mobile" come dispositivo e clicca su "Analizza caricamento pagina". Lighthouse ricaricherà la pagina in un ambiente simulato e genererà un report dettagliato.

Il punteggio Prestazioni (0-100) è un composito ponderato di sei metriche: First Contentful Paint (10%), Speed Index (10%), Largest Contentful Paint (25%), Total Blocking Time (30%), Cumulative Layout Shift (25%). Nota che Total Blocking Time e Largest Contentful Paint insieme rappresentano il 55% del punteggio, quindi queste sono le metriche più probabilmente influenzate dalla qualità del tema.

Esegui l'audit su almeno quattro tipi di pagina: la tua homepage, una pagina di categoria, una pagina prodotto e la pagina carrello o checkout. Ogni tipo di pagina ha una complessità DOM e requisiti di risorse diversi, e il tuo tema potrebbe comportarsi in modo molto diverso tra di essi.

Avvertenza importante: Lighthouse funziona in un ambiente simulato con throttling di CPU e rete. I numeri assoluti che produce non corrispondono alle prestazioni del mondo reale. Sono utili per il confronto (prima vs dopo, tema A vs tema B) ma non dovrebbero essere presi come l'esperienza effettiva dei tuoi clienti. Per i numeri del mondo reale, hai bisogno del Real User Monitoring, trattato più avanti in questo articolo.

Registra ogni risultato di Lighthouse in un foglio di calcolo. Includi l'URL testato, la data e l'ora, il punteggio complessivo delle Prestazioni e il valore di ogni singola metrica. Questo crea una baseline a cui puoi fare riferimento mentre apporti modifiche.

WebPageTest: analisi approfondita

WebPageTest (webpagetest.org) è uno strumento gratuito che fornisce molti più dettagli rispetto a Lighthouse. Utilizza browser reali su hardware reale da posizioni in tutto il mondo, offrendoti un quadro più accurato di ciò che i tuoi clienti sperimentano.

Avvia un test inserendo l'URL del tuo negozio, selezionando una posizione di test vicina al tuo pubblico principale e scegliendo una velocità di connessione. Per i negozi europei, utilizza una posizione di test a Francoforte o Londra con un profilo di connessione Cable o 4G. Esegui almeno tre test per ottenere risultati mediani.

Il grafico a cascata è l'output più prezioso di WebPageTest. Mostra ogni singola risorsa che la tua pagina carica, in ordine cronologico, con il tempo che ogni risorsa impiega per essere scaricata. Questa visualizzazione rende immediatamente evidente quali risorse bloccano il rendering e quali vengono caricate inutilmente.

Cerca questi pattern nel grafico a cascata. CSS e JavaScript che bloccano il rendering appaiono come barre lunghe nella parte superiore del grafico prima che qualsiasi contenuto venga renderizzato. File font di grandi dimensioni che si scaricano prima del contenuto critico indicano una strategia di caricamento dei font inadeguata. Richieste di terze parti (analytics, widget social, plugin di chat) che bloccano o ritardano le risorse del tema.

WebPageTest fornisce anche una visualizzazione filmstrip che mostra screenshot della tua pagina a intervalli di 100ms durante il caricamento. Questo è incredibilmente utile per comprendere l'esperienza visiva di caricamento. Puoi vedere esattamente quando appare il testo, quando vengono renderizzate le immagini e quando si verificano gli spostamenti del layout.

La vista "Content Breakdown" mostra il peso totale della tua pagina suddiviso per tipo di contenuto: HTML, CSS, JavaScript, immagini, font e altre risorse. Per un tema ben ottimizzato, il CSS dovrebbe essere sotto i 100KB compressi, il JavaScript sotto i 150KB compressi e i font sotto i 50KB. Se i tuoi numeri sono significativamente più alti, il tuo tema porta peso in eccesso.

Chrome DevTools - Scheda Performance: analisi fotogramma per fotogramma

La scheda Performance in Chrome DevTools fornisce l'analisi più granulare disponibile. Registra una timeline dettagliata di tutto ciò che il browser fa durante il caricamento della pagina, inclusa l'esecuzione di JavaScript, i calcoli del layout, le operazioni di paint e il compositing.

Per utilizzarla, apri DevTools (F12), vai alla scheda Performance, seleziona "Screenshot" e "Web Vitals", seleziona il throttle di rete "Slow 3G" e il throttle CPU "4x slowdown", poi clicca sul pulsante di registrazione e ricarica la pagina. Ferma la registrazione una volta che la pagina si è completamente caricata.

La timeline risultante mostra diverse corsie di informazione. La corsia Network mostra le richieste delle risorse. La corsia Frames mostra gli screenshot nei momenti chiave. La corsia Main mostra l'esecuzione di JavaScript sul thread principale. I marcatori Web Vitals mostrano esattamente quando si verificano gli eventi FCP, LCP e CLS.

Concentrati sulla corsia del thread Main. I blocchi gialli lunghi sono esecuzioni JavaScript. Cerca task JavaScript che impiegano più di 50ms, poiché questi sono "long task" che bloccano l'interazione dell'utente e contribuiscono al Total Blocking Time. Identifica quali script causano questi long task cliccando su di essi per vedere lo stack delle chiamate. Se i long task provengono dai file JavaScript del tuo tema, quello è un problema di prestazioni del tema.

I blocchi rossi nella corsia Main indicano layout thrashing, dove il browser è costretto a ricalcolare il layout più volte in rapida successione. Questo accade spesso quando JavaScript legge proprietà del layout (offsetHeight, getBoundingClientRect) e poi modifica il DOM in un ciclo. Il codice del tema che causa layout thrashing è una fonte comune di punteggi INP scarsi.

Le schede "Bottom-Up" e "Call Tree" sotto la timeline ti permettono di ordinare l'esecuzione JavaScript per tempo totale o tempo proprio. Questo ti mostra quali funzioni specifiche consumano più tempo CPU durante il caricamento della pagina. Se le funzioni del tema dominano questa lista, il tuo tema è il collo di bottiglia delle prestazioni.

Analisi del waterfall di rete per le risorse del tema

La scheda Network nei DevTools fornisce una vista diversa del caricamento delle risorse. Filtra per tipo di risorsa (CSS, JS, Font, Img) per isolare le risorse specifiche del tema e comprendere il loro impatto.

Inizia identificando tutte le risorse che appartengono al tuo tema. Queste vengono tipicamente caricate da percorsi come /themes/nome-tema/assets/ o simili. Annota il numero totale e la dimensione combinata. Poi identifica le risorse caricate dai moduli (dai percorsi /modules/) per comprendere separatamente il contributo dei moduli.

Abilita la casella "Disabilita cache" e ricarica. Questo simula un visitatore alla prima visita. Annota la dimensione totale del trasferimento e il tempo per DOMContentLoaded e gli eventi Load. Poi ricarica senza la casella per vedere l'esperienza con cache (visitatore di ritorno). La differenza ti dice quanto il tuo tema beneficia della cache del browser.

Guarda la colonna "Initiator" per comprendere la catena di dipendenze. Un file CSS caricato dal template head del tuo tema è una risorsa critica che blocca il rendering. Un file JavaScript caricato con l'attributo async o defer non è bloccante. Comprendere queste dipendenze ti aiuta a identificare quali risorse del tema sono sul percorso critico e quali potrebbero essere differite.

Utilizza la colonna "Priority" (abilitala tramite il menu contestuale dell'intestazione della colonna) per vedere come il browser prioritizza ogni risorsa. Le risorse con priorità "Highest" o "High" sono quelle che il browser considera più importanti. Se il tuo tema carica risorse non critiche ad alta priorità, quella è un'opportunità di ottimizzazione.

Il confronto con e senza tema

Per isolare davvero l'impatto prestazionale del tuo tema, hai bisogno di un confronto. L'approccio più rigoroso è testare il tuo negozio con il tema attuale e poi passare al tema predefinito minimale di PrestaShop e testare nuovamente.

Nel tuo ambiente di staging, esegui un set completo di misurazioni con il tema attuale attivo. Registra tutte le metriche. Poi cambia il tema con il tema Classic di PrestaShop (o Hummingbird se sei su PrestaShop 8.x+) e esegui le stesse misurazioni. La differenza rappresenta l'impatto incrementale del tuo tema rispetto a quello predefinito.

Questo confronto non è perfetto perché il tema predefinito non ha le tue personalizzazioni e l'output visivo è diverso. Ma ti fornisce un tetto massimo per quanto miglioramento prestazionale è possibile attraverso l'ottimizzazione del tema. Se il tuo tema attuale ottiene 30 punti in meno del tema predefinito su Lighthouse, sai che c'è un margine significativo per il miglioramento.

Un confronto più controllato implica la disabilitazione progressiva delle funzionalità del tema. Inizia con tutte le funzionalità abilitate, misura, poi disabilita i font personalizzati e misura nuovamente. Disabilita gli effetti JavaScript del tema e misura. Rimuovi il font di icone del tema. Ogni passaggio ti mostra il costo incrementale di quella specifica funzionalità.

Core Web Vitals: cosa misura effettivamente Google

I Core Web Vitals sono le tre metriche che Google utilizza per scopi di posizionamento. Vengono misurati sugli utenti reali attraverso il Chrome User Experience Report (CrUX), non attraverso strumenti di laboratorio come Lighthouse. Comprendere la differenza tra le misurazioni di laboratorio e quelle sul campo è fondamentale.

Le misurazioni di laboratorio (Lighthouse, WebPageTest) utilizzano condizioni simulate. Le misurazioni sul campo (CrUX, Real User Monitoring) catturano le esperienze effettive degli utenti su diversi dispositivi, reti e posizioni. Il tuo punteggio Lighthouse potrebbe essere 75, ma se la maggior parte dei tuoi clienti utilizza telefoni più vecchi con connessioni lente, i dati sul campo potrebbero raccontare una storia molto diversa.

Per vedere i tuoi dati sul campo, utilizza il report Core Web Vitals di Google Search Console o PageSpeed Insights (pagespeed.web.dev). PageSpeed Insights mostra sia i dati di laboratorio che quelli sul campo quando disponibili. Se il tuo sito ha traffico sufficiente, vedrai i dati degli utenti reali accanto alla simulazione di Lighthouse.

Le soglie per buoni Core Web Vitals sono: LCP sotto i 2,5 secondi, INP sotto i 200 millisecondi e CLS sotto 0,1. Google valuta il 75° percentile dei tuoi utenti, il che significa che il 75% dei tuoi utenti deve avere una buona esperienza perché una metrica sia classificata come "buona". Questa è una barra alta perché i visitatori con le peggiori prestazioni (telefoni vecchi, reti lente) influenzano pesantemente il 75° percentile.

Il tuo tema influisce direttamente su tutte e tre le metriche. L'LCP è influenzato dalla dimensione dei file CSS (che bloccano il rendering), dalla strategia di caricamento dei font e dall'implementazione dell'immagine hero. L'INP è influenzato dall'esecuzione JavaScript, dall'efficienza dei gestori di eventi e da come il tema risponde ai clic e allo scorrimento. Il CLS è influenzato dai segnaposto delle immagini, dall'inserimento di contenuti dinamici e dal caricamento dei font.

Real User Monitoring: la verità sul campo

Il Real User Monitoring (RUM) cattura i dati sulle prestazioni dai tuoi visitatori effettivi mentre navigano nel tuo negozio. Questa è la misura più accurata dell'impatto prestazionale del tuo tema nel mondo reale perché riflette i dispositivi, le reti e i pattern di utilizzo effettivi del tuo pubblico.

Google Analytics 4 cattura automaticamente i Core Web Vitals se hai lo snippet gtag.js sul tuo sito. Puoi visualizzare questi dati in GA4 sotto Report, Esperienza utente, oppure creando un'esplorazione personalizzata.

Per un RUM più dettagliato, servizi dedicati come SpeedCurve, Datadog o la libreria JavaScript gratuita web-vitals forniscono dati granulari. La libreria web-vitals (disponibile su npm) è particolarmente utile perché puoi aggiungerla al tuo tema e inviare i dati sulle prestazioni a qualsiasi endpoint di analytics.

Con i dati RUM, puoi segmentare le prestazioni per tipo di dispositivo (mobile vs desktop), browser (Chrome vs Safari vs Firefox), paese e tipo di pagina. Questa segmentazione spesso rivela che il tuo tema si comporta in modo molto diverso per diversi segmenti di pubblico. Un tema potrebbe ottenere buoni risultati per gli utenti desktop Chrome ma scarsi per gli utenti mobile Safari a causa delle differenze nelle prestazioni del motore JavaScript o nel rendering CSS.

Monitora i dati RUM nel tempo per correlare i cambiamenti di prestazioni con gli aggiornamenti del tema, le installazioni di moduli o le modifiche alla configurazione. Se il tuo LCP aumenta improvvisamente di 500ms, controlla cosa è cambiato nel tuo stack di tema o moduli in quella data.

Profilazione lato server: separare il backend dal frontend

A volte le scarse prestazioni della pagina vengono attribuite al tema quando il vero problema è il tempo di elaborazione lato server. Prima di ottimizzare il tema, verifica che il server stia generando l'HTML rapidamente.

PrestaShop include un profiler integrato che puoi abilitare nel back office sotto Parametri avanzati, Prestazioni, Modalità debug. Il profiler aggiunge una barra di debug nella parte inferiore di ogni pagina che mostra il conteggio delle query SQL, il tempo di esecuzione SQL, il tempo di generazione della pagina e l'utilizzo della memoria.

Un'installazione PrestaShop ben configurata dovrebbe generare la maggior parte delle pagine in meno di 500ms lato server. Se la generazione del server richiede più di un secondo, il problema non è il tuo tema ma il server, le query al database o gli hook dei moduli. Correggere il tema non aiuterà se il server impiega 3 secondi solo per generare l'HTML.

Puoi anche misurare il tempo di risposta del server (Time to First Byte, TTFB) dalla scheda Network nei DevTools. Clicca sulla richiesta del documento HTML e guarda la sezione Timing. Il valore "Waiting (TTFB)" mostra quanto il browser ha atteso la risposta del server. Sottrai la latenza di rete (che puoi stimare dal valore "Connection") per ottenere il tempo di elaborazione approssimativo del server.

Se il tuo TTFB è alto ma le risorse del tema sono veloci, concentrati sull'ottimizzazione del server (PHP OPcache, cache delle query MySQL, Redis/Memcached, object caching di PrestaShop) piuttosto che sull'ottimizzazione del tema. Se il tuo TTFB è veloce ma la pagina si carica comunque lentamente, il tema è probabilmente il collo di bottiglia.

Il framework di benchmarking prima/dopo

Quando apporti modifiche alle prestazioni del tema, hai bisogno di un confronto prima/dopo rigoroso per verificare che la modifica abbia effettivamente aiutato. Ecco un framework che produce risultati affidabili.

Prima di apportare qualsiasi modifica, esegui cinque audit Lighthouse su ogni pagina target e registra il punteggio mediano e le singole metriche. Esegui anche tre test WebPageTest e registra i valori mediani. Salva i report completi, non solo i punteggi, perché potresti dover esaminare i dettagli in seguito.

Apporta la tua modifica. Svuota tutte le cache, inclusa la cache Smarty di PrestaShop, l'OPcache e qualsiasi cache CDN. Attendi almeno 60 secondi perché l'OPcache si resetti completamente se hai modificato file PHP.

Esegui gli stessi cinque audit Lighthouse e tre test WebPageTest sulle stesse pagine. Confronta i risultati mediani. Una modifica è significativa se produce un miglioramento coerente in tutti i test. Se alcuni test mostrano miglioramento e altri regressione, l'impatto della modifica rientra nel margine di errore della misurazione.

Sii scettico riguardo ai piccoli miglioramenti. I punteggi Lighthouse possono variare di più o meno 5 punti tra esecuzioni identiche a causa della variabilità del throttle simulato di rete e CPU. Una modifica che migliora il punteggio da 62 a 65 potrebbe non essere un miglioramento reale. Una modifica da 62 a 75 quasi certamente lo è.

Per il confronto più rigoroso, utilizza la funzione di confronto visivo di WebPageTest. Inserisci il tuo URL di staging (prima della modifica) e l'URL di produzione (dopo la modifica), oppure esegui lo stesso URL in momenti diversi e confronta i test salvati. WebPageTest genera un filmstrip affiancato ed evidenzia le differenze.

Problemi comuni di prestazioni del tema e come rilevarli

Attraverso la misurazione, identificherai problemi di prestazioni specifici. Ecco i problemi più comuni legati al tema e le metriche che li rivelano.

Il CSS che blocca il rendering appare come un FCP e LCP elevati con un lungo intervallo tra TTFB e FCP nel waterfall. La soluzione è inserire inline il CSS critico e differire i fogli di stile non critici. Il JavaScript eccessivo si manifesta come TBT elevato e punteggi INP scarsi. I long task nella timeline della scheda Performance confermano questo. Il caricamento non ottimizzato dei font si manifesta come FOIT (testo invisibile) nel filmstrip o un intervallo tra FCP e il momento in cui il testo appare effettivamente. Gli spostamenti del layout causati da immagini senza dimensioni o contenuti inseriti dinamicamente appaiono come punteggi CLS elevati.

Ogni problema ha una firma di misurazione specifica. Imparare a leggere queste firme è ciò che trasforma il lavoro sulle prestazioni da supposizioni in ingegneria. Misura prima, diagnostica sulla base dei dati, correggi il problema specifico, poi misura di nuovo per verificare che la correzione abbia funzionato.

Costruire una routine di monitoraggio delle prestazioni

La misurazione delle prestazioni non dovrebbe essere un'attività una tantum. Costruisci una routine che individui le regressioni prima che influenzino i tuoi clienti e il posizionamento nella ricerca.

Settimanalmente, esegui Lighthouse sui tuoi quattro tipi di pagina chiave e registra i risultati. Mensilmente, esegui un'analisi completa con WebPageTest e confronta con il mese precedente. Dopo ogni aggiornamento del tema o installazione di moduli, esegui un confronto prima/dopo. Configura il monitoraggio dei Core Web Vitals in Google Search Console e rivedilo mensilmente.

Considera l'automazione con strumenti come Lighthouse CI (per esecuzioni automatizzate di Lighthouse nella tua pipeline di deployment) o SpeedCurve (per il monitoraggio continuo con avvisi). Questi strumenti ti notificano immediatamente quando le prestazioni peggiorano, permettendoti di identificare e correggere la causa prima che influisca sul tuo posizionamento nella ricerca.

L'obiettivo non è un punteggio Lighthouse perfetto. L'obiettivo è capire esattamente dove vanno il tuo tempo e le tue risorse ad ogni caricamento di pagina, e prendere decisioni deliberate e basate sui dati su cosa ottimizzare, cosa mantenere e cosa rimuovere.

Leggi la risposta completa

Il vero dibattito dietro il prezzo dei temi

Ogni proprietario di un negozio PrestaShop si trova prima o poi di fronte a questa domanda: meglio usare un tema gratuito o investire in uno premium? La risposta sembra ovvia in superficie. Il gratuito fa risparmiare, il premium costa. Ma il costo effettivo di un tema va ben oltre il suo prezzo di acquisto. Un tema gratuito che richiede centinaia di euro in lavori di personalizzazione, causa problemi di prestazioni o manca di funzionalità critiche può finire per costare molto di più di un tema premium che funziona correttamente fin da subito.

Questa guida analizza le reali differenze tra temi PrestaShop gratuiti e premium, esamina i costi nascosti di entrambe le opzioni e ti aiuta a prendere una decisione informata basata su ciò di cui hai effettivamente bisogno, piuttosto che su ciò che dice il cartellino del prezzo.

Cosa offrono realmente i temi gratuiti

PrestaShop viene fornito con un tema predefinito. In PrestaShop 1.7 e 8.x, si tratta del tema Classic. PrestaShop 9 introduce Hummingbird come nuovo tema predefinito. Questi temi ufficiali sono genuinamente ben realizzati. Seguono gli standard di codifica di PrestaShop, supportano tutti gli hook standard, funzionano correttamente con il sistema di traduzione e ricevono aggiornamenti insieme alla piattaforma principale. Per un proprietario di negozio che ha bisogno di un design pulito e funzionale ed è disposto a personalizzarlo con CSS, il tema predefinito è un punto di partenza legittimo.

Oltre ai temi ufficiali, il panorama dei temi gratuiti è molto più variegato in termini di qualità. I temi gratuiti di sviluppatori terzi rientrano in diverse categorie. Alcuni sono versioni ridotte di temi premium, progettate per darti un assaggio del lavoro dello sviluppatore e incoraggiarti ad effettuare l'upgrade. Questi sono generalmente funzionali ma limitati, privi di funzionalità come layout avanzati della pagina prodotto, mega menu o schemi di colori configurabili. Altri sono progetti hobbistici o pezzi da portfolio creati da singoli sviluppatori. La loro qualità varia enormemente, da sorprendentemente buoni a appena funzionanti. E poi ci sono temi che sono gratuiti perché servono a uno scopo diverso dall'essere un buon tema, come temi che includono adware, temi con backlink nascosti verso il sito dello sviluppatore o temi che raccolgono dati di utilizzo senza informare l'utente.

Il marketplace ufficiale PrestaShop Addons offre alcuni temi gratuiti, e questi devono superare un processo di revisione di base. I temi gratuiti provenienti da fonti sconosciute al di fuori del marketplace ufficiale comportano un rischio significativamente più elevato e dovrebbero essere valutati con particolare attenzione.

Cosa offrono i temi premium

I temi premium per PrestaShop hanno generalmente un prezzo compreso tra 60 e 300 euro, con la maggior parte nella fascia tra 80 e 150 euro. Per questo prezzo, si riceve generalmente un tema con un design visivo curato che include molteplici layout di pagina predefiniti e schemi di colori, un pannello di configurazione nel back office che consente di personalizzare colori, font, layout e altri elementi visivi senza modificare il codice, una raccolta di moduli companion (mega menu, pagine prodotto personalizzate, slider di immagini, funzionalità blog) progettati per funzionare perfettamente con il tema, documentazione che spiega installazione, configurazione e personalizzazione, un periodo di supporto tecnico (generalmente da 3 a 12 mesi a seconda del marketplace e del venditore) e aggiornamenti di compatibilità per le nuove versioni di PrestaShop.

La proposta di valore di un tema premium non è solo il design. È il tempo di sviluppo risparmiato. Creare da zero un modulo mega menu personalizzato, un sistema di layout configurabile per la pagina prodotto e un configuratore del tema nel back office costerebbe migliaia di euro in tempo di sviluppo. Un tema premium include tutto questo a una frazione del costo.

Differenze di qualità nel codice

La differenza più significativa tra temi gratuiti e premium è spesso invisibile all'acquirente: la qualità del codice. Gli sviluppatori di temi premium che vendono temi come attività principale hanno un incentivo finanziario a scrivere codice pulito e manutenibile. Le recensioni negative e le richieste di supporto costano loro tempo e denaro, quindi investono nella qualità fin dall'inizio. Gli sviluppatori di temi gratuiti non hanno alcuna relazione finanziaria continuativa con i loro utenti, nessun costo di supporto per codice di scarsa qualità e nessun rischio reputazionale da software abbandonato. I temi ufficiali di PrestaShop hanno un'eccellente qualità del codice, ma la qualità media dei temi gratuiti di terze parti è significativamente inferiore.

Le differenze specifiche includono l'organizzazione dei template (i temi premium usano gerarchie logiche con partial; i temi gratuiti spesso utilizzano template monolitici), l'architettura CSS (i temi premium usano BEM o metodologie simili con proprietà personalizzate appropriate; i temi gratuiti hanno CSS non strutturato con conflitti di specificità) e la qualità del JavaScript (i temi premium utilizzano pratiche moderne e funzionano con la gestione degli asset di PrestaShop; i temi gratuiti caricano librerie in modo ridondante e creano conflitti con i moduli).

Supporto e aggiornamenti

Quando qualcosa si rompe nel tuo tema, che sia a causa di un aggiornamento di PrestaShop, di un conflitto con un modulo o di una personalizzazione andata storta, hai bisogno di aiuto. È qui che il divario tra gratuito e premium diventa più tangibile.

I temi premium acquistati attraverso marketplace ufficiali includono un periodo di supporto definito. Durante questo periodo, puoi contattare lo sviluppatore per domande tecniche, segnalazioni di bug e problemi di compatibilità. La qualità del supporto varia tra gli sviluppatori, ma l'obbligo contrattuale esiste. Hai pagato per un prodotto e il venditore ha la responsabilità di garantire che funzioni come descritto.

I temi gratuiti non prevedono alcun obbligo di supporto. Se riscontri un bug, le tue opzioni sono risolverlo da solo, assumere uno sviluppatore per risolverlo o abbandonare il tema. Lo sviluppatore originale non ha alcun incentivo a rispondere alla tua segnalazione di bug, investigare il tuo problema o rilasciare una correzione. Alcuni sviluppatori di temi gratuiti forniscono supporto comunitario attraverso forum o issue su GitHub, ma questo è volontario e inaffidabile.

Gli aggiornamenti seguono lo stesso schema. Gli sviluppatori di temi premium rilasciano aggiornamenti quando escono nuove versioni di PrestaShop, quando vengono scoperti bug e quando vengono aggiunte nuove funzionalità. Questi aggiornamenti vengono distribuiti attraverso il marketplace e possono essere applicati tramite il back office. I temi gratuiti potrebbero non ricevere mai un aggiornamento dopo il rilascio iniziale. Quando PrestaShop 8 ha introdotto modifiche al sistema di template, i temi premium sono stati aggiornati. Molti temi gratuiti costruiti per PrestaShop 1.7 sono stati semplicemente abbandonati, lasciando i loro utenti bloccati su una vecchia versione di PrestaShop o costretti a cercare un nuovo tema in fretta.

Rischi di sicurezza dei temi gratuiti

La sicurezza è un'area in cui i temi gratuiti comportano un rischio genuinamente elevato. Un tema ha accesso all'intero front office. Controlla quale HTML, CSS e JavaScript viene consegnato ai browser dei tuoi clienti. Un tema malevolo o compromesso può iniettare codice di mining di criptovalute, reindirizzare i clienti verso siti di phishing, rubare dati dai moduli incluse le informazioni di pagamento, creare account admin nascosti o installare backdoor che persistono anche dopo la rimozione del tema.

I temi premium provenienti da marketplace consolidati passano attraverso un processo di revisione che verifica la presenza di problemi di sicurezza noti. Il marketplace PrestaShop Addons, ThemeForest e altre piattaforme affidabili scansionano i temi inviati alla ricerca di codice malevolo, vulnerabilità note e conformità agli standard di sicurezza di base. Questa revisione non è perfetta e le vulnerabilità possono comunque esistere, ma fornisce un livello di protezione di base.

I temi gratuiti scaricati da siti web casuali non hanno tale protezione. Stai affidando a uno sviluppatore sconosciuto l'accesso al front end del tuo negozio. Anche se lo sviluppatore ha buone intenzioni, il suo codice potrebbe contenere vulnerabilità di sicurezza non intenzionali come falle di cross-site scripting (XSS), punti di SQL injection nei gestori AJAX specifici del tema o gestione non sicura del caricamento file nei pannelli di configurazione del tema.

Il tema gratuito più sicuro è il tema predefinito ufficiale di PrestaShop, perché è mantenuto dal team principale di PrestaShop e riceve aggiornamenti di sicurezza insieme alla piattaforma stessa.

Il pericolo dei temi nulled

I temi nulled sono temi premium che sono stati piratati e distribuiti gratuitamente. Rappresentano la categoria più pericolosa in assoluto di temi PrestaShop. Utilizzare un tema nulled non è solo una violazione della proprietà intellettuale. È una minaccia diretta alla sicurezza della tua attività e dei tuoi clienti.

I temi nulled vengono modificati prima della distribuzione. Il codice di verifica della licenza viene rimosso (è questo che li rende nulled), ma altre modifiche vengono spesso aggiunte contemporaneamente. Le modifiche comuni includono accessi backdoor che consentono al distributore di accedere al pannello di amministrazione del tuo negozio in qualsiasi momento, raccolta di dati che invia le informazioni personali e i dati degli ordini dei tuoi clienti a server esterni, iniezione di spam SEO che aggiunge link nascosti a siti di gioco d'azzardo, farmaceutici o di contenuti per adulti nell'HTML del tuo negozio (danneggiando il tuo posizionamento nei motori di ricerca e potenzialmente violando le normative pubblicitarie), JavaScript di cryptomining che utilizza i dispositivi dei tuoi clienti per minare criptovalute mentre navigano nel tuo negozio e catene di redirect che inviano una percentuale del tuo traffico a siti concorrenti o pagine truffa.

Queste modifiche sono progettate per essere invisibili. Sono offuscate, attivate solo in determinate condizioni (ad esempio, solo per visitatori da paesi specifici o solo dopo che il negozio è stato in funzione per un certo periodo) e nascoste in file che i proprietari dei negozi raramente ispezionano. Puoi utilizzare un tema nulled per mesi prima di scoprire che ha inviato i dati dei tuoi clienti a un server in un altro paese.

Non esiste alcuna ragione legittima per utilizzare un tema nulled. Se non puoi permetterti un tema premium, usa il tema gratuito ufficiale. È migliore sotto ogni aspetto misurabile rispetto a un tema premium nulled.

Confronto delle prestazioni

Le prestazioni del tema influenzano direttamente il tasso di conversione del tuo negozio e il posizionamento nei motori di ricerca. Google utilizza i Core Web Vitals come fattore di ranking, e queste metriche sono fortemente influenzate dalla qualità del tema.

I temi ufficiali PrestaShop Classic e Hummingbird sono ottimizzati per le prestazioni. Caricano CSS e JavaScript minimi, utilizzano strutture di template efficienti e supportano le funzionalità di prestazioni integrate di PrestaShop come CCC (Combine, Compress, Cache) per i file CSS e JavaScript. Un negozio che utilizza il tema predefinito con una corretta configurazione del server raggiunge generalmente buoni punteggi Core Web Vitals senza lavoro di ottimizzazione aggiuntivo.

I temi premium variano nelle prestazioni. I migliori temi premium eguagliano o superano le prestazioni del tema predefinito offrendo significativamente più funzionalità. Raggiungono questo risultato attraverso tecniche come il lazy loading di immagini e contenuti below-the-fold, il caricamento condizionale del JavaScript (caricando il codice del carosello solo nelle pagine che hanno caroselli, ad esempio), CSS ottimizzato che evita regole inutilizzate e un uso efficiente dei web font con impostazioni font-display appropriate. I peggiori temi premium, tuttavia, sacrificano le prestazioni per la complessità visiva, caricando slider multipli, librerie di animazione e icon font su ogni pagina indipendentemente dal fatto che siano necessari.

I temi gratuiti di terze parti (escluso il tema predefinito ufficiale) tendono ad avere prestazioni scadenti. Senza l'incentivo commerciale all'ottimizzazione, gli sviluppatori di temi gratuiti spesso includono tutte le funzionalità su tutte le pagine, usano immagini non ottimizzate per i contenuti demo che vengono portate in produzione, caricano build complete delle librerie invece di selezionare solo i componenti necessari e saltano la minificazione e la concatenazione degli asset.

Prima di scegliere qualsiasi tema, testa la sua demo con Google PageSpeed Insights e controlla i punteggi Core Web Vitals. Un tema che ottiene un punteggio inferiore a 50 su mobile nel proprio ambiente demo ottimizzato avrà prestazioni ancora peggiori nel tuo negozio reale con moduli aggiuntivi, più prodotti e condizioni di hosting reali.

Opzioni di personalizzazione

La personalizzazione determina quanto puoi modificare l'aspetto del tuo negozio senza scrivere codice. Il tema ufficiale PrestaShop offre una personalizzazione integrata minima: logo, favicon e alcune impostazioni di base. Qualsiasi modifica visiva oltre queste basi richiede la modifica dei file CSS o dei template Smarty.

I temi premium includono generalmente un modulo configuratore del tema che fornisce un'interfaccia grafica per colori, tipografia, opzioni di layout, configurazione di header e footer, layout della pagina prodotto e visualizzazione della pagina categoria. Queste opzioni consentono a un proprietario di negozio non tecnico di creare un negozio visivamente distintivo senza toccare il codice. I temi gratuiti a volte includono opzioni di personalizzazione di base, ma sono generalmente limitate a poche scelte di colore e al caricamento del logo. La differenza è sostanziale.

Marketplace vs venditori indipendenti

Dove acquisti un tema premium conta tanto quanto se ne acquisti uno. I tre canali principali per i temi PrestaShop sono il marketplace ufficiale PrestaShop Addons, marketplace generalisti come ThemeForest e sviluppatori di temi indipendenti che vendono attraverso i propri siti web.

Il marketplace PrestaShop Addons offre il più alto livello di protezione dell'acquirente. I temi vengono revisionati per compatibilità con PrestaShop, qualità del codice e sicurezza. Il marketplace gestisce i pagamenti, fornisce un processo di risoluzione delle controversie e impone gli obblighi di supporto. Lo svantaggio è una selezione più ridotta rispetto ai marketplace generalisti e talvolta prezzi più alti.

ThemeForest e marketplace simili offrono una selezione molto più ampia a prezzi competitivi. Tuttavia, il processo di revisione per la qualità specifica di PrestaShop è meno rigoroso. Un tema può superare la revisione generale di ThemeForest pur avendo problemi specifici di PrestaShop come hook mancanti, strutture di template incompatibili o conflitti con moduli comuni. Il supporto è fornito dallo sviluppatore del tema, non dal marketplace, e la qualità varia significativamente tra i venditori.

I venditori indipendenti offrono temi attraverso i propri siti web. Questa può essere la migliore o la peggiore opzione a seconda dello sviluppatore specifico. Sviluppatori di temi PrestaShop consolidati con un portfolio di temi ben recensiti, blog o tutorial attivi e un coinvolgimento visibile nella comunità sono spesso la migliore fonte di temi di alta qualità. Comprendono PrestaShop in profondità e costruiscono temi specificamente per la piattaforma. Sviluppatori sconosciuti che vendono un singolo tema attraverso un sito web oscuro, tuttavia, rappresentano la categoria a più alto rischio per i temi premium.

Indipendentemente da dove acquisti, verifica sempre se il venditore offre una politica di rimborso, quali sono i termini di supporto (durata, tempo di risposta, cosa è coperto) e se gli aggiornamenti sono inclusi nel prezzo di acquisto o richiedono un abbonamento aggiuntivo.

Cosa cercare nella documentazione del tema

La qualità della documentazione è uno degli indicatori più affidabili della qualità complessiva del tema. Uno sviluppatore che investe tempo nella creazione di una documentazione completa investe anche tempo nella scrittura di codice pulito, nei test approfonditi e nella manutenzione del prodotto nel tempo.

Una buona documentazione del tema include una guida all'installazione che copre i requisiti del server, istruzioni di installazione passo dopo passo e risoluzione dei problemi comuni di installazione. Include una guida alla configurazione che spiega ogni opzione nel pannello di configurazione del tema, con screenshot che mostrano cosa cambia ogni impostazione. Include una guida alla personalizzazione che spiega come creare un tema figlio, quali file template controllano quali parti del negozio e come sovrascrivere elementi specifici in modo sicuro. Include un riferimento agli hook che elenca tutti gli hook supportati e dove appaiono nel layout. Include un changelog che documenta ogni aggiornamento con date, numeri di versione e descrizioni di ciò che è cambiato. E include informazioni sulla compatibilità che specificano quali versioni di PrestaShop sono state testate.

Una documentazione scadente è un singolo PDF con pochi screenshot che mostrano la procedura guidata di installazione. Se lo sviluppatore non si preoccupa di documentare il proprio prodotto, taglia gli angoli anche altrove.

Costo totale di proprietà

Il vero costo di un tema non è il suo prezzo di acquisto. È l'importo totale di denaro che spendi per il tema durante l'intera vita del tuo negozio, inclusi il prezzo di acquisto, i costi di personalizzazione, il tempo dello sviluppatore per correzioni e soluzioni alternative, il lavoro di ottimizzazione delle prestazioni e il costo opportunità delle vendite perse a causa di problemi legati al tema.

Considera due scenari. Nel primo scenario, scegli un tema gratuito. Spendi zero per il tema stesso, ma hai bisogno di uno sviluppatore per personalizzare il design (500 euro), correggere problemi di layout mobile (200 euro), aggiungere hook mancanti per due moduli (300 euro) e risolvere un conflitto jQuery (150 euro). Dopo che un aggiornamento di PrestaShop rompe il tema (perché non è più mantenuto), spendi 400 euro per migrare a un nuovo tema. Costo totale: 1.550 euro più tempi di inattività e vendite perse durante la migrazione.

Nel secondo scenario, scegli un tema premium per 120 euro. Il configuratore integrato gestisce la personalizzazione del design (nessun costo aggiuntivo). Il tema supporta tutti gli hook standard (nessun costo aggiuntivo). Lo sviluppatore rilascia un aggiornamento per la nuova versione di PrestaShop (nessun costo aggiuntivo, incluso nell'acquisto). Contatti il supporto per risolvere una piccola domanda di configurazione (nessun costo aggiuntivo, coperto dal periodo di supporto). Costo totale: 120 euro.

Questi numeri sono illustrativi, non universali. Alcuni temi gratuiti non richiedono alcun investimento aggiuntivo e alcuni temi premium richiedono personalizzazioni estensive nonostante il loro prezzo. Ma lo schema si ripete. L'opzione più economica inizialmente è spesso l'opzione più costosa nel tempo.

Esempi reali di costi nascosti

I costi nascosti compaiono in aree invisibili durante la valutazione iniziale. L'incompatibilità con i moduli è comune: un tema gratuito che rimuove l'hook displayProductExtraContent rende impossibile l'utilizzo di moduli che aggiungono tab alle pagine prodotto. Lo scopri solo dopo aver acquistato il modulo, e poi ti trovi di fronte a modifiche a pagamento del tema, alternative limitate di moduli o il cambio completo del tema.

I danni SEO derivanti da una struttura HTML scadente sono un altro costo nascosto. I temi che usano i tag di intestazione in modo errato (tag H1 multipli, livelli di intestazione saltati) danneggiano il posizionamento in modi difficili da diagnosticare e costosi da correggere attraverso la riscrittura dei template.

I costi legati alle prestazioni sono significativi. Un aumento di un secondo nel tempo di caricamento della pagina in un negozio che fattura 100.000 euro all'anno costa circa 7.000-10.000 euro annui in conversioni perse. Se un tema gratuito si carica più lentamente di un tema premium ottimizzato, l'opzione gratuita costa migliaia di euro all'anno in fatturato perso invisibile.

Fare la scelta giusta

Il tema predefinito ufficiale di PrestaShop è la scelta giusta se hai competenze di sviluppo, vuoi il massimo controllo e prevedi di investire nello sviluppo personalizzato. Un tema premium è la scelta giusta se hai bisogno di un negozio curato rapidamente, non hai competenze tecniche e desideri moduli inclusi con supporto. Un tema gratuito di terze parti è raramente la scelta giusta. L'unico caso d'uso valido è un negozio di test temporaneo o un proof-of-concept in cui il tema verrà sostituito prima della messa in produzione.

Non utilizzare mai un tema nulled in nessuna circostanza. I rischi per la sicurezza sono reali, i rischi legali sono reali e il danno finanziario derivante da un negozio compromesso supera di gran lunga il costo di qualsiasi tema premium legittimo.

Raccomandazioni finali

Inizia con il tema ufficiale PrestaShop se non sei sicuro. È gratuito, ben mantenuto, sicuro e compatibile con tutto. Puoi sempre passare a un tema premium in seguito, quando avrai un quadro più chiaro delle tue esigenze. Se decidi di acquistare un tema premium, dai la priorità ai temi del marketplace ufficiale PrestaShop Addons o di sviluppatori affermati con una comprovata esperienza. Leggi attentamente le recensioni, concentrandoti sulle menzioni della qualità del supporto, della frequenza degli aggiornamenti e dei problemi di compatibilità. Testa la demo approfonditamente sui dispositivi mobili e controlla le prestazioni con PageSpeed Insights prima dell'acquisto.

Qualunque tema tu scelga, conserva la ricevuta d'acquisto e le informazioni sulla licenza, crea un tema figlio per le tue personalizzazioni invece di modificare il tema direttamente, documenta qualsiasi modifica manuale apportata ai file del tema, testa gli aggiornamenti del tema su un ambiente di staging prima di applicarli alla produzione e mantieni backup regolari in modo da poter recuperare rapidamente in caso di problemi causati da un aggiornamento del tema. Il tema è la base del front end del tuo negozio. Investire tempo nella scelta di quello giusto, che sia gratuito o premium, previene problemi che sono costosi e destabilizzanti da risolvere in seguito.

Leggi la risposta completa

Perché il bloat dei moduli è il killer silenzioso delle prestazioni di PrestaShop

Ogni negozio PrestaShop parte veloce. Poi installi cinque moduli, dieci moduli, trenta moduli, e improvvisamente la tua homepage impiega quattro secondi per caricarsi. Il colpevole raramente è un singolo modulo massiccio. Piuttosto, sono decine di piccoli moduli che aggiungono ciascuno il proprio file CSS, il proprio file JavaScript e le proprie query al database a ogni singolo caricamento di pagina. Questo peso cumulativo è ciò che chiamiamo bloat dei moduli, ed è la ragione numero uno per cui i negozi PrestaShop diventano lenti nel tempo.

Il problema è che la maggior parte dei proprietari di negozi non verifica mai cosa caricano effettivamente i loro moduli. Installano un modulo per le etichette dei prodotti, un altro per i pulsanti di condivisione social, un altro per un popup newsletter, un altro per l'analytics, e ciascuno si registra silenziosamente su hook come displayHeader e actionFrontControllerSetMedia. Anche se un modulo mostra contenuti solo sulle pagine prodotto, potrebbe comunque caricare i suoi file CSS e JavaScript sulla homepage, sulle pagine categoria, sulla pagina carrello e al checkout. Questo significa che i tuoi clienti scaricano risorse che non utilizzeranno mai su quella particolare pagina.

Un audit corretto dei moduli rivela esattamente cosa contribuisce ogni modulo al peso della tua pagina. Ti dice quali moduli sono i peggiori in termini di impatto, quali caricano risorse inutilmente e quali puoi ottimizzare o rimuovere completamente. Questo articolo ti guida attraverso il processo completo di audit dei tuoi moduli PrestaShop per le prestazioni, utilizzando i DevTools del browser, la modalità debug di PrestaShop e un'analisi sistematica.

Passaggio 1: Abilitare la modalità debug e il profiling delle prestazioni di PrestaShop

Prima di aprire gli strumenti del browser, devi abilitare le funzionalità di profiling integrate in PrestaShop. PrestaShop ha una modalità debug che rivela informazioni dettagliate sull'esecuzione degli hook, i tempi di caricamento dei moduli e le query al database. Per abilitarla, devi modificare due impostazioni.

Per prima cosa, vai su Parametri Avanzati, quindi Prestazioni nel tuo back office. Imposta la Modalità Debug su Sì. Questo abilita la segnalazione degli errori e il logging aggiuntivo che aiuta a identificare i moduli problematici. Tuttavia, la vera potenza viene dalla funzionalità di profiling.

Per abilitare il profiling completo, devi modificare il file defines.inc.php situato nella directory config di PrestaShop. Trova la riga che definisce _PS_DEBUG_PROFILING_ e impostala su true. In PrestaShop 1.7 e 8.x, questa costante controlla se la barra di profiling appare nella parte inferiore di ogni pagina del front office. Una volta abilitata, ricarica qualsiasi pagina del tuo negozio e vedrai un pannello di profiling dettagliato che mostra i tempi di esecuzione per ogni hook, ogni modulo e ogni query SQL.

Il pannello di profiling è diviso in diverse sezioni. La sezione hook mostra ogni hook che è stato eseguito sulla pagina corrente, quali moduli sono collegati a ogni hook e quanto tempo ha impiegato ogni modulo per l'esecuzione. La sezione SQL mostra ogni query al database, il suo tempo di esecuzione e quale modulo o funzione core l'ha generata. La sezione moduli fornisce un riepilogo del tempo di esecuzione totale per modulo su tutti gli hook.

Presta particolare attenzione alla colonna del tempo di esecuzione totale. Un modulo ben ottimizzato dovrebbe contribuire meno di 10 millisecondi al caricamento di una pagina. Se vedi un modulo che impiega 50, 100 o addirittura 500 millisecondi, si tratta di un serio problema di prestazioni che necessita di indagine.

Passaggio 2: Utilizzare i DevTools del browser per mappare le risorse dei moduli

Il profiling integrato di PrestaShop ti informa sulle prestazioni lato server, ma non ti mostra il quadro completo di ciò che accade nel browser. Per questo, hai bisogno degli Strumenti per sviluppatori del tuo browser. Apri Chrome o Firefox, premi F12 e vai alla scheda Network.

Ricarica la tua homepage con la scheda Network aperta. Vedrai ogni richiesta effettuata dal browser: HTML, file CSS, file JavaScript, immagini, font e chiamate AJAX. L'obiettivo è identificare quali di queste richieste provengono dai moduli.

In PrestaShop, le risorse dei moduli seguono un pattern URL prevedibile. I file CSS dei moduli sono generalmente serviti da percorsi come /modules/nomemodulo/views/css/nomefile.css o /modules/nomemodulo/css/nomefile.css. I file JavaScript seguono lo stesso pattern con js al posto di css. Usa la barra filtro nella scheda Network per filtrare per "modules/" e vedrai istantaneamente ogni risorsa caricata dai tuoi moduli installati.

Per ogni risorsa di modulo trovata, annota le seguenti informazioni: il nome del file, la sua dimensione (sia trasferita che non compressa) e se viene caricata sul tipo di pagina corrente. Vuoi costruire un foglio di calcolo o un semplice elenco che mappi ogni modulo alle sue risorse. Un audit tipico potrebbe rivelare qualcosa del genere: il modulo A carica due file CSS per un totale di 45 KB e un file JavaScript di 120 KB su ogni pagina, ma mostra contenuti solo sulle pagine prodotto. Questo significa che le pagine categoria, la homepage e il carrello stanno caricando 165 KB di risorse inutili.

La scheda Network mostra anche la vista waterfall, che rivela quando ogni risorsa inizia a caricarsi e quanto tempo impiega. Le risorse che bloccano il rendering (CSS render-blocking e JavaScript sincrono) sono particolarmente dannose perché impediscono al browser di visualizzare qualsiasi contenuto fino al completamento del loro caricamento. Cerca file JavaScript dei moduli che si caricano nell'head senza attributi async o defer, poiché sono i peggiori colpevoli per il tempo di caricamento percepito.

Passaggio 3: Analizzare il waterfall di rete per modulo

La vista waterfall nei DevTools merita una sezione dedicata perché rivela problemi di prestazioni che le dimensioni grezze dei file non mostrano. Quando osservi il waterfall, vuoi identificare tre tipi di problemi.

Primo, cerca risorse render-blocking provenienti dai moduli. Queste appaiono come barre che iniziano presto nel waterfall e ritardano l'evento first paint (la linea verticale verde o blu). In PrestaShop, i file CSS aggiunti tramite l'hook displayHeader o attraverso addCSS in setMedia sono generalmente render-blocking. Se un modulo aggiunge un file CSS grande che è necessario solo su pagine specifiche, blocca il rendering su ogni pagina senza motivo.

Secondo, cerca catene di caricamento sequenziale. Alcuni moduli caricano un file JavaScript che poi attiva il caricamento di risorse aggiuntive: altri file JavaScript, file CSS, web font o chiamate API esterne. Ogni anello di questa catena aggiunge latenza. Un modulo che carica jQuery UI, poi un tema CSS di jQuery UI, poi uno script widget personalizzato, poi il CSS del widget crea una catena di quattro richieste sequenziali che potrebbe richiedere da 200 a 400 millisecondi anche su una connessione veloce.

Terzo, cerca richieste esterne. Alcuni moduli effettuano chiamate a server esterni per analytics, tracking, caricamento font, widget di social media o dati API. Queste richieste sono particolarmente pericolose perché non hai alcun controllo sul tempo di risposta del server esterno. Un modulo di condivisione social che chiama le API di Facebook, Twitter e Pinterest a ogni caricamento di pagina può aggiungere 500 millisecondi o più di latenza, e se uno qualsiasi di quei server è lento o irraggiungibile, può bloccare l'intera pagina dal completamento del caricamento.

Per quantificare l'impatto per modulo, usa la funzionalità di blocco dei Chrome DevTools. Fai clic destro su una richiesta da un modulo specifico e scegli "Block request domain" o "Block request URL." Poi ricarica la pagina e confronta il tempo di caricamento. Questo ti dà una misura diretta di quanto le risorse di quel modulo contribuiscono al tuo tempo di caricamento totale della pagina. Ripeti per ogni modulo per costruire una classifica dal più pesante al più leggero.

Passaggio 4: Analisi dell'esecuzione degli hook

Capire quali hook utilizza ogni modulo è fondamentale per identificare il caricamento non necessario. Il sistema di hook di PrestaShop è il meccanismo attraverso cui i moduli iniettano contenuti, risorse e logica nelle pagine. Gli hook più rilevanti per le prestazioni delle pagine front office sono displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo e displayProductListFunctionalButtons.

L'hook displayHeader è l'hook più comunemente abusato nell'ecosistema PrestaShop. I moduli si registrano su questo hook per aggiungere i propri CSS e JavaScript nell'head della pagina. Il problema è che displayHeader viene eseguito su ogni singola pagina del front office. Se un modulo si registra su displayHeader senza verificare quale pagina sta visualizzando il cliente, carica le sue risorse ovunque.

Per vedere quali moduli sono registrati su ogni hook, vai su Design, quindi Posizioni nel tuo back office. Questa pagina mostra ogni hook e ogni modulo collegato ad esso. Cerca specificamente displayHeader e actionFrontControllerSetMedia. Conta quanti moduli sono registrati lì. In un negozio tipico con 30 o più moduli installati, potresti trovare da 15 a 20 moduli solo su displayHeader. Ognuno di essi aggiunge almeno un file CSS o JavaScript a ogni pagina.

Ora incrocia questi dati con le tue scoperte nei DevTools. Per ogni modulo su displayHeader, verifica se quel modulo ha effettivamente bisogno di caricarsi sulla pagina corrente. Un modulo di recensioni prodotto ha bisogno delle sue risorse solo sulle pagine prodotto. Un modulo lista desideri ha bisogno delle sue risorse solo sulle pagine prodotto e account. Un modulo guida taglie ha bisogno delle sue risorse solo sulle pagine prodotto. Eppure tutti si caricano sulla tua homepage, sulle tue pagine categoria, sulle tue pagine CMS e al tuo checkout.

I dati di profiling dal Passaggio 1 aggiungono un'altra dimensione a questa analisi. Alcuni moduli non solo caricano risorse non necessarie ma eseguono anche codice PHP costoso a ogni chiamata hook. Un modulo che esegue query al database nel suo metodo hookDisplayHeader per controllare valori di configurazione o recuperare dati sta sprecando risorse del server su ogni pagina, anche quando il suo output non è necessario.

Passaggio 5: Identificare i moduli più pesanti

Con i dati dal profiling, dai DevTools e dall'analisi degli hook, puoi ora classificare i tuoi moduli per il loro impatto sulle prestazioni. Crea un elenco con le seguenti colonne: nome del modulo, numero di file CSS caricati, dimensione totale CSS, numero di file JavaScript caricati, dimensione totale JavaScript, tempo di esecuzione server dal profiling, numero di query al database e pagine dove il modulo visualizza effettivamente contenuti.

I moduli che ottengono il punteggio più alto su queste metriche sono i tuoi peggiori offensori. Nella nostra esperienza di audit di centinaia di negozi PrestaShop, le seguenti categorie di moduli sono costantemente le meno performanti.

I moduli page builder sono spesso i più pesanti. Caricano framework CSS di grandi dimensioni, multiple librerie JavaScript per il loro editor visuale e talvolta caricano persino le risorse dell'editor sul front office. Un page builder che carica 300 KB di CSS e 500 KB di JavaScript su ogni pagina non è insolito.

I moduli di social media che incorporano widget da Facebook, Instagram o Twitter caricano script esterni che sono sia grandi sia imprevedibili nei tempi di caricamento. Un singolo widget feed Instagram può aggiungere 1 MB o più di JavaScript alla tua pagina.

I moduli di analytics e tracking che utilizzano pixel di tracciamento multipli caricano script da domini esterni. Ogni pixel di tracciamento aggiunge tipicamente da 20 a 50 KB di JavaScript più richieste di rete aggiuntive per immagini pixel e chiamate API.

I moduli slider e carosello caricano librerie JavaScript di grandi dimensioni come Slick, Owl Carousel o Swiper insieme ai loro CSS. Anche se lo slider appare solo sulla homepage, le risorse spesso si caricano su ogni pagina.

I moduli di live chat caricano bundle JavaScript sostanziosi per l'interfaccia del widget chat, tipicamente da 100 a 300 KB, più stabiliscono connessioni WebSocket che consumano risorse per tutta la sessione di navigazione.

Passaggio 6: Misurare le prestazioni prima e dopo

Prima di iniziare a disabilitare hook o rimuovere moduli, stabilisci una misurazione di base. Usa molteplici strumenti per ottenere un quadro completo.

In Chrome DevTools, vai alla scheda Lighthouse ed esegui un audit delle prestazioni. Registra il Performance Score, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Cumulative Layout Shift (CLS). Esegui l'audit tre volte e calcola la media dei risultati per tenere conto della variabilità.

Usa la scheda Performance nei DevTools per registrare una traccia di caricamento della pagina. Questo ti fornisce un flame chart che mostra esattamente cosa sta facendo il browser in ogni millisecondo. Cerca le long task (blocchi più lunghi di 50 millisecondi) e identifica quali script dei moduli le causano.

Misura anche il peso della tua pagina. Nella scheda Network, osserva il numero totale di richieste e la dimensione totale trasferita nella parte inferiore del pannello. Filtra per CSS e JS separatamente per ottenere i totali specifici dei moduli.

Registra tutti questi numeri prima di apportare qualsiasi modifica. Poi, man mano che ottimizzi i moduli scollegandoli dagli hook non necessari o disabilitandoli completamente, riesegui le stesse misurazioni. La differenza ti dice esattamente quante prestazioni hai guadagnato da ogni modifica.

Un audit dei moduli ben eseguito tipicamente riduce il peso della pagina dal 30 al 50 percento e migliora i tempi di caricamento da uno a due secondi. Nei negozi con molti moduli scarsamente ottimizzati, il miglioramento può essere ancora più significativo.

Passaggio 7: Disabilitare gli hook non necessari

Una volta identificato quali moduli caricano risorse su pagine dove non sono necessari, hai diverse opzioni per l'ottimizzazione. L'approccio più semplice è scollegare i moduli dagli hook dove non hanno bisogno di essere presenti.

Vai su Design, quindi Posizioni nel tuo back office. Trova il modulo sull'hook da cui vuoi rimuoverlo. Clicca sull'icona cestino o sul pulsante di sgancio per rimuovere il modulo da quello specifico hook. Questo impedisce al modulo di eseguirsi su quell'hook completamente.

Tuttavia, fai attenzione con questo approccio. Alcuni moduli usano displayHeader non solo per caricare CSS e JavaScript ma anche per eseguire attività di inizializzazione essenziali. Scollegare un tale modulo da displayHeader potrebbe comprometterne la funzionalità sulle pagine dove è effettivamente necessario. Testa sempre su un ambiente di staging o come minimo verifica le pagine specifiche dove il modulo dovrebbe ancora funzionare dopo lo sgancio.

Un approccio migliore a lungo termine è contattare lo sviluppatore del modulo e richiedere il caricamento condizionale delle risorse. Un modulo ben programmato dovrebbe verificare il controller corrente o il tipo di pagina prima di caricare le sue risorse. Ad esempio, un modulo di recensioni prodotto dovrebbe caricare i suoi CSS e JavaScript solo quando il controller corrente è ProductController. In questo modo, il modulo resta agganciato a displayHeader per compatibilità ma carica le risorse solo quando sono effettivamente necessarie.

Se ti senti a tuo agio a modificare il codice dei moduli, puoi aggiungere tu stesso i controlli condizionali. Nel metodo hookDisplayHeader o hookActionFrontControllerSetMedia del modulo, aggiungi un controllo per il nome del controller corrente. Se il controller non è uno di quelli dove il modulo visualizza contenuti, ritorna anticipatamente senza aggiungere alcuna risorsa. Questa è l'ottimizzazione più mirata ed efficace che puoi fare.

Checklist pratica per il tuo audit dei moduli

Per riassumere l'intero processo di audit, ecco una checklist pratica che puoi seguire. Inizia abilitando il profiling debug di PrestaShop. Apri la scheda Network dei DevTools e ricarica la tua homepage. Filtra le richieste per il percorso dei moduli ed elenca ogni risorsa dei moduli. Annota la dimensione e il tipo di ogni risorsa. Controlla Design, quindi Posizioni per i moduli su displayHeader. Incrocia le registrazioni degli hook con dove i moduli visualizzano effettivamente contenuti. Usa il blocco richieste dei DevTools per misurare l'impatto per modulo. Registra i punteggi Lighthouse di base. Scollega i moduli dagli hook dove non sono necessari. Aggiungi il caricamento condizionale ai moduli che si caricano globalmente. Rimisura i punteggi Lighthouse dopo ogni modifica. Documenta le tue scoperte e le modifiche per riferimento futuro.

Questo approccio sistematico garantisce di non perdere alcuna opportunità di ottimizzazione e ti fornisce dati concreti per giustificare ogni modifica apportata. Il bloat dei moduli non è un mistero. È un problema misurabile e risolvibile, e ogni negozio PrestaShop trae beneficio da un audit approfondito dei moduli almeno una volta all'anno.

Leggi la risposta completa

La causa principale: come il sistema di hook di PrestaShop gestisce le risorse

Se hai mai ispezionato il codice sorgente del tuo negozio PrestaShop e ti sei chiesto perché un modulo che mostra un widget solo sulle pagine prodotto sta caricando i suoi CSS e JavaScript sulla homepage, sulle pagine categoria e persino al checkout, non sei il solo. Questo è uno dei problemi di prestazioni più comuni nell'ecosistema PrestaShop, e deriva dal funzionamento del sistema di hook combinato con pratiche di sviluppo poco attente.

PrestaShop utilizza un'architettura basata su hook per consentire ai moduli di iniettare contenuti, risorse e logica in diverse parti di una pagina. Quando un modulo deve aggiungere file CSS o JavaScript alla pagina, lo fa generalmente attraverso uno dei due hook: displayHeader o actionFrontControllerSetMedia. Entrambi questi hook vengono eseguiti su ogni pagina del front office senza eccezione. Non esiste un meccanismo integrato nel sistema di hook per limitare la chiamata di un hook a specifici tipi di pagina. È interamente responsabilità dello sviluppatore del modulo verificare quale pagina viene caricata e decidere se aggiungere le risorse o meno.

Il problema è che molti sviluppatori di moduli prendono scorciatoie. Invece di scrivere una logica condizionale che controlla il controller corrente, registrano semplicemente le loro risorse in ogni chiamata hook. Il ragionamento è semplice: se le risorse sono sempre caricate, il modulo funzionerà sempre indipendentemente da dove appare il suo contenuto. Questo approccio "carica e dimentica" garantisce che il modulo funzioni correttamente, ma garantisce anche scarse prestazioni.

Come l'abuso dell'hook displayHeader crea il bloat delle pagine

L'hook displayHeader è il meccanismo principale attraverso cui i moduli aggiungono contenuti alla sezione head dell'HTML di ogni pagina. Quando un modulo implementa il metodo hookDisplayHeader, PrestaShop chiama quel metodo a ogni caricamento di pagina del front office. All'interno di questo metodo, i moduli tipicamente chiamano $this->context->controller->addCSS() e $this->context->controller->addJS() per registrare i loro file di risorse.

Ecco cosa succede in un negozio tipico con 25 moduli installati. Quindici di quei moduli hanno un metodo hookDisplayHeader. Ciascuno aggiunge tra uno e quattro file CSS e JavaScript. Questo significa che ogni singola pagina del tuo negozio carica da 15 a 60 richieste HTTP aggiuntive solo dai moduli, indipendentemente dal fatto che quei moduli visualizzino qualcosa sulla pagina corrente.

Considera un esempio concreto. Un modulo che aggiunge un popup guida taglie alle pagine prodotto ha bisogno di un file CSS per lo stile del popup e un file JavaScript per il comportamento del popup. Se lo sviluppatore registra queste risorse in hookDisplayHeader senza alcun controllo condizionale, quei due file si caricano sulla homepage, su ogni pagina categoria, sulla pagina carrello, sulla pagina checkout e su ogni pagina CMS. La guida taglie non apparirà mai su nessuna di quelle pagine, ma il browser scarica, analizza e processa comunque i file CSS e JavaScript.

Moltiplica questo per ogni modulo che segue lo stesso schema e inizierai a capire perché alcuni negozi PrestaShop caricano 2 MB o più di risorse dei moduli su pagine dove la maggior parte di quelle risorse è completamente inutile.

L'hook actionFrontControllerSetMedia

PrestaShop 1.7 ha introdotto l'hook actionFrontControllerSetMedia come alternativa più moderna a displayHeader per la registrazione delle risorse. Questo hook è stato progettato specificamente per registrare file CSS e JavaScript utilizzando i nuovi metodi registerStylesheet e registerJavascript. Questi metodi offrono vantaggi rispetto alle vecchie funzioni addCSS e addJS, inclusa la possibilità di impostare la priorità di caricamento, specificare attributi async o defer e controllare la posizione (head o bottom) dei tag script.

Tuttavia, actionFrontControllerSetMedia soffre dello stesso identico problema fondamentale di displayHeader: viene eseguito su ogni pagina. Un modulo che registra risorse in hookActionFrontControllerSetMedia senza verificare il controller corrente carica quelle risorse ovunque, proprio come l'approccio precedente.

L'unica differenza è il metodo di registrazione, non l'ambito di caricamento. Che uno sviluppatore usi addCSS in displayHeader o registerStylesheet in actionFrontControllerSetMedia, il risultato è lo stesso se non aggiunge logica condizionale. Le risorse si caricano globalmente.

Caricamento condizionale corretto: cosa fanno i moduli ben sviluppati

Un modulo ben sviluppato verifica quale pagina sta visualizzando il cliente prima di caricare qualsiasi risorsa. Il modo standard per farlo in PrestaShop è controllare il nome del controller. Ogni pagina del front office è servita da un controller specifico: IndexController per la homepage, CategoryController per le pagine categoria, ProductController per le pagine prodotto, CartController per il carrello e così via.

All'interno del metodo hookDisplayHeader o hookActionFrontControllerSetMedia, lo sviluppatore può accedere al controller corrente attraverso $this->context->controller. Controllando il nome della classe o la proprietà php_self del controller, il modulo può decidere se caricare le sue risorse. Un modulo di recensioni prodotto, ad esempio, dovrebbe verificare se la pagina corrente è una pagina prodotto e caricare i suoi CSS e JavaScript solo in quel caso.

Questo approccio condizionale non è difficile da implementare. Aggiunge forse da cinque a dieci righe di codice al metodo hook. Eppure un numero sorprendente di moduli, inclusi moduli a pagamento popolari sul marketplace PrestaShop Addons e moduli gratuiti ben noti, saltano completamente questo controllo. La ragione è una combinazione di comodità per lo sviluppatore e il fatto che PrestaShop non impone né incoraggia il caricamento condizionale nella sua documentazione per lo sviluppo di moduli.

Alcuni sviluppatori sostengono che il caricamento globale delle risorse garantisce la compatibilità con temi personalizzati o configurazioni di pagina insolite dove il contenuto del modulo potrebbe apparire inaspettatamente. Anche se questo argomento ha un fondo di verità, non giustifica il costo in termini di prestazioni. Un approccio migliore è caricare le risorse in modo condizionale per impostazione predefinita e fornire un'opzione di configurazione per abilitare il caricamento globale per i negozi che ne hanno bisogno.

Il metodo setMedia: best practice per gli sviluppatori di moduli

Per gli sviluppatori di moduli che leggono questo articolo, ecco le best practice per il caricamento delle risorse che rispettano le prestazioni del sito dei vostri utenti.

Primo, utilizzate sempre l'hook actionFrontControllerSetMedia invece di displayHeader per la registrazione delle risorse in PrestaShop 1.7 e versioni successive. L'hook più recente fornisce un controllo migliore sul comportamento di caricamento delle risorse e mantiene la registrazione delle risorse separata dall'output HTML.

Secondo, controllate sempre il controller corrente prima di registrare le risorse. Usate un approccio whitelist: definite l'elenco dei controller dove il vostro modulo visualizza contenuti e registrate le risorse solo quando il controller corrente è in quell'elenco. Questo è più manutenibile di un approccio blacklist perché i nuovi tipi di pagina aggiunti nelle future versioni di PrestaShop non caricheranno accidentalmente le vostre risorse.

Terzo, utilizzate registerStylesheet e registerJavascript invece di addCSS e addJS. I metodi più recenti consentono di specificare un id per ogni risorsa, il che rende possibile per i temi e altri moduli sovrascrivere o rimuovere le vostre risorse in modo pulito. Supportano anche impostazioni di priorità che controllano l'ordine in cui le risorse vengono caricate.

Quarto, considerate se il vostro JavaScript deve veramente caricarsi nell'head o se può caricarsi alla fine della pagina con l'attributo defer. Il JavaScript nell'head blocca il rendering, il che significa che il browser non può visualizzare alcun contenuto fino a quando il vostro script non ha terminato il download e il parsing. Spostare gli script in fondo alla pagina o aggiungere defer elimina questo comportamento di blocco del rendering.

Quinto, minimizzate le dimensioni dei vostri file di risorse. Minificate i vostri file CSS e JavaScript prima di distribuire il vostro modulo. Rimuovete le regole CSS inutilizzate. Evitate di includere intere librerie come jQuery UI o Bootstrap quando utilizzate solo una piccola parte delle loro funzionalità. Ogni kilobyte conta quando le risorse del vostro modulo si caricano su migliaia di visualizzazioni di pagina al giorno.

Misurare l'impatto sulle prestazioni del caricamento globale delle risorse

Per capire quanto costa al tuo negozio il caricamento globale delle risorse, hai bisogno di misurazioni concrete. Apri Chrome DevTools sulla tua homepage e vai alla scheda Network. Ricarica la pagina e filtra le richieste per il percorso /modules/. Conta il numero totale di richieste e la loro dimensione combinata. Questo è l'overhead delle risorse dei moduli su una pagina dove la maggior parte dei moduli non visualizza alcun contenuto.

Ora fai lo stesso su una pagina prodotto, dove molti moduli hanno legittimamente bisogno delle loro risorse. Confronta i numeri. In un negozio ben ottimizzato, la pagina prodotto dovrebbe caricare significativamente più risorse dei moduli rispetto alla homepage perché è lì che la maggior parte dei moduli visualizza i propri contenuti. In un negozio scarsamente ottimizzato, i numeri sono quasi identici perché ogni modulo carica tutto ovunque.

Un benchmark concreto da audit reali: un negozio con 35 moduli installati caricava 1,8 MB di CSS e JavaScript dei moduli sulla homepage. Dopo aver implementato il caricamento condizionale su tutti i moduli, le risorse dei moduli sulla homepage sono scese a 340 KB. La pagina prodotto, dove la maggior parte dei moduli aveva legittimamente bisogno delle proprie risorse, è passata da 2,1 MB a 1,4 MB. Il tempo di caricamento della homepage è migliorato di 1,3 secondi e il punteggio prestazioni di Lighthouse è passato da 42 a 71.

Questi numeri non sono insoliti. Il caricamento globale delle risorse è una delle singole maggiori fonti di peso della pagina non necessario nei negozi PrestaShop, e correggerlo produce spesso i miglioramenti di prestazioni più significativi.

Come identificare i moduli problematici nel tuo negozio

Trovare quali moduli caricano risorse globalmente richiede un approccio sistematico. Inizia con la scheda Network nei DevTools come descritto sopra. Per ogni risorsa di modulo che trovi caricata sulla homepage, chiediti: questo modulo visualizza contenuti sulla homepage? Se la risposta è no, quel modulo sta caricando risorse inutilmente.

Un altro approccio è utilizzare la modalità di profiling debug di PrestaShop. Quando il profiling è abilitato (impostando _PS_DEBUG_PROFILING_ su true nel tuo config/defines.inc.php), PrestaShop mostra dati dettagliati sull'esecuzione degli hook nella parte inferiore di ogni pagina. Questi dati ti mostrano esattamente quali moduli vengono eseguiti su ogni hook e quanto tempo impiegano. Qualsiasi modulo che viene eseguito su displayHeader o actionFrontControllerSetMedia ma non viene eseguito su nessun hook di visualizzazione che produce output visibile sulla pagina corrente è un candidato per l'ottimizzazione.

Puoi anche verificare a livello di codice esaminando il codice sorgente di ogni modulo. Guarda i metodi hookDisplayHeader e hookActionFrontControllerSetMedia nel file PHP principale del modulo. Se il metodo contiene chiamate addCSS, addJS, registerStylesheet o registerJavascript senza alcun controllo condizionale sul nome del controller, quel modulo carica le risorse globalmente.

Per i negozi con molti moduli, questa revisione manuale può richiedere molto tempo. Una scorciatoia pratica è concentrarsi prima sulle risorse più grandi. Ordina le risorse dei moduli nella scheda Network per dimensione e inizia a indagare sui file più grandi. Un file JavaScript da 200 KB che si carica globalmente è un problema molto più grande di un file CSS da 3 KB, quindi dai priorità di conseguenza.

Richiedere correzioni agli sviluppatori dei moduli

Quando identifichi un modulo che carica risorse globalmente, il tuo primo passo dovrebbe essere contattare lo sviluppatore e richiedere una correzione. La maggior parte degli sviluppatori di moduli professionali è ricettiva alle richieste di miglioramento delle prestazioni, specialmente quando puoi fornire dati specifici sull'impatto.

Scrivi un messaggio chiaro e tecnico che spieghi il problema. Menziona che il metodo hookDisplayHeader del modulo carica CSS e JavaScript su ogni pagina senza controllare il controller corrente. Specifica quali pagine hanno effettivamente bisogno delle risorse e quali pagine le caricano inutilmente. Includi le dimensioni dei file e l'impatto stimato sulle prestazioni. Se hai punteggi Lighthouse che mostrano il prima e il dopo quando le risorse del modulo vengono bloccate, includili.

Se lo sviluppatore è reattivo, tipicamente rilascerà un aggiornamento entro poche settimane che aggiunge il caricamento condizionale. Se lo sviluppatore non risponde o ignora la preoccupazione, hai diverse opzioni: implementare il caricamento condizionale tu stesso modificando il codice del modulo, utilizzare un modulo di ottimizzazione delle prestazioni che può bloccare selettivamente le risorse su pagine specifiche, oppure trovare un modulo alternativo che segua migliori pratiche di sviluppo.

Soluzioni alternative quando non puoi modificare il modulo

A volte non puoi modificare un modulo direttamente. Potrebbe essere criptato con IonCube, potrebbe essere un modulo di cui non vuoi mantenere un fork, oppure il modulo potrebbe sovrascrivere le tue modifiche a ogni aggiornamento. In questi casi, hai bisogno di soluzioni alternative.

Una soluzione alternativa efficace è creare un piccolo modulo personalizzato che sgancia il modulo problematico da displayHeader e actionFrontControllerSetMedia, poi riaggiunge le risorse solo sulle pagine dove sono necessarie. Questo modulo personalizzato utilizzerebbe l'hook actionFrontControllerSetMedia con una priorità alta (così viene eseguito dopo il modulo problematico) e chiamerebbe Media::unregisterStylesheet e Media::unregisterJavascript per rimuovere le risorse caricate globalmente. Poi, sulle pagine dove le risorse sono effettivamente necessarie, le ri-registrerebbe.

Un'altra soluzione alternativa è utilizzare il file Theme.yml per sovrascrivere le risorse dei moduli. In PrestaShop 1.7 e versioni successive, il file di configurazione theme.yml del tema può rimuovere risorse specifiche dei moduli dal caricamento. Questa è una soluzione a livello di tema che persiste tra gli aggiornamenti dei moduli. Tuttavia, rimuove le risorse da tutte le pagine, non selettivamente, quindi dovresti combinarla con la riaggiunta delle risorse su pagine specifiche attraverso un modulo personalizzato o un template del tema.

Una terza opzione, disponibile in PrestaShop 8.x, è utilizzare le funzionalità integrate di priorità e rimozione del sistema di gestione delle risorse. PrestaShop 8 ha migliorato la pipeline delle risorse per dare ai temi maggiore controllo su quali risorse dei moduli vengono caricate. Consulta la documentazione del tuo tema per istruzioni specifiche su come sfruttare queste funzionalità.

Indipendentemente dall'approccio scelto, testa sempre accuratamente dopo aver apportato le modifiche. Rimuovere il CSS di un modulo può comprometterne l'aspetto visivo, e rimuovere il suo JavaScript può compromettere le funzionalità interattive. Testa ogni tipo di pagina dove il modulo dovrebbe ancora funzionare correttamente.

Prevenzione: valutare i moduli prima dell'installazione

Il modo migliore per evitare problemi di caricamento globale delle risorse è valutare i moduli prima di installarli. Sebbene questo non sia sempre possibile, ci sono verifiche che puoi eseguire.

Se il modulo fornisce un negozio demo, visitalo e ispeziona la homepage con i DevTools. Controlla se le risorse del modulo si caricano su pagine dove il modulo non visualizza contenuti. Se le risorse si caricano globalmente nella demo, si caricheranno globalmente anche nel tuo negozio.

Se hai accesso al codice sorgente del modulo prima dell'acquisto (alcuni marketplace forniscono anteprime del codice), guarda i metodi hookDisplayHeader e hookActionFrontControllerSetMedia. Controlla la presenza di logica di caricamento condizionale. L'assenza di qualsiasi controllo sul controller è un segnale d'allarme.

Leggi le recensioni e il forum di supporto del modulo. Gli utenti attenti alle prestazioni segnalano spesso problemi di caricamento globale delle risorse nelle recensioni. Se più utenti si sono lamentati del fatto che il modulo rallenta il loro negozio, prendi sul serio quel feedback.

Infine, considera la qualità complessiva del codice dello sviluppatore. Gli sviluppatori che seguono le best practice in un'area tendono a seguirle anche nelle altre. Se il codice di un modulo è pulito, ben documentato e segue gli standard di codifica di PrestaShop, è più probabile che gestisca correttamente il caricamento delle risorse. Se il codice è disordinato e mal strutturato, il caricamento globale delle risorse è probabilmente solo uno dei tanti problemi.

Leggi la risposta completa

Perché usare Cloudflare con PrestaShop?

Cloudflare si posiziona tra i tuoi visitatori e il tuo server PrestaShop, agendo come reverse proxy che fornisce protezione DDoS, un Web Application Firewall (WAF), una CDN globale per le risorse statiche e la terminazione SSL/TLS. Quando configurato correttamente, Cloudflare può migliorare notevolmente i tempi di caricamento delle pagine del tuo negozio, ridurre la larghezza di banda del server e bloccare il traffico malevolo prima che raggiunga il tuo hosting. Tuttavia, una configurazione errata di Cloudflare è una delle cause più comuni di loop di redirect, checkout malfunzionanti, IP dei clienti errati e disastri di caching in PrestaShop. Questa guida ti accompagna attraverso ogni passaggio di una configurazione corretta.

Passaggio 1: Configurazione DNS

Dopo aver aggiunto il tuo dominio a Cloudflare, devi configurare i tuoi record DNS. La decisione più importante è quali record devono essere proxied (nuvola arancione) rispetto a quelli solo DNS (nuvola grigia).

Record proxied (nuvola arancione):

Il tuo record A o AAAA principale che punta all'IP del tuo server (es. esempio.com e www.esempio.com)
Qualsiasi CNAME per sottodomini che servono contenuti web

Record solo DNS (nuvola grigia):

Record MX (posta) — questi non devono mai essere proxied
Record utilizzati per FTP, SSH o altri servizi non HTTP
Record che puntano a server di posta (es. mail.esempio.com)

Importante: Se utilizzi un sottodominio per il back office del tuo PrestaShop (es. admin.esempio.com), puoi proxarlo, ma fai attenzione alle regole di caching discusse più avanti. Non creare mai un record DNS che esponga inutilmente il tuo vero IP del server — una volta che il dominio principale è proxied, gli aggressori che conoscono l'IP reale possono bypassare completamente Cloudflare. Considera di cambiare l'IP del tuo server dopo aver abilitato Cloudflare se era precedentemente pubblico.

Passaggio 2: Configurazione SSL/TLS — Usa Full (Strict)

Questa è la singola impostazione più critica. Vai su SSL/TLS > Panoramica nella tua dashboard Cloudflare.

Usa sempre la modalità Full (Strict). Ecco cosa fa ogni modalità e perché le altre sono sbagliate per PrestaShop:

Off: Nessuna crittografia. Non usare mai questa modalità per un negozio e-commerce.
Flexible: Crittografa il traffico tra il visitatore e Cloudflare, ma invia HTTP non crittografato al tuo server. Questo causa loop di redirect infiniti in PrestaShop perché il server vede HTTP, imposta force_ssl = 1, reindirizza a HTTPS, Cloudflare lo consegna tramite HTTPS, ma la richiesta successiva arriva al server di nuovo come HTTP. Questo è l'errore numero uno con Cloudflare e PrestaShop.
Full: Crittografa end-to-end ma non valida il certificato SSL del tuo server. Accettabile ma non raccomandato.
Full (Strict): Crittografa end-to-end e valida il tuo certificato di origine. Questa è la modalità corretta. Se non hai un certificato SSL a pagamento, usa un certificato Cloudflare Origin gratuito (valido 15 anni) installato sul tuo server.

Per installare un certificato Cloudflare Origin: vai su SSL/TLS > Origin Server > Create Certificate. Scarica il certificato e la chiave privata, installali nel tuo web server (Apache o Nginx) e riavvia il servizio. Questo certificato è valido solo per il traffico che passa attraverso Cloudflare — risulterà non valido se vi si accede direttamente.

Sotto SSL/TLS > Edge Certificates, abilita:

Always Use HTTPS: Sì
Automatic HTTPS Rewrites: Sì (corregge i contenuti misti riscrivendo gli URL HTTP in HTTPS)
Minimum TLS Version: TLS 1.2

Passaggio 3: Configurazione del caching

Il comportamento di caching predefinito di Cloudflare funziona bene per le risorse statiche ma può causare gravi problemi se mette in cache le pagine dinamiche di PrestaShop. Vai su Caching > Configuration.

Impostazioni consigliate:

Caching Level: Standard
Browser Cache TTL: Respect Existing Headers (lascia che PrestaShop controlli il caching del browser tramite le sue impostazioni CCC)
Always Online: Disabilita questa opzione per i negozi e-commerce — mostrare pagine prodotto obsolete con prezzi errati o articoli esauriti è peggio che mostrare una pagina di errore

Cosa mette in cache Cloudflare per impostazione predefinita: Solo estensioni di file statici come .js, .css, .png, .jpg, .gif, .svg, .woff2, .ico. NON mette in cache le pagine HTML per impostazione predefinita, il che è corretto per PrestaShop. Non abilitare "Cache Everything" senza regole di bypass appropriate, altrimenti i tuoi clienti vedranno i carrelli, le sessioni e i dati personali di altre persone.

Passaggio 4: Page Rules e Cache Rules

Le Page Rules (o le più recenti Cache Rules) ti consentono di personalizzare il comportamento di Cloudflare per specifici pattern URL. Per PrestaShop, hai bisogno di regole che proteggano il pannello admin e il checkout dal caching ottimizzando al contempo la distribuzione dei contenuti statici.

Regola 1: Bypass cache per il pannello admin

Crea una regola che corrisponda a esempio.com/admin* (sostituisci "admin" con il nome effettivo della directory del tuo back office):

Cache Level: Bypass
Disable Performance: Sì (disabilita Rocket Loader, Mirage e altre ottimizzazioni che possono rompere il JS dell'admin)
Security Level: High

Regola 2: Bypass cache per checkout e carrello

Crea una regola che corrisponda a esempio.com/order* e un'altra per esempio.com/cart* (oppure usa esempio.com/*order* se utilizzi URL amichevoli):

Cache Level: Bypass
Disable Performance: Sì

Se il tuo PrestaShop utilizza URL di checkout generati da moduli (come quelli dei moduli express checkout), aggiungi regole anche per quei percorsi.

Regola 3: Bypass cache per l'account cliente

Corrisponde a esempio.com/my-account* o esempio.com/identity* e qualsiasi altra pagina autenticata rivolta al cliente:

Cache Level: Bypass

Regola 4: Cache aggressiva per le risorse statiche

Corrisponde a esempio.com/themes/* e esempio.com/js/* e esempio.com/modules/*/views/css/*:

Cache Level: Cache Everything
Edge Cache TTL: 1 mese
Browser Cache TTL: 1 settimana

Nota sul nuovo sistema di Rules: Cloudflare sta migrando dalle Page Rules a Cache Rules, Configuration Rules e Transform Rules separate. La logica è la stessa — crea una Cache Rule con un'espressione di filtro personalizzata come (http.request.uri.path contains "/admin") e imposta l'azione su bypass cache.

Passaggio 5: Rocket Loader — Disabilitalo

Rocket Loader è la funzionalità di Cloudflare che differisce il caricamento di tutto il JavaScript sulle tue pagine. Vai su Speed > Optimization > Content Optimization e disabilita Rocket Loader.

Sebbene sembri vantaggioso, Rocket Loader causa gravi problemi con PrestaShop:

Pulsanti aggiungi al carrello non funzionanti: PrestaShop si basa su blocchi JavaScript inline e gestori jQuery ready che devono essere eseguiti in ordine. Rocket Loader li differisce e li riordina.
Guasti ai moduli di pagamento: I gateway di pagamento come PayPal, Stripe e Mollie iniettano il proprio JavaScript con cui Rocket Loader interferisce, causando errori al checkout e ordini persi.
Rottura del pannello admin: Il back office utilizza JavaScript inline estensivo per la validazione dei form, le chiamate AJAX e le pagine di configurazione dei moduli. Rocket Loader rompe tutto questo.
Moduli di cookie consent e GDPR: Questi si basano sul blocco di determinate risorse fino a quando non viene dato il consenso. Rocket Loader mina questo meccanismo riscrivendo il modo in cui tutte le risorse esterne vengono caricate.

Anche se imposti una Page Rule per disabilitare le funzionalità di prestazione su /admin*, il front office si romperà comunque. L'approccio più sicuro è disabilitare Rocket Loader globalmente.

Passaggio 6: Ripristino dell'IP reale

Quando Cloudflare proxa il traffico, il tuo server vede gli indirizzi IP di Cloudflare invece degli IP reali dei tuoi visitatori. Questo compromette PrestaShop in diversi modi: i record degli ordini mostrano IP di Cloudflare, il rilevamento delle frodi non funziona, la geolocalizzazione è errata, il rate limiting non funziona e i dati di analytics sono inutili.

Apache (mod_remoteip)

Installa e abilita il modulo:

sudo a2enmod remoteip
sudo systemctl restart apache2

Aggiungi alla tua configurazione Apache (virtual host o globale):

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22

Cloudflare pubblica i propri intervalli IP su cloudflare.com/ips — controlla periodicamente e aggiorna la tua configurazione se cambiano.

Nginx

Usa il ngx_http_realip_module (generalmente compilato per impostazione predefinita):

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... aggiungi tutti gli intervalli Cloudflare ...
real_ip_header CF-Connecting-IP;

Configurazione PrestaShop

Anche con mod_remoteip, alcuni moduli PrestaShop leggono l'IP da $_SERVER['HTTP_CF_CONNECTING_IP'] o $_SERVER['HTTP_X_FORWARDED_FOR']. Se continui a vedere gli IP di Cloudflare negli ordini dopo aver configurato mod_remoteip, controlla il config/defines.inc.php del tuo PrestaShop per eventuali override relativi agli IP o aggiungi il seguente codice (non sempre necessario se mod_remoteip funziona correttamente):

if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

Passaggio 7: Regole WAF (Web Application Firewall)

Il WAF di Cloudflare protegge il tuo negozio da SQL injection, XSS e altri attacchi. Con il piano gratuito, ottieni una protezione di base. Con il piano Pro e superiori, ottieni i ruleset gestiti.

Impostazioni WAF consigliate

Security Level: Medium (sotto Security > Settings). "High" potrebbe attivare verifiche per clienti legittimi su reti mobili o VPN.
Challenge Passage: 30 minuti (per quanto tempo un visitatore resta verificato dopo aver risolto una verifica)
Bot Fight Mode: Abilita con cautela — può bloccare i callback dei gateway di pagamento (IPN) da PayPal, Stripe, ecc. Se lo abiliti, aggiungi eccezioni WAF per i percorsi webhook noti come /module/paypal/notify.

Regole WAF personalizzate per PrestaShop

Crea queste regole firewall sotto Security > WAF > Custom Rules:

Blocca l'accesso diretto a file sensibili:

Espressione: (http.request.uri.path contains "config/settings.inc.php") or (http.request.uri.path contains ".env") or (http.request.uri.path contains "composer.json") or (http.request.uri.path contains "var/logs/")

Azione: Blocca

Rate limiting per i tentativi di login:

Usa le Rate Limiting Rules per limitare le richieste al tuo URL di login admin (es. /adminXYZ/index.php) a 5 richieste al minuto per IP. Questo previene gli attacchi brute force al back office.

Whitelist degli IP dei provider di pagamento:

Se usi Bot Fight Mode, crea una regola Allow per gli IP webhook del tuo provider di pagamento in modo che i loro callback server-to-server non vengano mai sottoposti a verifica.

Passaggio 8: Impostazioni delle prestazioni

Vai su Speed > Optimization e configura:

Auto Minify: Abilita per JavaScript, CSS e HTML. Il CCC (Combine, Compress, Cache) di PrestaShop esegue la propria minificazione, quindi potrebbe esserci una doppia minificazione, ma questo è generalmente innocuo. Se noti problemi di rendering, disabilita la minificazione CSS di Cloudflare e affidati al CCC di PrestaShop.
Brotli: Abilita — compressione migliore di gzip, supportata da tutti i browser moderni
Early Hints: Abilita — comunica ai browser di precaricare risorse critiche prima che l'HTML sia completamente consegnato
HTTP/2: Abilitato per impostazione predefinita su tutti i piani Cloudflare
HTTP/3 (QUIC): Abilita per migliori prestazioni su reti mobili

Mirage (piano Pro): Se disponibile, abilitalo. Mirage esegue il lazy-load delle immagini e serve immagini di dimensioni appropriate in base al dispositivo del visitatore. Funziona bene con le immagini prodotto di PrestaShop.

Polish (piano Pro): Abilita con compressione "Lossy" per le immagini prodotto, o "Lossless" se la qualità dell'immagine è critica (es. stampe artistiche). Polish comprime le immagini al volo sull'edge senza modificare gli originali.

Passaggio 9: Svuotare la cache di Cloudflare

Quando aggiorni il design del tuo negozio, aggiungi nuovi prodotti o modifichi file CSS/JS, devi svuotare la cache di Cloudflare affinché i visitatori vedano l'ultima versione.

Metodi per lo svuotamento:

Purge Everything: Dashboard > Caching > Configuration > Purge Everything. Usa con parsimonia — forza il ri-scaricamento di tutte le risorse dal tuo server.
Purge per URL: Svuota file specifici come esempio.com/themes/il-tuo-tema/assets/css/theme.css
Purge per Tag / Prefisso: Disponibile nei piani Enterprise
Purge via API: Usa l'API di Cloudflare per automatizzare lo svuotamento della cache dopo i deploy. Puoi integrarlo nel tuo flusso di deploy dei moduli PrestaShop.

Il sistema CCC di PrestaShop aggiunge stringhe di versione ai file CSS e JS (es. theme.css?v=12345), il che naturalmente invalida la cache di Cloudflare quando i file cambiano. Se ti affidi correttamente al CCC, raramente hai bisogno di svuotamenti manuali della cache per le risorse statiche.

Errori comuni e come evitarli

Errore 1: SSL impostato su Flexible

Sintomi: Loop di redirect infinito, ERR_TOO_MANY_REDIRECTS, pagina bianca. Soluzione: Cambia la modalità SSL a Full (Strict) e installa un certificato di origine sul tuo server.

Errore 2: Caching delle pagine dinamiche

Sintomi: Il cliente A vede il carrello o i dettagli dell'account del cliente B, prezzi errati visualizzati, gli utenti loggati vedono contenuti da utente sloggato. Soluzione: Non usare mai "Cache Everything" come impostazione globale. Metti in cache solo i percorsi delle risorse statiche. Esegui sempre il bypass della cache per /order, /cart, /my-account e il pannello admin.

Errore 3: Rocket Loader abilitato

Sintomi: L'aggiungi al carrello non funziona, i form di pagamento non si caricano, i moduli del back office generano errori JavaScript, le gallerie della pagina prodotto non funzionano. Soluzione: Disabilita Rocket Loader globalmente.

Errore 4: Mancato ripristino degli IP reali

Sintomi: Tutti gli ordini mostrano lo stesso indirizzo IP (un IP di Cloudflare), i moduli di geolocalizzazione mostrano paesi errati, il rate limiting blocca Cloudflare invece degli aggressori. Soluzione: Configura mod_remoteip o ngx_http_realip_module come descritto sopra.

Errore 5: Bot Fight Mode che blocca i webhook

Sintomi: Le conferme di pagamento non arrivano mai, gli ordini restano in stato "In attesa di pagamento", i log IPN/webhook mostrano risposte 403 o verifiche. Soluzione: Crea regole di eccezione WAF per gli URL webhook e gli intervalli IP dei provider di pagamento.

Errore 6: Problemi email dopo la configurazione

Sintomi: Le email smettono di funzionare, la validazione SPF/DKIM fallisce. Causa: I record DNS relativi alla posta (MX, SPF TXT, DKIM) sono stati accidentalmente impostati come proxied (nuvola arancione). Soluzione: Tutti i record DNS email devono essere solo DNS (nuvola grigia). Il proxying funziona solo per il traffico HTTP/HTTPS.

Errore 7: Development Mode lasciato attivo

Sintomi: La cache non funziona mai, carico elevato sul server di origine. Causa: La Development Mode è stata abilitata durante la configurazione e dimenticata. Soluzione: Disabilita la Development Mode in Caching > Configuration una volta completata la configurazione. La Development Mode si disabilita automaticamente dopo 3 ore, ma controlla comunque.

Checklist di risoluzione dei problemi

Quando qualcosa va storto con Cloudflare e PrestaShop, segui questa checklist:

Loop di redirect: Controlla la modalità SSL (deve essere Full o Full Strict), controlla il .htaccess per redirect HTTPS duplicati, verifica che PS_SSL_ENABLED di PrestaShop sia impostato a 1 nel database.
Avvisi di contenuti misti: Abilita Automatic HTTPS Rewrites in Cloudflare, controlla URL http:// hardcoded nel tuo tema o nelle pagine CMS.
TTFB lento (Time to First Byte): Cloudflare non mette in cache l'HTML per impostazione predefinita. Un TTFB lento significa che il tuo server di origine è lento — ottimizza PrestaShop (abilita CCC, configura OPcache, controlla le query al database) piuttosto che dare la colpa a Cloudflare.
CSS/JS non si aggiornano: Svuota la cache CCC di PrestaShop (back office > Prestazioni), poi svuota la cache di Cloudflare. Controlla che il CCC stia aggiungendo stringhe di versione agli URL dei file.
Pannello admin lento o non funzionante: Assicurati che la tua Page Rule esegua il bypass della cache e disabiliti le funzionalità di prestazione per la directory admin. Controlla che il WAF di Cloudflare non stia bloccando le richieste AJAX dell'admin.
Clienti sottoposti a verifiche: Abbassa il Security Level a Medium o Low. Controlla che l'Under Attack Mode non sia abilitato (dovrebbe essere usato solo durante attacchi DDoS attivi). Rivedi gli eventi firewall in Security > Events per vedere quali regole vengono attivate.
Chiamate API che falliscono: Se il tuo negozio ha endpoint API REST o web service, assicurati che Cloudflare non stia verificando o bloccando le richieste API. Crea una regola WAF per consentire le richieste a /api/* da intervalli IP noti.
Immagini che non si caricano: Controlla se la Hotlink Protection è abilitata e sta accidentalmente bloccando il tuo stesso dominio. Verifica che gli URL delle immagini utilizzino HTTPS.

Cloudflare con PrestaShop Multistore

Se gestisci PrestaShop multistore con più domini, ogni dominio deve essere aggiunto a Cloudflare separatamente (nel piano gratuito, ogni dominio è una zona separata). Assicurati che:

La modalità SSL sia impostata su Full (Strict) su ogni zona
Le Page Rules siano duplicate per ogni dominio
Il ripristino dell'IP reale copra tutti i domini (mod_remoteip è globale, quindi una sola configurazione gestisce tutti i virtual host)

Piano Cloudflare consigliato per PrestaShop

Il piano gratuito copre la maggior parte delle esigenze: DNS, CDN, WAF di base e SSL. Il piano Pro (circa 20 USD/mese) aggiunge Mirage, Polish, ruleset WAF gestiti e più Page Rules. Per negozi ad alto traffico, il piano Business aggiunge regole WAF personalizzate e funzionalità di prestazione aggiuntive. La maggior parte dei negozi PrestaShop di piccole e medie dimensioni funziona perfettamente con il piano gratuito o Pro.

Riepilogo

Configurare correttamente Cloudflare con PrestaShop si riduce a poche decisioni critiche: usa SSL Full (Strict), disabilita Rocket Loader, esegui il bypass della cache sulle pagine dinamiche, ripristina gli IP reali dei visitatori e proteggi i webhook di pagamento dalla protezione bot. Fai queste cose giuste fin dall'inizio e Cloudflare diventa un potente alleato per le prestazioni e la sicurezza del tuo negozio. Sbaglia e passerai ore a fare debug di loop di redirect, checkout non funzionanti e ordini fantasma. Prenditi il tempo per configurarlo correttamente una volta sola e il tuo negozio PrestaShop beneficerà di tempi di caricamento più rapidi a livello globale, carico del server ridotto e protezione robusta contro gli attacchi.

Leggi la risposta completa

Cos'è il WebP e perché è importante per PrestaShop

WebP è un formato di immagine moderno sviluppato da Google che fornisce compressione sia lossy che lossless per le immagini web. Rispetto ai formati tradizionali come JPEG e PNG, WebP offre generalmente dimensioni di file inferiori del 25-35% a parità di qualità visiva. Per un negozio e-commerce che utilizza PrestaShop, dove le pagine prodotto contengono spesso decine di immagini, il passaggio a WebP può ridurre notevolmente il peso della pagina, migliorare i tempi di caricamento e aumentare i punteggi Core Web Vitals—tutti fattori che influenzano direttamente il posizionamento SEO e i tassi di conversione.

A differenza dei formati di nuova generazione più vecchi che hanno faticato con l'adozione, WebP ha raggiunto un supporto quasi universale da parte dei browser. Nel 2026, ogni browser principale—Chrome, Firefox, Safari, Edge, Opera e le loro controparti mobile—supporta pienamente WebP. Anche i vecchi ritardatari come le versioni più datate di Safari su macOS Catalina sono ormai statisticamente irrilevanti, rappresentando meno dello 0,3% del traffico globale. Questo significa che puoi servire con sicurezza immagini WebP a praticamente tutti i visitatori senza preoccuparti di problemi di compatibilità.

Per i commercianti PrestaShop, i guadagni in prestazioni sono sostanziali. Un catalogo prodotti tipico con 1.000 prodotti e 5 immagini ciascuno può vedere il payload totale delle immagini ridotto da 500 MB a meno di 350 MB. Sulle pagine di elenco prodotti che mostrano 20-40 miniature, questo si traduce in 200-400 KB risparmiati per caricamento di pagina—sufficienti per migliorare significativamente le metriche Time to First Contentful Paint e Largest Contentful Paint.

Abilitare WebP in PrestaShop 1.7 e 8.x

PrestaShop 1.7.8+ e tutte le versioni 8.x includono supporto WebP nativo. La funzionalità è integrata nel sistema di rigenerazione delle immagini e può essere abilitata attraverso il back office. Ecco come attivarla:

Vai su Design > Impostazioni Immagini (in PS 8.x) o Preferenze > Immagini (in PS 1.7).
Cerca la sezione Opzioni di generazione immagini nella parte inferiore della pagina.
Trova l'impostazione Formato immagine e seleziona una delle opzioni relative a WebP. PrestaShop offre generalmente: solo JPEG, solo PNG, solo WebP, oppure JPEG/PNG + WebP (genera entrambi i formati).
Seleziona JPEG/PNG + WebP se vuoi la compatibilità con fallback, oppure solo WebP se sei certo che tutti i tuoi visitatori utilizzano browser moderni.
Imposta il cursore Qualità WebP. Un valore tra 80 e 85 offre un equilibrio eccellente tra dimensione del file e qualità visiva per la fotografia di prodotti.
Clicca Salva, poi clicca Rigenera miniature per creare le versioni WebP di tutte le immagini esistenti.

Il processo di rigenerazione può richiedere un tempo significativo per cataloghi di grandi dimensioni. Per un negozio con oltre 5.000 prodotti, aspettati che il processo duri da 30 minuti a diverse ore a seconda delle risorse del server. È fortemente raccomandato eseguire la rigenerazione durante le ore di minor traffico o tramite CLI per evitare problemi di timeout PHP.

Rigenerazione CLI per cataloghi di grandi dimensioni

Per i negozi con migliaia di prodotti, la rigenerazione basata sul browser probabilmente andrà in timeout. Usa invece l'approccio CLI:

php bin/console prestashop:image:regenerate --format=all

Questo comando viene eseguito senza i vincoli di timeout del web server. Puoi anche selezionare specifici tipi di immagine:

php bin/console prestashop:image:regenerate --type=products --format=all
php bin/console prestashop:image:regenerate --type=categories --format=all

Nelle versioni di PrestaShop 1.7 che non dispongono del comando console, puoi aumentare i limiti di timeout di PHP ed eseguire la rigenerazione tramite il pannello admin, oppure utilizzare uno script PHP personalizzato che chiama direttamente la classe ImageManager.

Configurazione del server: regole Apache .htaccess

Anche dopo aver abilitato la generazione WebP in PrestaShop, il tuo server deve essere configurato per servire il formato corretto. PrestaShop genera i file WebP insieme ai file JPEG/PNG originali, ma il server deve sapere quando servire quale formato.

Per i server Apache, aggiungi le seguenti regole al tuo file .htaccess nella directory root di PrestaShop o nella directory img/:

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Serve immagini WebP se il browser le supporta e il file esiste
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png)$
  RewriteCond %1.webp -f
  RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>

# Imposta il tipo MIME corretto per WebP
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

# Header Vary per prevenire problemi di caching
<IfModule mod_headers.c>
  Header append Vary Accept env=REQUEST_image
</IfModule>

Queste regole funzionano come segue: quando un browser richiede un file JPEG o PNG, il server verifica se il browser invia un header Accept: image/webp. Se lo fa, e una versione .webp del file esiste su disco, il server serve trasparentemente il file WebP al suo posto. L'header Vary: Accept garantisce che i proxy di caching memorizzino versioni separate per i browser compatibili con WebP e quelli non compatibili.

Assicurati che mod_rewrite, mod_mime e mod_headers siano abilitati sulla tua installazione Apache. La maggior parte degli ambienti di hosting condiviso li ha abilitati per impostazione predefinita, ma puoi verificare con il tuo provider di hosting.

Configurazione Nginx

Per i negozi che funzionano su Nginx, la configurazione va nel blocco server o in un blocco location all'interno del file di configurazione del tuo sito:

map $http_accept $webp_suffix {
  default "";
  "~*image/webp" ".webp";
}

server {
  # ... configurazione esistente ...

  location ~* ^(/img/.+)\.(jpe?g|png)$ {
    set $img_path $1;
    add_header Vary Accept;
    try_files $img_path$webp_suffix $uri =404;
  }
}

La direttiva map a livello http verifica se il client invia un header Accept compatibile con WebP e imposta una variabile di conseguenza. Il blocco location utilizza poi try_files per tentare prima di servire la versione WebP, con fallback al formato originale se il file WebP non esiste.

Dopo aver modificato la configurazione Nginx, testa sempre prima di ricaricare:

nginx -t
nginx -s reload

Considerazioni sulla CDN

Se utilizzi una CDN come Cloudflare, KeyCDN o Bunny.net davanti al tuo negozio PrestaShop, la distribuzione WebP richiede attenzione aggiuntiva.

Cloudflare

Cloudflare offre la conversione WebP integrata attraverso la funzionalità Polish (disponibile nei piani Pro e superiori). Quando Polish è abilitato con la conversione WebP, Cloudflare converte automaticamente le immagini in WebP sull'edge—il che significa che non hai bisogno di generare file WebP sul tuo server. Tuttavia, fai attenzione a queste avvertenze:

Polish funziona solo per le immagini servite attraverso il proxy di Cloudflare (nuvola arancione abilitata).
Non converte immagini più grandi di 10 MB o immagini con determinati profili colore.
La conversione iniziale aggiunge latenza alla prima richiesta; le richieste successive vengono servite dalla cache.
Se generi WebP anche localmente, potresti finire per fare una doppia conversione, il che può degradare leggermente la qualità.

Se preferisci servire i tuoi file WebP attraverso Cloudflare, assicurati che l'header Vary: Accept sia gestito correttamente. Per impostazione predefinita, Cloudflare rimuove l'header Vary. Potresti dover creare una Cache Rule o utilizzare un Worker per garantire una corretta negoziazione dei contenuti.

Altre CDN

La maggior parte delle CDN moderne supporta la negoziazione dei contenuti basata sull'header Accept, ma devi abilitarla esplicitamente. Consulta la documentazione della tua CDN per "supporto header Vary" o "negoziazione dei contenuti". Alcune CDN richiedono di abilitare "Cache by Accept header" nelle regole di caching. Senza questo, la CDN potrebbe memorizzare in cache la prima versione che riceve (JPEG o WebP) e servirla a tutti i visitatori indipendentemente dal supporto del browser.

Impostazioni di qualità delle immagini

Scegliere la giusta impostazione di qualità WebP è fondamentale. Troppo alta, e perdi i vantaggi in termini di dimensione del file; troppo bassa, e le immagini dei prodotti appaiono sfocate o mostrano artefatti di compressione—un problema inaccettabile per l'e-commerce.

Ecco le impostazioni di qualità consigliate per tipo di immagine:

Immagini prodotto (viste grandi/dettaglio): Qualità 82-88. Le foto dei prodotti devono apparire nitide, specialmente per articoli dove texture e dettaglio contano (moda, gioielleria, elettronica). A qualità 85, un'immagine prodotto tipica da 800x800 si comprime da ~120 KB (JPEG) a ~80 KB (WebP) senza alcuna perdita di qualità visibile.
Banner di categoria e immagini hero: Qualità 78-82. Queste sono generalmente visualizzate a dimensioni maggiori ma con meno attenzione ai dettagli fini.
Miniature e immagini di elenco: Qualità 75-80. A dimensioni di visualizzazione ridotte, una qualità inferiore è meno percepibile. Una miniatura a qualità 75 può essere il 50-60% più piccola del suo equivalente JPEG.
Loghi e grafiche con bordi netti: Usa WebP lossless o mantieni il formato PNG. La compressione lossy crea artefatti visibili intorno al testo e alle grafiche con bordi netti.

PrestaShop applica un'unica impostazione di qualità globalmente. Se hai bisogno di livelli di qualità diversi per diversi tipi di immagine, dovresti modificare la classe ImageManager o utilizzare un modulo di terze parti che fornisce un controllo più granulare.

Strategie di fallback

Sebbene il supporto dei browser per WebP sia quasi universale nel 2026, implementare una strategia di fallback è ancora considerata una best practice, specialmente se il tuo negozio serve clienti che utilizzano dispositivi più vecchi o ambienti aziendali con restrizioni.

Negoziazione dei contenuti lato server

Le regole .htaccess e Nginx descritte sopra implementano la negoziazione dei contenuti lato server. Questo è l'approccio raccomandato perché è trasparente per il livello applicativo. Il browser richiede l'URL originale e il server decide quale formato consegnare in base all'header Accept. Non sono necessarie modifiche ai template o al codice front-end.

L'elemento HTML Picture

Un approccio alternativo utilizza l'elemento <picture> per lasciare che il browser scelga il formato migliore:

<picture>
  <source srcset="immagine.webp" type="image/webp">
  <img src="immagine.jpg" alt="Nome prodotto">
</picture>

Questo richiede la modifica dei template PrestaShop (Smarty o Twig a seconda della tua versione). Sebbene ti dia un controllo esplicito, è più invasivo e più difficile da mantenere attraverso gli aggiornamenti del tema. La negoziazione lato server è generalmente preferita per i deployment PrestaShop.

Fallback integrato di PrestaShop

Quando selezioni l'opzione "JPEG/PNG + WebP" nelle impostazioni immagine di PrestaShop, il sistema genera entrambi i formati. PrestaShop 8.x gestisce il fallback automaticamente nei suoi template core, verificando se il file WebP esiste prima di referenziarlo. Se usi un tema personalizzato, verifica che i template delle immagini prodotto del tema supportino questo approccio a doppio formato.

Insidie comuni e come risolverle

1. Immagini non funzionanti dopo l'abilitazione di WebP

Il problema più comune dopo l'abilitazione di WebP sono le immagini non funzionanti in tutto il negozio. Questo di solito accade perché:

I file WebP non sono stati generati. Abilitare l'impostazione influisce solo sulle immagini caricate successivamente. Devi cliccare "Rigenera miniature" per creare le versioni WebP delle immagini esistenti. Per cataloghi di grandi dimensioni, usa il comando CLI.
I permessi dei file sono errati. L'utente del web server (generalmente www-data) deve avere i permessi di scrittura sulla struttura della directory img/. Dopo la rigenerazione, verifica i permessi: find img/ -name "*.webp" -exec ls -la {} \;
Le regole .htaccess sono in conflitto. L'.htaccess predefinito di PrestaShop contiene regole di rewrite che possono entrare in conflitto con le regole di rewrite WebP. Posiziona le regole WebP prima del blocco di rewrite predefinito di PrestaShop per assicurarti che vengano valutate per prime.

2. Estensioni GD o Imagick mancanti

La generazione WebP richiede che PHP abbia la libreria GD o l'estensione ImageMagick compilata con il supporto WebP. Per verificare:

php -r "echo gd_info()['WebP Support'] ? 'GD WebP OK' : 'GD WebP MANCANTE';"

Oppure per ImageMagick:

php -r "echo in_array('WEBP', Imagick::queryFormats()) ? 'Imagick WebP OK' : 'Imagick WebP MANCANTE';"

Se il supporto WebP è assente, devi ricompilare PHP con i flag appropriati o installare i pacchetti corretti. Su Debian/Ubuntu: apt-get install libwebp-dev seguito dalla ricompilazione dell'estensione GD, oppure installa una versione di PHP che include il supporto WebP (PHP 7.4+ lo include generalmente per impostazione predefinita).

Su hosting condiviso, se la tua build PHP non ha il supporto WebP, contatta il tuo provider di hosting. La maggior parte degli ambienti di hosting moderni include il supporto WebP nelle installazioni PHP 8.x.

3. Problemi di cache

I problemi legati alla cache sono tra le insidie WebP più frustranti:

Cache del browser: Dopo l'abilitazione di WebP, i browser potrebbero continuare a mostrare le versioni JPEG/PNG memorizzate in cache. Consiglia agli utenti di fare un hard-refresh (Ctrl+Shift+R), ma questo si risolve da solo quando le immagini in cache scadono.
Cache lato server: Se usi Varnish, Redis o qualsiasi full-page caching, la cache deve essere svuotata dopo l'abilitazione di WebP. Altrimenti, le pagine in cache faranno riferimento a vecchi URL di immagini o tipi MIME.
Cache CDN: Svuota completamente la cache della tua CDN dopo l'abilitazione di WebP. Presta particolare attenzione alle chiavi di cache della CDN—se la CDN non varia il caching per header Accept, potrebbe servire WebP a browser che non lo supportano (o viceversa).
OPcache: Se hai modificato file PHP come parte dell'abilitazione di WebP (ad esempio, override personalizzati di ImageManager), resetta OPcache per assicurarti che il nuovo codice abbia effetto.
Cache Smarty di PrestaShop: Svuota la cache Smarty dal back office (Parametri Avanzati > Prestazioni) o elimina il contenuto della directory var/cache/.

4. Tipi MIME errati

Se il tuo server non riconosce l'estensione .webp, i browser non riusciranno a renderizzare le immagini anche se i file sono validi. Assicurati che la configurazione del tuo server includa la mappatura corretta del tipo MIME: image/webp per i file .webp. La direttiva AddType nella sezione Apache qui sopra gestisce questo aspetto.

5. Problemi di caricamento immagini nel back office

Il back office di PrestaShop valida i formati delle immagini caricate. In alcune versioni, caricare un'immagine WebP direttamente attraverso l'editor prodotto potrebbe fallire con un errore di validazione. Questo perché la whitelist del validatore di upload potrebbe non includere WebP. Controlla le estensioni consentite in Parametri Avanzati > Amministrazione o nella configurazione pertinente.

6. Incompatibilità con moduli di terze parti

Alcuni moduli di terze parti (specialmente slider, moduli galleria e moduli zoom immagini prodotto) hanno le estensioni dei file immagine hardcoded o non supportano WebP. Dopo l'abilitazione di WebP, testa tutti i moduli che visualizzano immagini. I sintomi comuni includono miniature mancanti nei moduli slider o funzionalità zoom non funzionante. Contatta lo sviluppatore del modulo per aggiornamenti, o assicurati che la negoziazione dei contenuti lato server gestisca correttamente il fallback.

Testare la distribuzione WebP

Dopo la configurazione, verifica che le immagini WebP vengano effettivamente servite. Ecco diversi metodi:

Strumenti per sviluppatori del browser

Apri il tuo negozio in Chrome o Firefox.
Apri i DevTools (F12) e vai alla scheda Network.
Filtra per tipo Img.
Ricarica la pagina.
Clicca su qualsiasi richiesta di immagine e controlla gli Header di risposta. Il Content-Type dovrebbe essere image/webp.
Controlla anche la colonna Type nell'elenco della rete—dovrebbe mostrare "webp" per le immagini convertite.

Test da linea di comando

Usa curl per verificare che la negoziazione dei contenuti funzioni correttamente:

# Richiesta con supporto WebP
curl -s -I -H "Accept: image/webp,image/*" https://tuonegozio.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type
# Atteso: Content-Type: image/webp

# Richiesta senza supporto WebP
curl -s -I -H "Accept: image/jpeg" https://tuonegozio.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type
# Atteso: Content-Type: image/jpeg

Strumenti online

Google PageSpeed Insights e Lighthouse segnalano entrambi le immagini che non vengono servite in formati di nuova generazione. Esegui un audit Lighthouse sulle tue pagine prodotto—se WebP è configurato correttamente, non dovresti vedere la raccomandazione "Servi immagini in formati di nuova generazione".

Impatto sulle prestazioni

L'impatto prestazionale reale di WebP su un negozio PrestaShop dipende dalla dimensione del catalogo e dalla composizione della pagina, ma i miglioramenti tipici includono:

Riduzione del peso totale della pagina: 15-30% sulle pagine di elenco prodotti e 10-20% sulle pagine dettaglio prodotto, dove le immagini costituiscono la maggior parte dei byte scaricati.
Largest Contentful Paint (LCP): Miglioramento medio di 200-600ms, poiché l'immagine prodotto principale si carica più velocemente. Questa è una delle tre metriche Core Web Vitals e influenza direttamente il posizionamento nei motori di ricerca.
Time to Interactive (TTI): Miglioramento marginale, poiché il caricamento delle immagini compete con l'esecuzione del JavaScript per la larghezza di banda ma non per la CPU.
Risparmio di larghezza di banda del server: Per un negozio che serve 100.000 visualizzazioni di pagina al mese, WebP può ridurre l'utilizzo mensile della larghezza di banda di 20-50 GB, potenzialmente abbassando i costi di hosting.
Prestazioni mobile: I guadagni più significativi sono sulle connessioni mobile, dove le dimensioni ridotte delle immagini si traducono direttamente in tempi di caricamento più rapidi su reti 4G/5G. L'indicizzazione mobile-first di Google rende questo aspetto particolarmente importante.

Tieni presente che la generazione WebP aggiunge carico CPU durante l'elaborazione delle immagini (upload e rigenerazione). Su hosting condiviso con risorse limitate, la rigenerazione delle miniature per un catalogo di grandi dimensioni può temporaneamente rallentare il server. Pianifica la rigenerazione durante i periodi di basso traffico.

Checklist riepilogativa

Per distribuire con successo WebP sul tuo negozio PrestaShop, segui questa checklist:

Verifica che PHP abbia GD o ImageMagick con supporto WebP.
Abilita la generazione WebP nelle impostazioni immagine di PrestaShop (usa JPEG/PNG + WebP per sicurezza).
Imposta la qualità a 82-85 per un equilibrio ottimale.
Rigenera tutte le miniature (usa CLI per cataloghi di grandi dimensioni).
Aggiungi regole di negoziazione dei contenuti lato server (.htaccess o configurazione Nginx).
Configura la tua CDN per variare la cache per header Accept.
Svuota tutte le cache (browser, server, CDN, Smarty, OPcache).
Testa la distribuzione utilizzando i DevTools del browser e curl.
Verifica che i moduli di terze parti visualizzino le immagini correttamente.
Esegui un audit Lighthouse per confermare che non rimangano avvisi "formati di nuova generazione".

WebP non è più opzionale per l'e-commerce competitivo. Con il supporto integrato di PrestaShop e una configurazione del server semplice, non c'è motivo di continuare a servire file JPEG e PNG sovradimensionati. La configurazione richiede meno di un'ora e i benefici in termini di prestazioni sono immediati e misurabili.

Leggi la risposta completa

Cos'è il CSS Critico e Perché è Importante per PrestaShop?

Il CSS critico si riferisce al set minimo di regole CSS necessarie per il rendering del contenuto visibile nella parte superiore della pagina web (above the fold). Quando un browser carica il tuo negozio PrestaShop, deve scaricare, analizzare e applicare ogni file CSS prima di poter visualizzare qualsiasi contenuto sullo schermo. Ciò significa che una tipica installazione PrestaShop con un foglio di stile del tema, fogli di stile dei moduli e possibilmente un framework CSS può costringere i visitatori a fissare una pagina vuota per diversi secondi, mentre il browser elabora centinaia di kilobyte di CSS che potrebbero non essere nemmeno rilevanti per ciò che il visitatore vede inizialmente.

Il concetto alla base del CSS critico è semplice: estrarre solo gli stili necessari per la visualizzazione iniziale, incorporarli direttamente nel documento HTML e rinviare tutto il resto. Questo consente al browser di iniziare il rendering della pagina quasi immediatamente, migliorando drasticamente il tempo di caricamento percepito e diverse metriche chiave di performance.

Come il CSS che Blocca il Rendering Penalizza i Core Web Vitals

I Core Web Vitals di Google sono un insieme di metriche che influenzano direttamente il posizionamento nei motori di ricerca. Il CSS che blocca il rendering influisce negativamente su diverse metriche contemporaneamente.

Largest Contentful Paint (LCP) misura il momento in cui il più grande elemento visibile termina il rendering. Poiché il CSS blocca completamente il rendering, ogni millisecondo speso per scaricare e analizzare il CSS si aggiunge direttamente al punteggio LCP. Un negozio PrestaShop che carica 300KB di CSS prima di visualizzare qualsiasi contenuto supererà costantemente la soglia di 2,5 secondi per l'LCP, specialmente sulle connessioni mobili.

First Contentful Paint (FCP) registra il momento in cui il browser esegue il primo rendering di qualsiasi contenuto. Il CSS che blocca il rendering ritarda l'FCP perché il browser non può disegnare un singolo pixel finché tutti i fogli di stile bloccanti non sono stati elaborati. I negozi con numerosi moduli, ognuno dei quali inietta i propri file CSS, spesso registrano tempi FCP superiori a 3-4 secondi su connessioni 3G.

Cumulative Layout Shift (CLS) può essere influenzato indirettamente. Quando il CSS si carica in ritardo o in modo asincrono senza un adeguato CSS critico implementato, gli elementi potrebbero renderizzarsi senza stili e poi spostarsi di posizione una volta applicati gli stili. Questo crea instabilità visiva che frustra gli utenti e aumenta i punteggi CLS.

Interaction to Next Paint (INP) ne risente perché il thread principale è occupato nell'analisi di file CSS di grandi dimensioni anziché rispondere agli input dell'utente. Anche dopo il rendering iniziale, il browser deve ancora elaborare i fogli di stile differiti, e se questo accade durante l'interazione dell'utente, si crea un ritardo percepibile.

Identificare le Risorse che Bloccano il Rendering in PrestaShop

Prima di poter eliminare il CSS che blocca il rendering, è necessario identificare esattamente quali risorse stanno causando problemi. Diversi strumenti possono aiutare in questa analisi.

Google PageSpeed Insights fornisce un audit specifico chiamato "Elimina le risorse che bloccano il rendering" che elenca ogni file CSS e JavaScript che blocca il rendering iniziale. Analizza la homepage e le principali pagine di categoria/prodotto del tuo PrestaShop con questo strumento. Presta attenzione alla colonna dei risparmi stimati, che mostra quanti millisecondi potresti recuperare differendo ogni risorsa.

Chrome DevTools - Scheda Coverage è inestimabile per comprendere l'utilizzo del CSS. Apri DevTools, naviga nella scheda Coverage (Ctrl+Shift+P, quindi digita "coverage") e ricarica la pagina. Questo ti mostra esattamente quanto di ogni file CSS viene effettivamente utilizzato durante il rendering iniziale. In un tipico negozio PrestaShop, scoprirai che il 70-85% del CSS caricato su qualsiasi pagina non viene utilizzato per quella pagina specifica.

WebPageTest offre visualizzazioni filmstrip e waterfall che mostrano chiaramente quando i file CSS vengono richiesti, quando terminano il caricamento e quando avviene il primo rendering. Il divario tra l'arrivo dell'HTML e il primo rendering è in gran parte causato dal CSS che blocca il rendering.

Un tipico negozio PrestaShop 1.7 o 8.x carica le seguenti risorse CSS che bloccano il rendering: il foglio di stile del tema (spesso 200-400KB), un file del framework Bootstrap (150KB+), Font Awesome o font icona (50-100KB) e da 3 a 15 fogli di stile specifici dei moduli. Combinati, questi possono facilmente superare i 500KB di CSS che blocca il rendering.

Estrazione Manuale del CSS Critico

L'estrazione manuale comporta l'identificazione delle regole CSS necessarie per il contenuto above the fold e la loro separazione dal resto. Sebbene laboriosa, questa approccio offre il massimo controllo sul risultato.

Inizia identificando ciò che appare above the fold su ciascun tipo di pagina. Per un negozio PrestaShop, i modelli di pagina principali sono: homepage, elenco delle categorie, pagina prodotto, carrello e checkout. Ognuno ha un contenuto above the fold diverso. La homepage tipicamente mostra l'header, la navigazione e un banner o slider principale. Le pagine di categoria mostrano l'header, i breadcrumb e la prima riga di prodotti. Le pagine prodotto mostrano l'header, l'immagine del prodotto, il titolo e il prezzo.

Utilizza la scheda Coverage di Chrome DevTools per identificare quali regole CSS vengono applicate agli elementi above the fold. Puoi anche utilizzare il pannello "Computed" nella scheda Elements per vedere esattamente quali regole influenzano ogni elemento visibile.

Estrai queste regole in un file separato o in un blocco inline. Un tipico payload di CSS critico per una pagina PrestaShop dovrebbe essere compreso tra 10KB e 30KB (prima della compressione gzip). Se il tuo CSS critico supera i 50KB, probabilmente stai includendo troppe regole. Concentrati rigorosamente su layout (grid, flexbox), tipografia (font-family, font-size, line-height per il testo visibile), colori e sfondi degli elementi visibili, la struttura dell'header e della navigazione e il layout dell'area di contenuto principale.

L'approccio manuale è più adatto per negozi con un design fisso che cambia raramente. Se aggiorni frequentemente il tema o aggiungi moduli, il carico di manutenzione del CSS critico manuale diventa insostenibile.

Strumenti Automatizzati per il CSS Critico

Gli strumenti automatizzati generano CSS critico renderizzando la pagina in un browser headless ed estraendo solo gli stili applicati agli elementi all'interno del viewport. Due strumenti dominano questo settore.

Critters (di Google Chrome Labs)

Critters è un plugin Webpack che incorpora il CSS critico inline al momento della build. A differenza di altri strumenti, Critters non utilizza un browser headless. Invece, analizza staticamente HTML e CSS, identificando quali selettori corrispondono agli elementi presenti nel documento HTML. Questo lo rende più veloce e prevedibile rispetto agli approcci basati su browser.

Per l'integrazione con PrestaShop, Critters funziona bene quando incorporato in una pipeline di build personalizzata. Elabora l'output HTML renderizzato e incorpora gli stili critici inline, convertendo i restanti link ai fogli di stile per il caricamento asincrono. Il vantaggio principale di Critters è la velocità e l'affidabilità durante i processi di build. Poiché non necessita di un'istanza del browser in esecuzione, può elaborare le pagine rapidamente e in modo coerente.

Le considerazioni di configurazione per Critters in PrestaShop includono l'impostazione della larghezza del viewport appropriata (tipicamente 1350px per desktop, 375px per mobile), l'esclusione di certi selettori generati dinamicamente (come le classi specifiche dei moduli aggiunte tramite JavaScript) e la gestione corretta delle dichiarazioni font-face per evitare il flash of invisible text (FOIT).

Critical (di Addy Osmani)

Il pacchetto npm Critical utilizza un browser headless (Puppeteer) per renderizzare le pagine ed estrarre il CSS above the fold. Produce risultati più accurati dell'analisi statica perché vede la pagina esattamente come la vedrebbe un browser reale, inclusi i contenuti renderizzati con JavaScript e gli stili applicati dinamicamente.

Per utilizzare Critical con PrestaShop, dovresti creare un passaggio di build che recupera ogni tipo di pagina dal tuo negozio live o di staging, estrae il CSS critico e lo inietta nei template del tema. Questo approccio richiede un'attenta gestione dell'autenticazione per le pagine protette (checkout, pagine account) e la considerazione di diversi viewport per il CSS critico responsive.

Critical può essere eseguito come passaggio post-distribuzione. Dopo aver distribuito un aggiornamento del tema, rigeneri il CSS critico per ogni tipo di pagina e aggiorni gli stili inline di conseguenza. Questo assicura che il CSS critico rimanga sincronizzato con gli stili effettivi del tema.

Impostazioni CCC di PrestaShop: Combina, Comprimi, Cache

PrestaShop include un'ottimizzazione CSS integrata attraverso la funzionalità CCC (Combina, Comprimi, Cache), accessibile nel Back Office sotto Parametri Avanzati > Prestazioni. Comprendere queste impostazioni è essenziale prima di implementare il CSS critico, poiché interagiscono con la tua strategia di ottimizzazione.

Combina file CSS unisce tutti i file CSS in un unico file combinato. Questo riduce il numero di richieste HTTP, cosa cruciale negli ambienti HTTP/1.1. Con HTTP/2 e HTTP/3, il vantaggio della combinazione è ridotto perché più file possono essere scaricati in parallelo. Tuttavia, la combinazione aiuta ancora con il blocco del rendering perché il browser deve attendere un solo file invece di potenzialmente dozzine.

Comprimi CSS (minificazione) rimuove spazi bianchi, commenti e caratteri non necessari dai file CSS. Questo riduce tipicamente la dimensione dei file CSS del 15-25%. Abilita sempre questa opzione in produzione.

Cache CSS aggiunge un hash univoco ai nomi dei file CSS combinati, abilitando una cache aggressiva del browser garantendo al contempo che i visitatori ottengano gli stili aggiornati dopo le modifiche. Questo funziona sia con il sistema integrato di PrestaShop che con le configurazioni CDN.

Quando implementi il CSS critico insieme al CCC, la configurazione raccomandata è abilitare tutte e tre le opzioni CCC. Il file CSS combinato e minificato diventa il foglio di stile differito (non critico), mentre il CSS critico viene incorporato inline nell'head HTML. Questo ti offre il meglio di entrambi i mondi: rendering immediato dal CSS critico inline e cache efficiente del foglio di stile completo per i caricamenti successivi delle pagine.

Un'avvertenza importante: dopo aver abilitato o modificato le impostazioni CCC, devi svuotare la cache di PrestaShop. Naviga in Parametri Avanzati > Prestazioni e clicca "Svuota la cache" o elimina il contenuto delle directory /var/cache/prod/ e /var/cache/dev/. Anche i template compilati di Smarty in /var/cache/smarty/compile/ dovrebbero essere svuotati.

Implementare il CSS Critico Inline in PrestaShop

L'implementazione effettiva del CSS critico in PrestaShop comporta la modifica del template head del tema per incorporare gli stili critici inline e differire il CSS rimanente.

Nel file _partials/head.tpl del tuo tema (o l'equivalente nel tuo tema), devi aggiungere il CSS critico inline all'interno di un tag style nell'head del documento. Questo sostituisce il normale link al foglio di stile per gli stili above the fold. Il CSS critico dovrebbe essere posizionato immediatamente dopo i meta tag e prima di qualsiasi altra risorsa.

Un approccio pratico è creare un template Smarty che includa il CSS critico inline. Crea un file nel tuo tema in _partials/critical-css.tpl che contenga gli stili critici racchiusi in un elemento style. Poi includi questo parziale nel template head. Questo mantiene il CSS critico gestibile e separato dalla logica del template principale.

Per diversi tipi di pagina, puoi caricare condizionalmente CSS critici diversi. PrestaShop fornisce la variabile $page.page_name in Smarty che indica quale tipo di pagina viene renderizzata. Usala per caricare CSS critici specifici per pagina: un set per la homepage, un altro per le pagine di categoria, un altro per le pagine prodotto e un fallback generico per tutte le altre pagine.

Caricamento Asincrono del CSS Rimanente

Una volta che il CSS critico è incorporato inline, il CSS rimanente deve caricarsi senza bloccare il rendering. Esistono diverse tecniche per questo.

La tecnica dello swap dell'attributo media è l'approccio più ampiamente supportato. Cambia l'attributo media del link al foglio di stile in "print" e aggiungi un handler onload che lo cambia in "all" una volta caricato. Questo indica al browser che il foglio di stile è solo per la stampa, quindi lo scarica con priorità bassa e non blocca il rendering. Una volta caricato, l'handler onload cambia il tipo di media in "all", applicando gli stili allo schermo. Includi un fallback noscript con il link originale per gli utenti senza JavaScript.

L'approccio rel="preload" utilizza il precaricamento dei link per recuperare il foglio di stile con alta priorità ma senza bloccare il rendering. Aggiungi rel="preload" e as="style" all'elemento link, insieme a un handler onload che cambia il rel in "stylesheet". Questo approccio fornisce una migliore priorità di caricamento rispetto alla tecnica di swap del media, ma ha un supporto browser leggermente inferiore nei browser più vecchi.

La libreria loadCSS di Filament Group fornisce una soluzione JavaScript robusta per il caricamento asincrono del CSS con ampio supporto browser. Gestisce casi limite e fallback che le implementazioni manuali potrebbero trascurare. Per i negozi PrestaShop che devono supportare browser più vecchi, questa è la scelta più sicura.

Qualunque tecnica tu scelga, includi sempre un fallback <noscript> contenente il normale link al foglio di stile. Questo assicura che il sito rimanga funzionale per la piccola percentuale di visitatori con JavaScript disabilitato.

Problemi CSS Specifici dei Moduli in PrestaShop

I moduli PrestaShop sono una delle maggiori fonti di CSS che blocca il rendering e presentano sfide uniche per l'ottimizzazione del CSS critico.

Pattern di iniezione CSS dei moduli: La maggior parte dei moduli PrestaShop registra il proprio CSS attraverso l'hookDisplayHeader o tramite il metodo setMedia() del modulo, che chiama $this->context->controller->addCSS(). Questi fogli di stile vengono aggiunti all'head della pagina e bloccano il rendering per impostazione predefinita. Quando CCC è abilitato, PrestaShop combina questi fogli di stile dei moduli con il CSS del tema, il che significa che non possono essere differiti individualmente.

CSS dei moduli non necessario su pagine irrilevanti: Un problema comune è che i moduli caricano il loro CSS su ogni pagina anche quando la funzionalità del modulo viene utilizzata solo su pagine specifiche. Un modulo di pagamento che carica il proprio CSS sulla homepage, o un modulo di confronto prodotti che carica il CSS sulla pagina di checkout, spreca banda e aumenta il tempo di blocco del rendering. Verifica i tuoi moduli e assicurati che ciascuno carichi il CSS solo sulle pagine dove è effettivamente necessario. Molti moduli offrono un'opzione di configurazione per questo. Per quelli che non la offrono, puoi sovrascrivere l'hook header del modulo per aggiungere condizioni sul tipo di pagina.

Qualità del CSS dei moduli di terze parti: I moduli di terze parti spesso includono CSS scarsamente ottimizzato. Potresti trovare moduli che includono file CSS da 50KB+ quando ne necessitano solo 5KB. Alcuni includono interi framework CSS all'interno del modulo. Altri includono CSS di sviluppo non minificato. Identifica questi moduli usando la scheda Coverage di Chrome DevTools e considera la creazione di versioni ottimizzate dei loro fogli di stile nella directory di override dei moduli del tema in /themes/tuo-tema/modules/nome-modulo/views/css/.

Ordine di caricamento del CSS dei moduli: PrestaShop carica il CSS dei moduli nell'ordine in cui i moduli sono registrati per gli hook. Se il CSS di un modulo critico viene caricato per ultimo nel file combinato, il browser deve analizzare tutto il CSS precedente prima di raggiungere gli stili essenziali. Puoi influenzare l'ordine di caricamento attraverso la pagina delle posizioni dei moduli nel Back Office (Design > Posizioni), spostando i moduli essenziali più in alto nell'hook displayHeader.

Misurare il Miglioramento: Prima e Dopo

Misurare l'impatto dell'implementazione del CSS critico richiede una metodologia di test coerente e le metriche giuste.

Strumenti per la misurazione: Usa Google PageSpeed Insights per dati di laboratorio e sul campo, WebPageTest per un'analisi dettagliata del waterfall e Chrome DevTools Lighthouse per audit locali rapidi. Esegui test da più posizioni e velocità di connessione. Le prestazioni mobile su connessioni 3G tipicamente mostrano il miglioramento più drammatico dal CSS critico perché il ritardo del blocco del rendering è proporzionale alla velocità di connessione.

Metriche chiave da monitorare: Il First Contentful Paint è la metrica più direttamente migliorata dal CSS critico, poiché misura il primo evento di rendering. Anche l'LCP dovrebbe migliorare perché il browser può iniziare il rendering e il caricamento delle immagini visibili prima. Il Time to Interactive potrebbe migliorare leggermente perché il thread principale impiega meno tempo nell'analisi iniziale del CSS.

Metodologia di test: Esegui sempre almeno 5 test prima e 5 test dopo l'implementazione, poi confronta le mediane anziché le singole esecuzioni. Le condizioni di rete, il carico del server e la cache CDN possono causare variazioni significative tra le singole esecuzioni dei test. Strumenti come WebPageTest permettono di specificare il numero di esecuzioni e calcolano automaticamente le mediane.

Numeri di Performance nel Mondo Reale

Basandosi su ottimizzazioni reali di negozi PrestaShop, ecco i miglioramenti di performance che puoi tipicamente aspettarti implementando correttamente il CSS critico.

First Contentful Paint: Miglioramento tipico da 1,2 a 2,5 secondi su connessioni mobile 3G. Un negozio che precedentemente aveva un FCP di 4,2 secondi può realisticamente raggiungere 1,8-2,0 secondi con un CSS critico implementato correttamente. Su connessioni desktop a banda larga, il miglioramento è tipicamente di 0,3-0,8 secondi.

Largest Contentful Paint: Un miglioramento di 0,8-2,0 secondi è comune. L'LCP beneficia perché il browser può iniziare a caricare immagini e altri elementi di grandi dimensioni prima, quando il CSS non blocca più il rendering. Un negozio PrestaShop con LCP di 5,1 secondi su mobile può spesso portare questo sotto i 3,0 secondi con il CSS critico combinato con l'ottimizzazione delle immagini.

Punteggio PageSpeed: I punteggi PageSpeed mobile tipicamente aumentano di 15-30 punti dopo l'eliminazione del CSS che blocca il rendering. Un negozio con un punteggio di 35-45 su mobile può realisticamente raggiungere 60-75 con il solo CSS critico. Combinato con altre ottimizzazioni (compressione immagini, differimento JavaScript, caching lato server), punteggi superiori a 85 sono raggiungibili.

Total Blocking Time: Una riduzione di 200-500 millisecondi è tipica, poiché il thread principale impiega meno tempo nell'analisi del CSS durante la fase critica di caricamento.

Questi numeri presuppongono un'installazione PrestaShop ben configurata con un tema moderno, tempi di risposta del server ragionevoli (sotto 500ms TTFB) e una corretta configurazione CDN. I negozi con hosting estremamente lento, un numero eccessivo di moduli o temi pesantemente personalizzati potrebbero vedere risultati diversi.

Checklist di Implementazione

Per riassumere il processo completo per implementare il CSS critico nel tuo negozio PrestaShop, segui questi passaggi nell'ordine indicato. Primo, verifica il panorama CSS attuale usando Chrome DevTools Coverage per capire quanto CSS viene caricato e quanto è effettivamente utilizzato above the fold. Secondo, abilita le impostazioni CCC di PrestaShop (Combina, Comprimi, Cache) come ottimizzazione di base. Terzo, scegli il metodo di generazione del CSS critico: estrazione manuale per temi semplici e stabili, oppure strumenti automatizzati come Critters o Critical per negozi complessi o frequentemente aggiornati. Quarto, genera il CSS critico per ogni tipo di pagina principale: homepage, categoria, prodotto, carrello e checkout. Quinto, implementa il CSS critico inline nel template head del tema con caricamento condizionale per tipo di pagina. Sesto, configura il caricamento asincrono per il file CSS combinato rimanente usando la tecnica di swap del media o preload. Settimo, verifica il CSS dei moduli per eliminare il caricamento di fogli di stile non necessari su pagine irrilevanti. Ottavo, misura i risultati usando PageSpeed Insights, WebPageTest e Lighthouse, confrontando le metriche prima e dopo. Nono, imposta un processo per rigenerare il CSS critico dopo aggiornamenti del tema o modifiche significative ai moduli. Infine, monitora i Core Web Vitals in Google Search Console per verificare i miglioramenti nel mondo reale per i visitatori effettivi nel tempo.

L'ottimizzazione del CSS critico è uno dei miglioramenti di performance con il maggiore impatto che puoi apportare a un negozio PrestaShop. Sebbene l'implementazione iniziale richieda impegno, il miglioramento risultante nei Core Web Vitals, nell'esperienza utente e nel posizionamento nei motori di ricerca rende l'investimento assolutamente vantaggioso.

Leggi la risposta completa

Perché Dovresti Cambiare l'URL Admin Predefinito

Ogni installazione di PrestaShop crea una directory admin con un nome come admin1234 — le cifre vengono generate in modo casuale durante l'installazione. Questa directory è il punto di accesso al back office del tuo negozio. Sebbene il suffisso casuale fornisca una certa oscurità di base, non è una misura di sicurezza robusta. Bot automatizzati e malintenzionati scansionano regolarmente i pattern degli URL admin più comuni su migliaia di siti web. Cambiare il tuo URL admin con qualcosa di imprevedibile aggiunge un livello significativo di difesa.

La ragione principale per cambiare il nome della cartella admin è ridurre l'esposizione agli attacchi brute-force. Se un attaccante non riesce a trovare la tua pagina di login, non può tentare di indovinare la tua password. Questo non sostituisce le password robuste e le altre misure di sicurezza, ma è un primo passo efficace che non costa nulla e richiede solo pochi minuti per essere implementato.

Inoltre, un URL admin personalizzato rende il tuo negozio più professionale se dipendenti o clienti devono accedere al back office. Un URL come tuodominio.com/gestione-negozio/ è più facile da ricordare e comunicare rispetto a tuodominio.com/admin7382pqxz/.

Come Funzionano gli URL Admin di PrestaShop

La directory admin di PrestaShop è una cartella fisica sul tuo server. Quando digiti tuodominio.com/admin1234/ nel tuo browser, il server web cerca la directory admin1234 e serve il file index.php al suo interno. Questo significa che cambiare l'URL admin è principalmente una questione di rinominare la directory nel filesystem del server.

All'interno della directory admin, PrestaShop memorizza file controller, file template e configurazioni che fanno riferimento al percorso admin. In PrestaShop 1.7 e 8.x, la directory admin contiene anche i componenti di routing Symfony. La configurazione interna memorizza il nome della directory admin nel file app/config/parameters.php (o config/parameters.php nelle versioni precedenti) sotto la chiave ps_admin_dir. Questo valore deve corrispondere al nome effettivo della directory affinché il back office funzioni correttamente.

Passo dopo Passo: Rinominare la Directory Admin

Metodo 1: Via FTP o File Manager

Questo è il metodo più sicuro e diretto. Funziona su tutti i tipi di hosting e su tutte le versioni di PrestaShop dalla 1.6 fino alla 8.x e 9.x.

Connettiti al tuo server via FTP (FileZilla, WinSCP) oppure usa il file manager del pannello di controllo del tuo hosting (cPanel, Plesk).
Naviga nella directory principale di PrestaShop — è dove vedi cartelle come classes/, modules/, themes/ e la tua attuale cartella admin.
Identifica la tua attuale cartella admin. Avrà un nome come admin1234 o admin-dev (sulle installazioni di sviluppo). Non confonderla con la cartella admin-dev/ se hai la versione con codice sorgente installata.
Rinomina la cartella con il nome desiderato. Fai clic destro sulla cartella nel tuo client FTP e seleziona "Rinomina". Scegli un nome difficile da indovinare ma facile da ricordare. Buoni esempi: manage-xyz, backoffice-abc, control-2024. Evita nomi ovvi come admin, administrator, backend, dashboard o manage.
Aggiorna il file di configurazione. Apri app/config/parameters.php in un editor di testo e trova la riga contenente ps_admin_dir. Cambia il valore in modo che corrisponda esattamente al nuovo nome della directory.
Svuota la cache. Elimina il contenuto di var/cache/prod/ e var/cache/dev/ (se esiste). La vecchia cache contiene riferimenti al nome della directory admin precedente.
Testa il nuovo URL. Apri il browser e naviga su tuodominio.com/nuovo-nome-admin/. Dovresti vedere la pagina di login di PrestaShop.

Metodo 2: Via SSH (Riga di Comando)

Se hai accesso SSH al tuo server, puoi rinominare la directory con un singolo comando:

cd /var/www/html/prestashop
mv admin1234 nuovo-nome

Poi aggiorna la configurazione:

sed -i "s/admin1234/nuovo-nome/g" app/config/parameters.php

E svuota la cache:

rm -rf var/cache/prod/* var/cache/dev/*

Questo metodo è più veloce e meno soggetto a errori rispetto all'uso di FTP, specialmente se il nome della directory appare in più punti nel file di configurazione.

Differenze tra le Versioni di PrestaShop

PrestaShop 1.6

In PrestaShop 1.6, il nome della directory admin è memorizzato in config/settings.inc.php anziché in app/config/parameters.php. Cerca una riga come:

define('_PS_ADMIN_DIR_', '/var/www/html/prestashop/admin1234');

Cambia il percorso in modo che corrisponda al nuovo nome della directory. La struttura della directory app/ non esiste nella 1.6 perché precede l'integrazione con Symfony. Per il resto, il processo di rinominazione della directory è identico.

PrestaShop 1.7

PrestaShop 1.7 ha introdotto il framework Symfony, aggiungendo il file app/config/parameters.php. Tuttavia, la 1.7 mantiene ancora la compatibilità con il routing admin legacy. Dopo la rinominazione, svuota sia la cache Smarty (var/cache/) sia la cache Symfony. Il nome della directory admin è memorizzato in parameters.php all'interno dell'array parameters:

'parameters' => array(
    // ...
    'ps_admin_dir' => 'nuovo-nome',
    // ...
)

PrestaShop 8.x

PrestaShop 8.x continua l'architettura della 1.7 con un'integrazione Symfony più profonda. Il processo è lo stesso della 1.7, ma il file parameters.php potrebbe utilizzare la configurazione basata su YAML di Symfony in alcune configurazioni. Controlla sia app/config/parameters.php che app/config/parameters.yml se presente. Dopo la rinominazione, svuota sempre la cache completamente.

PrestaShop 9.x

PrestaShop 9.x perfeziona ulteriormente l'integrazione con Symfony. Il concetto di directory admin rimane, ma il routing è maggiormente basato su Symfony. Il file parameters.php o parameters.yml contiene ancora il riferimento alla directory admin. Il processo di rinominazione non cambia, ma presta particolare attenzione allo svuotamento di tutti i livelli di cache, poiché la cache di routing Symfony è più aggressiva nella 9.x.

Aggiornamento di .htaccess Dopo la Rinominazione

Nella maggior parte dei casi, non è necessario modificare il file .htaccess nella directory principale di PrestaShop dopo aver rinominato la cartella admin. Le regole .htaccess di PrestaShop tipicamente non fanno riferimento alla directory admin per nome. Le regole di riscrittura gestiscono il front office (URL rivolte ai clienti) e la directory admin è accessibile direttamente senza riscrittura.

Tuttavia, ci sono eccezioni. Se hai aggiunto regole di sicurezza personalizzate al .htaccess che fanno riferimento al vecchio nome della directory admin, devi aggiornare quelle regole. Ad esempio, se hai precedentemente aggiunto il whitelisting degli IP per l'area admin:

# Vecchia regola
<Directory /var/www/html/prestashop/admin1234>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.50
</Directory>

Questa deve essere aggiornata per fare riferimento al nuovo nome della directory. Allo stesso modo, controlla eventuali plugin di sicurezza (come le regole mod_security) o configurazioni CDN (regole di pagina Cloudflare) che potrebbero fare riferimento al vecchio percorso admin.

Controlla anche il file .htaccess all'interno della directory admin stessa. PrestaShop ne posiziona uno per il routing interno. Questo file generalmente non necessita di modifiche perché utilizza percorsi relativi, ma verificalo dopo la rinominazione per assicurarti che nulla sia compromesso.

Errori Comuni e Cosa NON Fare

Non Usare Symlink come Scorciatoia

Alcuni amministratori creano un link simbolico da un nuovo nome alla vecchia directory admin invece di rinominarla effettivamente. Questo vanifica completamente lo scopo perché la vecchia directory esiste ancora ed è accessibile. Esegui sempre una rinominazione effettiva, non un symlink.

Non Dimenticare di Aggiornare parameters.php

L'errore più comune in assoluto è rinominare la directory ma dimenticare di aggiornare il file di configurazione. Quando questo accade, vedrai una pagina bianca o un errore 500 quando tenti di accedere al pannello admin. PrestaShop internamente fa riferimento al nome della directory admin dalla configurazione, e una discrepanza causa un fallimento immediato.

Non Scegliere Nomi Ovvi

Rinominare la directory admin da admin1234 a admin o administrator è controproducente. Gli scanner automatizzati controllano prima questi nomi ovvi. Scegli qualcosa che combini parole e numeri in un modo non facilmente indovinabile: store-mgmt-7x9, bo-access-42 o anche una stringa completamente casuale come kx9m4p2q.

Non Rinominare Mentre gli Utenti Sono Connessi

Le sessioni del back office attive si interromperanno immediatamente quando rinomini la directory. Qualsiasi utente admin attualmente connesso vedrà un errore e perderà il lavoro non salvato. Effettua la rinominazione durante un periodo di basso traffico e avvisa qualsiasi membro dello staff che utilizza il back office.

Non Dimenticare Segnalibri e Link Salvati

Dopo la rinominazione, aggiorna tutti i segnalibri, le password salvate nel browser, le voci del gestore di password e la documentazione che fanno riferimento al vecchio URL admin. Avvisa tutti i membri dello staff che accedono al back office riguardo al nuovo URL.

Non Usare Caratteri Speciali o Spazi

Il nome della directory admin deve essere un componente di percorso URL valido. Usa solo lettere minuscole, numeri e trattini. Evita spazi, underscore (anche se funzionano, i trattini sono più puliti), caratteri accentati e qualsiasi carattere speciale.

Conflitti dei Moduli e Considerazioni su Terze Parti

La maggior parte dei moduli PrestaShop ben scritti utilizza le funzioni interne di PrestaShop per determinare il percorso della directory admin piuttosto che codificarlo direttamente. Questi moduli continueranno a funzionare dopo la rinominazione senza alcun intervento. Tuttavia, alcuni moduli scritti in modo inadeguato potrebbero codificare direttamente il percorso admin nei loro file di configurazione, JavaScript o endpoint AJAX.

Dopo aver rinominato la directory admin, testa quanto segue nel back office:

Tutti i moduli installati — apri la pagina di configurazione di ciascun modulo
Qualsiasi modulo che usa chiamate AJAX (controlla la console del browser per errori 404)
Callback e webhook dei moduli di pagamento
Qualsiasi integrazione personalizzata o connessione ERP che fa riferimento all'URL admin
Cron job che chiamano script lato admin

Se un modulo smette di funzionare dopo la rinominazione, controlla i suoi file di configurazione per percorsi admin codificati direttamente. Molti moduli memorizzano le impostazioni nella tabella del database ps_configuration, e alcuni di questi valori potrebbero contenere il vecchio nome della directory admin.

Per cercare nel database i riferimenti alla vecchia directory admin:

SELECT * FROM ps_configuration WHERE value LIKE '%admin1234%';

Sostituisci admin1234 con il tuo vecchio nome della directory e ps_ con il prefisso effettivo del database.

Misure di Sicurezza Aggiuntive per l'Area Admin

Rinominare la directory admin è un buon primo passo, ma dovrebbe far parte di una strategia di sicurezza completa. Considera queste misure aggiuntive:

Whitelisting degli Indirizzi IP

Se tu e il tuo team accedete sempre al back office da indirizzi IP fissi, puoi limitare l'accesso a livello di server web. Per Apache, aggiungi al .htaccess della tua directory admin:

Order Deny,Allow
Deny from all
Allow from 203.0.113.50
Allow from 198.51.100.25

Per Nginx, aggiungi al tuo blocco server:

location /nome-admin/ {
    allow 203.0.113.50;
    allow 198.51.100.25;
    deny all;
}

Questo è estremamente efficace perché anche se un attaccante scopre il tuo URL admin, non può accedere alla pagina di login da un indirizzo IP non autorizzato.

Autenticazione a Due Fattori (2FA)

PrestaShop 8.x non include il 2FA integrato, ma diversi moduli forniscono questa funzionalità. L'autenticazione a due fattori richiede un secondo passaggio di verifica (tipicamente un codice da un'app mobile come Google Authenticator) oltre alla password. Questo rende gli attacchi brute-force essenzialmente impossibili anche se l'attaccante conosce sia l'URL admin che la password.

Certificato SSL/TLS

Accedi sempre al tuo pannello admin tramite HTTPS. Questo cripta le credenziali di login durante il transito, prevenendo gli attacchi man-in-the-middle. La maggior parte dei provider di hosting offre certificati SSL gratuiti tramite Let's Encrypt. Il back office di PrestaShop dovrebbe essere configurato per forzare SSL in Parametri del Negozio > Generali > Abilita SSL e Abilita SSL su tutte le pagine.

Limitazione dei Tentativi di Login

PrestaShop include una protezione brute-force di base che blocca gli indirizzi IP dopo un certo numero di tentativi di login falliti. Assicurati che sia abilitata nelle impostazioni di sicurezza. Puoi anche implementare il rate limiting a livello di server web usando moduli come mod_evasive per Apache o limit_req per Nginx.

Rotazione Regolare delle Password

Assicurati che tutti gli account admin utilizzino password robuste e uniche. Una buona password è di almeno 16 caratteri e include un mix di lettere, numeri e simboli. Usa un gestore di password per generare e memorizzare queste password. Ruota le password periodicamente, specialmente quando un dipendente lascia l'azienda o si verifica un incidente di sicurezza.

Audit degli Account Admin

Rivedi regolarmente l'elenco degli account admin in Parametri Avanzati > Team > Dipendenti. Rimuovi o disabilita gli account dei dipendenti che non necessitano più dell'accesso. Ogni persona dovrebbe avere il proprio account anziché condividere le credenziali, il che rende possibile tracciare chi ha effettuato quali modifiche.

Cosa Fare Se Perdi l'Accesso

Se rinomini la directory admin e non riesci ad accedere al back office, non farti prendere dal panico. Connettiti al server via FTP o SSH e rinomina la directory con il suo nome originale oppure controlla il file parameters.php per assicurarti che il nome della directory corrisponda. Se hai perso traccia sia del nome della directory che della configurazione, guarda l'elenco delle directory sul server — la directory admin è quella che contiene file come ajax-tab.php, init.php e una sottodirectory themes/ con il tema del back office.

Puoi anche trovare il nome della directory admin nel database:

SELECT value FROM ps_configuration WHERE name = 'PS_ADMIN_DIR';

Tuttavia, nota che non tutte le versioni di PrestaShop memorizzano questo valore nella tabella di configurazione. Il file parameters.php è la fonte autorevole.

Automatizzare i Cambiamenti dell'URL Admin con uno Script

Se gestisci più installazioni di PrestaShop, puoi creare un semplice script shell per automatizzare il processo di rinominazione:

#!/bin/bash
OLD_NAME="$1"
NEW_NAME="$2"
PS_ROOT="/var/www/html/prestashop"

if [ -z "$OLD_NAME" ] || [ -z "$NEW_NAME" ]; then
    echo "Uso: $0 vecchio-nome-admin nuovo-nome-admin"
    exit 1
fi

mv "$PS_ROOT/$OLD_NAME" "$PS_ROOT/$NEW_NAME"
sed -i "s/$OLD_NAME/$NEW_NAME/g" "$PS_ROOT/app/config/parameters.php"
rm -rf "$PS_ROOT/var/cache/prod/*" "$PS_ROOT/var/cache/dev/*"
echo "Directory admin rinominata da $OLD_NAME a $NEW_NAME"
echo "Verifica l'accesso su: tuodominio.com/$NEW_NAME/"

Salva questo come rename-admin.sh, rendilo eseguibile con chmod +x rename-admin.sh e avvialo con i vecchi e nuovi nomi della directory come argomenti. Testa sempre il nuovo URL immediatamente dopo aver eseguito lo strumento.

Seguendo questi passaggi e combinando il cambio dell'URL admin con misure di sicurezza aggiuntive, riduci significativamente la superficie di attacco del back office del tuo negozio PrestaShop.

Leggi la risposta completa

La transizione del motore di template in PrestaShop

PrestaShop sta attraversando uno dei cambiamenti architetturali più significativi della sua storia recente — la migrazione da Smarty a Twig come motore di template principale. Questa transizione, iniziata con PrestaShop 1.7 e che ha raggiunto una pietra miliare importante con PrestaShop 9.0 (rilasciato a giugno 2025), riguarda ogni sviluppatore, designer di temi e creatore di moduli che lavora con la piattaforma.

Comprendere questo cambiamento è essenziale che tu stia mantenendo un negozio esistente, pianificando un aggiornamento o sviluppando nuovi moduli e temi. Questa guida copre cosa è cambiato, cosa sta ancora cambiando e come preparare i tuoi progetti PrestaShop per l'era Twig.

Cosa sono Smarty e Twig?

Smarty - Il motore legacy

Smarty è un motore di template PHP che alimenta PrestaShop dai suoi inizi. Separa la logica di business PHP dalla presentazione HTML.

Caratteristiche principali di Smarty -

I file template usano l'estensione .tpl
Le variabili sono accessibili con parentesi graffe e segni di dollaro - {$variable}
I modificatori usano la sintassi pipe - {$variable|escape:'html'}
I blocchi usano tag accoppiati - {block name='content'}{/block}
Ereditarietà del template tramite {extends file='parent.tpl'}

Twig - Il motore moderno

Twig è il motore di template costruito da SensioLabs, la stessa azienda dietro il framework Symfony. Poiché PrestaShop ha progressivamente adottato i componenti Symfony, passare a Twig è un allineamento naturale.

Caratteristiche principali di Twig -

I file template usano l'estensione .html.twig
Le variabili usano doppie parentesi graffe - {{ variable }}
I filtri usano la sintassi pipe - {{ variable|escape('html') }}
I blocchi usano tag accoppiati - {% block content %}{% endblock %}
Ereditarietà del template tramite {% extends 'parent.html.twig' %}

Confronto della sintassi - Fianco a fianco

Output delle variabili

Funzionalità	Smarty	Twig
Variabile semplice	`{$product.name}`	`{{ product.name }}`
Accesso array	`{$products[0].name}`	`{{ products[0].name }}`
Metodo oggetto	`{$product->getName()}`	`{{ product.getName() }}`
Valore predefinito	`{$var\|default:'N/A'}`	`{{ var\|default('N/A') }}`

Strutture di controllo

<!-- Smarty: if/else -->
{if $product.active}
  <span class="badge badge-success">Attivo</span>
{elseif $product.pending}
  <span class="badge badge-warning">In attesa</span>
{else}
  <span class="badge badge-danger">Inattivo</span>
{/if}

<!-- Twig: if/else -->
{% if product.active %}
  <span class="badge badge-success">Attivo</span>
{% elseif product.pending %}
  <span class="badge badge-warning">In attesa</span>
{% else %}
  <span class="badge badge-danger">Inattivo</span>
{% endif %}

Cicli

<!-- Smarty: ciclo foreach -->
{foreach $products as $product}
  <div class="product">
    <h3>{$product.name}</h3>
    <p>{$product.price|number_format:2:',':'.'}</p>
  </div>
{foreachelse}
  <p>Nessun prodotto trovato.</p>
{/foreach}

<!-- Twig: ciclo for -->
{% for product in products %}
  <div class="product">
    <h3>{{ product.name }}</h3>
    <p>{{ product.price|number_format(2, ',', '.') }}</p>
  </div>
{% else %}
  <p>Nessun prodotto trovato.</p>
{% endfor %}

Cosa è già cambiato - La cronologia

PrestaShop 1.7 (2016)

Inizio della migrazione. Il back office ha iniziato ad adottare controller Symfony con template Twig. Il front office è rimasto interamente basato su Smarty.

PrestaShop 8.x (2022-2024)

Più pagine del back office sono state migrate a Symfony e Twig.

PrestaShop 9.0 (giugno 2025)

Pietra miliare importante. Il back office è ora completamente migrato a controller Symfony e template Twig. Tuttavia, Smarty è ancora presente perché -

Il front office (temi) usa ancora principalmente Smarty
Molti moduli di terze parti usano ancora template Smarty
Le pagine admin dei moduli con AdminController legacy si basano ancora su Smarty

Impatto sui proprietari di negozi

Se usi PrestaShop 1.7 o 8.x

Nulla cambia immediatamente. I tuoi temi e moduli continueranno a funzionare. Pianifica l'eventuale aggiornamento a PrestaShop 9.0.

Se stai aggiornando a PrestaShop 9.0

L'impatto più significativo riguarda i moduli che modificano le pagine del back office. Verifica la compatibilità con gli sviluppatori dei moduli prima dell'aggiornamento.

Impatto sugli sviluppatori di moduli

Per compatibilità PrestaShop 8.x (approccio legacy) -

class AdminMyModuleController extends ModuleAdminController
{
    public function renderList()
    {
        $this->context->smarty->assign([
            'my_data' => $this->getMyData(),
        ]);
        return $this->display(__FILE__, 'views/templates/admin/list.tpl');
    }
}

Per PrestaShop 9.0+ (approccio moderno) -

class MyModuleAdminController extends FrameworkBundleAdminController
{
    public function listAction(): Response
    {
        return $this->render('@Modules/mymodule/views/templates/admin/list.html.twig', [
            'my_data' => $this->getMyData(),
        ]);
    }
}

Supportare più versioni di PrestaShop

if (version_compare(_PS_VERSION_, '9.0.0', '>=')) {
    return $this->render('@Modules/mymodule/admin/config.html.twig', $params);
} else {
    $this->context->smarty->assign($params);
    return $this->display($this->file, 'views/templates/admin/config.tpl');
}

Vantaggi di Twig rispetto a Smarty

Migliore sicurezza

Twig effettua l'escape automatico dell'output per impostazione predefinita.

<!-- Twig: escape automatico per default -->
{{ user_input }}  <!-- Entità HTML escapate automaticamente -->
{{ trusted_html|raw }}  <!-- Esplicitamente marcato come sicuro -->

<!-- Smarty: escape manuale necessario -->
{$user_input|escape:'html'}  <!-- Devi ricordarti di escapare -->
{$user_input}  <!-- PERICOLOSO: nessun escape -->

Integrazione con Symfony

Twig si integra nativamente con routing, rendering dei form, sistema di traduzione e componenti di sicurezza di Symfony.

Migliori messaggi di errore

Twig fornisce messaggi di errore chiari con numeri di riga esatti.

Pattern di migrazione comuni

Traduzione di stringhe

<!-- Smarty -->
{l s='Aggiungi al carrello' mod='mymodule'}

<!-- Twig -->
{{ 'Aggiungi al carrello'|trans({}, 'Modules.Mymodule.Shop') }}

Rendering dei hook

<!-- Smarty -->
{hook h='displayProductButtons'}

<!-- Twig -->
{{ renderhook('displayProductButtons') }}

Override dei template back office in PrestaShop 9

modules/mymodule/views/PrestaShop/Admin/Product/CatalogPage/catalog.html.twig

{% extends '@PrestaShopCore/Admin/Product/CatalogPage/catalog.html.twig' %}

{% block product_catalog_tools %}
  {{ parent() }}
  <div class="my-custom-toolbar">
    <!-- Contenuto aggiuntivo della toolbar -->
  </div>
{% endblock %}

Consigli pratici per i proprietari di negozi

Non farti prendere dal panico

La migrazione è graduale. Smarty non verrà rimosso da un giorno all'altro.

Verifica la compatibilità dei moduli prima dell'aggiornamento

Prima di aggiornare a PrestaShop 9.0, verifica che ogni modulo sia compatibile.

Considera l'aiuto professionale per negozi complessi

Con personalizzazioni estese, assumi uno sviluppatore PrestaShop esperto sia in Smarty che in Twig.

Testa tutto in un ambiente di staging

Non aggiornare mai il tuo negozio in produzione direttamente.

Leggi la risposta completa

Perché la migrazione del server richiede pianificazione

Spostare un negozio PrestaShop su un nuovo server è una delle operazioni più critiche. Con una corretta pianificazione, puoi ridurre il downtime a pochi minuti — o anche ottenere una transizione senza interruzioni.

Checklist pre-migrazione

Verificare i requisiti del nuovo server
Documentare la configurazione attuale
Elencare tutti i domini e sottodomini
Identificare i file personalizzati
Pianificare il certificato SSL

Fase 1 - Preparare il nuovo server

sudo apt update
sudo apt install apache2 mysql-server php8.1 php8.1-mysql \
  php8.1-gd php8.1-curl php8.1-intl php8.1-mbstring \
  php8.1-zip php8.1-xml php8.1-bcmath
sudo a2enmod rewrite ssl headers expires

Configurare PHP

memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Creare il database

CREATE DATABASE prestashop CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'ps_user'@'localhost' IDENTIFIED BY 'password_forte';
GRANT ALL PRIVILEGES ON prestashop.* TO 'ps_user'@'localhost';

Fase 2 - Trasferire i file

rsync -avz --progress -e ssh \
  /var/www/html/prestashop/ \
  user@nuovo-server:/var/www/html/prestashop/

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

Fase 3 - Trasferire il database

mysqldump -u root -p --single-transaction --routines --triggers \
  prestashop > /tmp/prestashop_db.sql

scp /tmp/prestashop_db.sql user@nuovo-server:/tmp/
mysql -u ps_user -p prestashop < /tmp/prestashop_db.sql

Fase 4 - Aggiornare la configurazione

Modifica app/config/parameters.php con le nuove credenziali del database. NON cambiare gli URL del negozio.

Fase 5 - Testare sul nuovo server

Modifica il file hosts locale per puntare al nuovo server e testa approfonditamente tutto il sito.

Fase 6 - Il passaggio

Abbassare il TTL DNS 48 ore prima
Mettere il vecchio negozio in manutenzione
Sincronizzazione finale del database
Sincronizzazione finale dei file
Cambiare i record DNS
Togliere il nuovo negozio dalla manutenzione

Fase 7 - Verifica post-migrazione

Svuotare tutte le cache
Rigenerare il .htaccess
Verificare SSL
Testare l'invio email
Controllare i cron job
Mantenere entrambi i server per 48-72 ore

Trappole comuni della migrazione

Percorsi hardcoded nei file dei moduli
Configurazione email
URL delle immagini
Contenuto misto dopo SSL

Leggi la risposta completa

Perché capire il database è importante

PrestaShop memorizza tutto — prodotti, ordini, clienti, impostazioni, traduzioni, immagini, prezzi — in un database MySQL. Capire la struttura del database ti dà superpoteri per diagnosticare problemi, eseguire operazioni massive e recuperare dagli errori.

Tabelle dei prodotti

ps_product

La tabella principale dei prodotti con dati fondamentali -

Colonna	Scopo
id_product	Identificatore unico del prodotto
price	Prezzo base (tasse escluse)
reference	Riferimento/SKU del prodotto
active	Abilitato (1) o disabilitato (0)

ps_product_lang

Dati prodotto specifici per lingua - nome, descrizione, meta titolo, URL.

ps_stock_available

La tabella effettiva di tracciamento delle scorte.

SELECT * FROM ps_stock_available 
WHERE id_product = 42 AND id_product_attribute = 0;

Tabelle degli ordini

ps_orders

La tabella commerciale più importante. Ogni riga è un ordine completato.

ps_order_detail

Le singole righe all'interno di un ordine con prodotto, quantità e prezzo.

SELECT o.reference, o.date_add, o.total_paid_tax_incl,
  od.product_name, od.product_quantity, od.unit_price_tax_incl
FROM ps_orders o
JOIN ps_order_detail od ON o.id_order = od.id_order
WHERE o.id_order = 12345;

Tabelle dei clienti

ps_customer

Account clienti con email, password hashata, nome, stato newsletter.

SELECT c.id_customer, c.email, c.firstname, c.date_add
FROM ps_customer c
LEFT JOIN ps_orders o ON c.id_customer = o.id_customer
WHERE o.id_order IS NULL AND c.active = 1;

Tabelle del carrello

ps_cart e ps_cart_product

Carrelli e i loro prodotti. I carrelli abbandonati rimangono qui.

Tabelle di configurazione

ps_configuration

Archivio chiave-valore per tutte le impostazioni.

SELECT name, value FROM ps_configuration 
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SSL_ENABLED', 'PS_SHOP_ENABLE');

Tabelle moduli e hook

ps_module, ps_hook, ps_hook_module

Moduli, hook e le loro associazioni.

Operazioni comuni

-- Aumento prezzi del 10%
UPDATE ps_product SET price = price * 1.10;

-- Disabilitare prodotti esauriti
UPDATE ps_product p
JOIN ps_stock_available sa ON p.id_product = sa.id_product 
SET p.active = 0
WHERE sa.quantity <= 0 AND sa.id_product_attribute = 0;

Regole di sicurezza del database

Sempre backup prima di modificare
Mai modificare ps_shop_url direttamente
Testare le query con SELECT prima di UPDATE o DELETE

Leggi la risposta completa

Cosa sono gli hook in PrestaShop?

Gli hook sono il meccanismo di estensione di PrestaShop — i punti nel codice dove i moduli possono agganciarsi per aggiungere funzionalità, modificare il comportamento o iniettare contenuto nelle pagine.

Due tipi di hook

Hook di visualizzazione

Gli hook di visualizzazione (con prefisso display) iniettano contenuto HTML nella pagina. Esempi -

displayHeader — nella sezione <head>
displayHome — area contenuto homepage
displayFooter — area footer
displayProductAdditionalInfo — info aggiuntive prodotto

Hook di azione

Gli hook di azione (con prefisso action) eseguono logica senza restituire HTML. Esempi -

actionCartSave — quando un carrello viene salvato
actionOrderStatusUpdate — quando lo stato dell'ordine cambia
actionValidateOrder — quando un ordine viene validato

Come funziona l'ordine di esecuzione

PrestaShop consulta la tabella ps_hook_module per trovare i moduli registrati su un hook. I moduli vengono eseguiti nell'ordine della colonna position.

SELECT hm.position, m.name AS module_name, h.name AS hook_name
FROM ps_hook_module hm
JOIN ps_module m ON hm.id_module = m.id_module
JOIN ps_hook h ON hm.id_hook = h.id_hook
WHERE h.name = 'displayHeader'
ORDER BY hm.position ASC;

Registrare hook nel modulo

public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('displayProductAdditionalInfo')
        && $this->registerHook('actionCartSave');
}

public function hookDisplayHeader($params)
{
    $this->context->controller->addCSS($this->_path . 'views/css/style.css');
}

public function hookActionCartSave($params)
{
    $cart = $params['cart'];
    $this->logCartActivity($cart);
}

Gestire le posizioni degli hook nel Back Office

Vai a Design > Posizioni per vedere tutti gli hook e i moduli associati. Puoi riordinare con il drag and drop o trapiantare i moduli.

Problemi comuni di esecuzione degli hook

Conflitti tra moduli

Quando due moduli sullo stesso hook producono contenuto duplicato, riordinali o sgancia il modulo problematico.

Impatto sulle prestazioni

SELECT h.name, COUNT(*) AS module_count
FROM ps_hook_module hm
JOIN ps_hook h ON hm.id_hook = h.id_hook
GROUP BY h.name
ORDER BY module_count DESC
LIMIT 20;

Hook importanti per i proprietari di negozi

Checkout - displayPayment, paymentOptions, actionValidateOrder
SEO - displayHeader, filterHtmlContent
Visualizzazione prodotto - displayProductAdditionalInfo, displayAfterProductThumbs

Leggi la risposta completa

GDPR ed e-commerce: cosa devono sapere i proprietari di negozi

Il Regolamento Generale sulla Protezione dei Dati (GDPR) e entrato in vigore nel maggio 2018 e ha cambiato radicalmente il modo in cui le aziende di e-commerce gestiscono i dati personali. Se il tuo negozio PrestaShop serve clienti nello Spazio Economico Europeo, sei soggetto al GDPR indipendentemente da dove si trova fisicamente la tua azienda. Il regolamento concede ai singoli individui diritti specifici sui propri dati personali, e il tuo negozio deve avere la capacita tecnica e organizzativa per soddisfare tali diritti.

Per i proprietari di negozi PrestaShop, gli aspetti operativamente piu impegnativi del GDPR sono le Richieste di Accesso ai Dati (SAR) e le richieste di cancellazione. Una SAR si verifica quando un cliente ti chiede di fornire una copia di tutti i dati personali che detieni su di lui. Una richiesta di cancellazione, nota anche come diritto all'oblio, si verifica quando un cliente ti chiede di eliminare i suoi dati personali. Entrambe devono essere gestite entro scadenze rigorose, e il mancato rispetto puo comportare sanzioni significative.

Questo articolo copre il lato pratico: quali dati PrestaShop memorizza, come esportarli, come eliminarli o anonimizzarli, cosa devi conservare per motivi legali e come costruire un processo affidabile attorno a queste richieste.

Quali dati personali memorizza PrestaShop

Prima di poter rispondere a qualsiasi richiesta del soggetto interessato, devi sapere esattamente dove risiedono i dati personali nella tua installazione PrestaShop. I dati personali sono qualsiasi informazione che puo identificare una persona fisica, direttamente o indirettamente. In un tipico negozio PrestaShop, i dati personali sono distribuiti in molte tabelle del database e potenzialmente in moduli di terze parti.

Tabelle core di PrestaShop contenenti dati personali

La tabella ps_customer memorizza il record principale del cliente: nome, indirizzo email, data di nascita, data di creazione, indirizzo IP alla registrazione e flag di opt-in per il marketing. La tabella ps_address memorizza gli indirizzi di consegna e fatturazione inclusi nome completo, indirizzo, citta, codice postale, paese e numeri di telefono. Un singolo cliente puo avere piu indirizzi.

La tabella ps_orders contiene la cronologia degli ordini collegati ai clienti, inclusi i metodi di pagamento e i dettagli di consegna. La tabella ps_order_detail contiene le righe di dettaglio per ogni ordine. La tabella ps_cart memorizza i dati del carrello, che includono le selezioni di prodotti e possono essere ricollegate a un cliente. Le tabelle ps_message e ps_customer_message contengono i messaggi scambiati tra il cliente e il tuo negozio attraverso il modulo di contatto o il sistema di messaggistica degli ordini.

Le tabelle ps_connections e ps_connections_source tracciano le connessioni dei visitatori inclusi indirizzi IP e URL di riferimento. La tabella ps_guest memorizza i dati dei visitatori ospiti collegati ai cookie. La tabella ps_customer_session (nelle versioni piu recenti) traccia le sessioni di accesso.

Dati nei moduli di terze parti

Qualsiasi modulo che raccoglie o elabora dati dei clienti crea posizioni di archiviazione dati aggiuntive. I moduli newsletter memorizzano indirizzi email. I moduli di recensioni memorizzano nomi dei clienti e testo delle recensioni. I moduli wishlist collegano le preferenze sui prodotti agli account dei clienti. I moduli di fidelizzazione e premi tracciano il comportamento di acquisto. I moduli di analisi possono memorizzare pattern di navigazione. Ognuno di questi moduli deve essere considerato quando si risponde a una richiesta del soggetto interessato.

Ecco perche mantenere un inventario del trattamento dei dati, un documento che elenca ogni luogo in cui i dati personali sono memorizzati, non e solo una buona pratica ma un requisito del GDPR. Senza di esso, non puoi garantire la completezza quando rispondi a una SAR.

Il modulo GDPR di PrestaShop

PrestaShop fornisce un modulo ufficiale di conformita GDPR (psgdpr) che gestisce i requisiti base delle richieste dei soggetti interessati. Questo modulo e disponibile per PrestaShop 1.7 e versioni successive e puo essere installato dal catalogo moduli nel back office.

Cosa fa il modulo

Il modulo GDPR aggiunge un framework di gestione del consenso al tuo negozio, permettendoti di tracciare quando e dove i clienti hanno dato il consenso al trattamento dei dati. Aggiunge caselle di consenso ai moduli di registrazione, ai moduli di contatto e ai moduli di iscrizione alla newsletter. Ogni azione di consenso viene registrata con un timestamp.

Per le richieste dei soggetti interessati, il modulo fornisce due funzionalita chiave. La funzione di esportazione dati genera un file PDF o CSV contenente tutti i dati personali associati all'indirizzo email di un cliente. La funzione di cancellazione dati anonimizza o rimuove i dati personali per un dato cliente.

Il modulo aggiunge anche una sezione alla pagina dell'account del cliente nel front office dove i clienti possono visualizzare e scaricare i propri dati e inviare richieste di cancellazione direttamente.

Configurazione del modulo

Dopo l'installazione, vai alla pagina di configurazione del modulo. Troverai sezioni per la gestione delle caselle di consenso (quali moduli richiedono il consenso e quale testo visualizzare), la configurazione dei moduli compatibili con il GDPR (il modulo puo interrogare i moduli compatibili per i loro dati memorizzati) e l'impostazione delle pagine di portabilita e cancellazione dei dati rivolte al cliente.

Il modulo si aggancia ad altri moduli compatibili con il GDPR attraverso un'interfaccia standardizzata. Quando un modulo implementa gli hook GDPR, il modulo psgdpr puo includere automaticamente i dati di quel modulo nelle operazioni di esportazione e cancellazione. Verifica quali dei tuoi moduli installati supportano questa integrazione, perche i moduli che non la supportano dovranno essere gestiti manualmente.

Gestione delle Richieste di Accesso ai Dati (SAR)

Quando un cliente richiede l'accesso ai propri dati personali, hai un mese di calendario per rispondere. Questa scadenza inizia dal giorno in cui ricevi la richiesta e include il tempo necessario per verificare l'identita del richiedente. Se la richiesta e complessa o ricevi un volume elevato di richieste, puoi estendere questo periodo di ulteriori due mesi, ma devi informare il cliente dell'estensione entro il primo mese.

Verifica dell'identita

Prima di rilasciare qualsiasi dato personale, devi verificare che la persona che effettua la richiesta sia chi afferma di essere. Se la richiesta proviene da un account cliente connesso, questo e generalmente sufficiente come verifica. Se la richiesta arriva via email, dovresti chiedere al richiedente di confermare dettagli che solo il titolare dell'account potrebbe conoscere, come numeri di ordine recenti o l'indirizzo in archivio. Non chiedere documenti di verifica eccessivi, poiché questo stesso potrebbe essere una violazione del GDPR (principio di minimizzazione dei dati), ma fai abbastanza per prevenire la divulgazione non autorizzata dei dati.

Utilizzo del modulo GDPR per l'esportazione

Nel back office di PrestaShop, vai alla configurazione del modulo GDPR e trova la sezione di gestione dei dati personali. Inserisci l'indirizzo email del cliente e utilizza la funzione di esportazione. Il modulo generera un file contenente i dati dalle tabelle core di PrestaShop e da qualsiasi modulo compatibile con il GDPR.

Rivedi i dati esportati prima di inviarli al cliente. L'esportazione dovrebbe includere: dettagli dell'account cliente (nome, email, data di nascita, data di registrazione), tutti gli indirizzi in archivio, cronologia degli ordini con dettagli degli ordini, cronologia del carrello, messaggi e comunicazioni, registri dei consensi e qualsiasi dato specifico dei moduli (iscrizioni alla newsletter, recensioni, wishlist).

Cosa deve includere l'esportazione

Ai sensi dell'Articolo 15 del GDPR, l'esportazione dei dati deve includere non solo i dati grezzi ma anche informazioni su come i dati vengono trattati. In particolare, dovresti fornire: le categorie di dati personali che tratti, le finalita del trattamento, eventuali terze parti con cui i dati sono stati condivisi (processori di pagamento, corrieri, piattaforme di marketing), il periodo di conservazione o i criteri per determinarlo, e informazioni sui diritti del cliente (rettifica, cancellazione, limitazione, opposizione).

Il modulo GDPR gestisce l'esportazione dei dati grezzi, ma le informazioni contestuali sulle finalita del trattamento e sulla condivisione con terze parti devono tipicamente provenire dalla tua informativa sulla privacy. Considera la possibilita di includere un link alla tua informativa sulla privacy insieme all'esportazione dei dati o di allegare una lettera di accompagnamento che riassuma queste informazioni.

Esportazione manuale per moduli non integrati

Per i moduli che non si integrano con il modulo GDPR, devi estrarre i dati manualmente. Questo tipicamente comporta l'interrogazione diretta delle tabelle del database del modulo. Per esempio, un modulo di recensioni prodotto potrebbe memorizzare dati in una tabella come ps_product_comment con l'ID del cliente come chiave esterna. Dovresti esportare tutte le righe associate all'ID del cliente.

Documenta questi passaggi manuali nella tua procedura di gestione delle SAR in modo che non vengano trascurati quando un altro membro del team gestisce una richiesta.

Diritto alla cancellazione: anonimizzazione vs eliminazione completa

Il diritto alla cancellazione (Articolo 17) permette ai clienti di richiedere l'eliminazione dei propri dati personali. Tuttavia, questo diritto non e assoluto. Esistono motivi legittimi per conservare determinati dati, e comprendere queste eccezioni e fondamentale per gestire correttamente le richieste di cancellazione.

Quando devi cancellare

Se un cliente richiede la cancellazione e nessuna delle esenzioni si applica, devi eliminare o anonimizzare i suoi dati personali senza indebito ritardo (la stessa scadenza di un mese delle SAR). I dati devono essere rimossi da tutti i sistemi, inclusi i backup se tecnicamente fattibile. Devi anche notificare eventuali terze parti con cui hai condiviso i dati (processori di pagamento, strumenti di marketing) affinche possano eliminare le loro copie.

Quando puoi rifiutare la cancellazione

L'Articolo 17(3) del GDPR elenca diverse esenzioni in cui puoi rifiutare una richiesta di cancellazione. Le piu rilevanti per l'e-commerce sono:

Obbligo legale: la legislazione fiscale nella maggior parte dei paesi UE richiede di conservare fatture e registrazioni finanziarie per un periodo specifico, tipicamente tra 5 e 10 anni a seconda della giurisdizione. Questo significa che non puoi eliminare i dati degli ordini necessari per la conformita fiscale, anche se il cliente richiede la cancellazione. Devi conservare i dati della fattura (nome, indirizzo, dettagli dell'ordine, importi) per il periodo legalmente richiesto.

Pretese legali: se e in corso una controversia, un reclamo in garanzia o una potenziale azione legale relativa agli ordini di un cliente, puoi conservare i dati necessari per stabilire, esercitare o difendersi da pretese legali.

Obbligo contrattuale: se un ordine e ancora in fase di elaborazione, spedizione o e entro il periodo di reso/garanzia, hai un motivo legittimo per conservare i dati associati fino al completamento della transazione.

L'approccio dell'anonimizzazione

La soluzione pratica per la maggior parte dei negozi e-commerce e l'anonimizzazione anziche la cancellazione completa. L'anonimizzazione significa sostituire i dati personali con segnaposto non identificativi mantenendo le registrazioni transazionali necessarie per la contabilita e la conformita legale.

Per esempio, invece di eliminare completamente un record di ordine, sostituiresti il nome del cliente con qualcosa come "Cliente Anonimizzato" o un hash, sostituiresti l'email con un segnaposto come "cancellato@anonimizzato.invalid", sostituiresti l'indirizzo con valori generici ("Indirizzo Rimosso", "Citta Rimossa") e rimuoveresti i numeri di telefono. L'ordine stesso, inclusi dettagli del prodotto, quantita, prezzi e importi fiscali, rimane intatto per scopi contabili, ma non puo piu essere collegato a un individuo identificabile.

Il modulo GDPR di PrestaShop utilizza questo approccio di anonimizzazione per impostazione predefinita. Quando elabori una richiesta di cancellazione attraverso il modulo, esso sostituisce gli identificatori personali con valori anonimizzati anziche eliminare i record direttamente.

Cosa viene anonimizzato vs cancellato

In una tipica operazione di cancellazione GDPR su PrestaShop, accade quanto segue. L'account del cliente viene disattivato e i campi personali vengono anonimizzati (il nome diventa anonimo, l'email diventa un hash, la data di nascita viene cancellata). Tutti gli indirizzi associati al cliente vengono anonimizzati (nomi, indirizzi e numeri di telefono sostituiti). I carrelli del cliente vengono eliminati completamente poiche non hanno requisiti di conservazione legale. I messaggi e le comunicazioni del servizio clienti vengono anonimizzati o eliminati. Le iscrizioni alla newsletter vengono rimosse. I record degli ospiti e i log di connessione associati al cliente vengono eliminati.

I record degli ordini vengono anonimizzati ma conservati: il nome e l'indirizzo del cliente sull'ordine vengono sostituiti con valori anonimi, ma i dettagli dell'ordine (prodotti, prezzi, tasse) rimangono per la conformita contabile. Le fatture generate da questi ordini continuano ad esistere ma con dati del cliente anonimizzati.

Passaggi tecnici per l'elaborazione di una richiesta di cancellazione

Passo 1: Verifica l'identita e documenta la richiesta

Prima di elaborare qualsiasi cancellazione, verifica l'identita del richiedente utilizzando gli stessi metodi descritti per le SAR. Registra la richiesta con un timestamp, l'identita del richiedente e il metodo di verifica utilizzato. Questo registro e esso stesso un requisito di conformita. Devi dimostrare di aver elaborato la richiesta e quando.

Passo 2: Verifica le esenzioni di conservazione

Esamina la cronologia degli ordini del cliente. Se ha ordini entro il tuo periodo di conservazione legale (verifica i requisiti della tua legislazione fiscale locale), quei record degli ordini devono essere conservati in forma anonimizzata. Se ci sono ordini aperti, controversie in corso o reclami in garanzia attivi, la cancellazione dei dati correlati dovrebbe essere posticipata fino alla loro risoluzione.

Passo 3: Elabora la cancellazione

Utilizza la funzione di cancellazione del modulo GDPR per i dati principali. Inserisci l'indirizzo email del cliente nel pannello di amministrazione del modulo ed esegui la cancellazione. Il modulo anonimizzera i dati nelle tabelle principali e in qualsiasi modulo integrato con il GDPR.

Per i moduli non integrati con il modulo GDPR, dovrai gestire la cancellazione manualmente. Questo potrebbe comportare l'esecuzione di query SQL per anonimizzare o eliminare i dati nelle tabelle specifiche del modulo, o l'utilizzo dell'interfaccia di amministrazione del modulo per rimuovere i dati del cliente.

Passo 4: Gestisci i responsabili del trattamento di terze parti

Identifica tutti i servizi di terze parti che hanno ricevuto i dati del cliente. Questo include tipicamente il tuo processore di pagamento (Stripe, PayPal, Mollie), i corrieri che hanno ricevuto gli indirizzi di consegna, le piattaforme di email marketing (Mailchimp, Sendinblue) e qualsiasi servizio di analisi che elabora dati personali. Contatta ogni responsabile e richiedi la cancellazione dei dati del cliente. La maggior parte dei principali processori ha i propri processi di cancellazione dati GDPR. Documenta ogni comunicazione.

Passo 5: Conferma il completamento

Invia una conferma al cliente (al suo indirizzo email, prima di anonimizzarlo, o attraverso qualsiasi canale di comunicazione utilizzato per la richiesta) dichiarando che i suoi dati sono stati cancellati. Includi la data di cancellazione e una nota su eventuali dati conservati in base a esenzioni legali, spiegando la base giuridica della conservazione.

Requisiti di conservazione dei dati degli ordini

L'intersezione tra il diritto alla cancellazione del GDPR e i requisiti di conservazione della legislazione fiscale e una delle aree piu comunemente fraintese. Ecco una ripartizione pratica per le principali giurisdizioni UE.

Germania: i documenti commerciali e fiscali devono essere conservati per 10 anni (Sezione 147 AO, Sezione 257 HGB). Questo include fatture, registrazioni contabili e corrispondenza correlata.

Francia: i documenti commerciali devono essere conservati per 10 anni (Articolo L123-22 Code de Commerce). I documenti fiscali per 6 anni dopo l'ultima operazione fiscalmente rilevante.

Paesi Bassi: le registrazioni dell'amministrazione fiscale devono essere conservate per 7 anni (Articolo 52 AWR).

Italia: il codice civile richiede 10 anni per i documenti commerciali (Articolo 2220 CC). I documenti fiscali per un minimo di 5 anni.

Spagna: i documenti commerciali per 6 anni (Articolo 30 Codigo de Comercio). I documenti fiscali per 4 anni.

In tutti i casi, cio che deve essere conservato e la registrazione finanziaria e transazionale, non il profilo di marketing. Devi conservare i dati della fattura (cosa e stato acquistato, per quanto, tasse pagate) ma puoi anonimizzare gli identificatori personali una volta che il rapporto contrattuale e completamente concluso (tutte le consegne effettuate, periodi di reso scaduti, pagamenti saldati).

Un approccio pratico e implementare un processo in due fasi: anonimizzazione immediata dei dati non essenziali (preferenze di marketing, cronologia di navigazione, iscrizioni alla newsletter, dati del carrello) combinata con l'anonimizzazione programmata dei dati personali relativi agli ordini una volta scaduto il periodo di conservazione legale.

Costruire un audit trail

Il GDPR richiede che tu sia in grado di dimostrare la conformita, non solo di raggiungerla. Questo significa mantenere registrazioni di ogni richiesta del soggetto interessato ricevuta e di come e stata gestita.

Cosa registrare

Per ogni richiesta, registra quanto segue: la data in cui la richiesta e stata ricevuta, il tipo di richiesta (accesso, cancellazione, rettifica, ecc.), l'identita del richiedente e come e stata verificata, la data in cui la richiesta e stata elaborata, quali azioni sono state intraprese (dati esportati, dati anonimizzati, ecc.), eventuali esenzioni applicate e la base giuridica per esse, eventuali terze parti notificate e la data in cui il richiedente e stato informato dell'esito.

Dove conservare il registro

Il registro delle richieste dovrebbe essere conservato separatamente dai dati del cliente. Se i dati del cliente vengono cancellati, devi conservare la voce del registro che mostra che hai elaborato la richiesta di cancellazione. Tuttavia, il registro stesso dovrebbe contenere dati personali minimi. Registra la richiesta utilizzando un numero di riferimento anziche memorizzare il nome completo e l'email del cliente nel registro. Un riferimento come "GDPR-2026-0042" collegato a un documento di richiesta originale conservato in modo sicuro e preferibile alla ripetizione di dati personali su piu sistemi.

Il modulo GDPR di PrestaShop mantiene il proprio registro delle operazioni sui dati, accessibile nella sezione di amministrazione del modulo. Integra questo con i tuoi registri se il tuo processo coinvolge passaggi manuali o comunicazioni con terze parti.

Tempistiche di risposta e flusso di lavoro pratico

La regola di un mese

Hai un mese di calendario dalla ricezione della richiesta per rispondere. Questo significa che se ricevi una richiesta il 15 marzo, devi rispondere entro il 15 aprile. Se una richiesta arriva il 31 gennaio, la scadenza e il 28 febbraio (o il 29 negli anni bisestili). Se la scadenza cade in un fine settimana o giorno festivo, si estende al giorno lavorativo successivo.

Estensione per richieste complesse

Se la richiesta e particolarmente complessa (per esempio, il cliente ha una cronologia degli ordini estesa su molti anni) o se ricevi un volume elevato di richieste contemporaneamente, puoi estendere la scadenza di ulteriori due mesi. Ma devi informare il richiedente entro il primo mese che stai utilizzando l'estensione e spiegarne il motivo.

Costruire un flusso di lavoro interno

Per i negozi che ricevono regolarmente richieste GDPR, stabilisci un flusso di lavoro standardizzato. Designa una persona o un team responsabile per la gestione delle richieste. Crea una casella di posta condivisa o un sistema di ticket dove le richieste vengono registrate. Sviluppa checklist passo dopo passo per ogni tipo di richiesta. Imposta scadenze interne piu brevi della scadenza legale per consentire revisioni e controlli di qualita. Conduci formazione periodica in modo che il personale del servizio clienti riconosca le richieste dei soggetti interessati (i clienti non sempre usano la terminologia legale).

Un cliente potrebbe dire "Voglio che il mio account venga eliminato" o "Mandami tutto quello che sapete su di me" senza mai menzionare il GDPR o i diritti dei soggetti interessati. Il tuo team deve riconoscere queste come richieste formali e instradarle di conseguenza.

Self-service nel front office

Il modulo GDPR di PrestaShop aggiunge una sezione nell'area dell'account del cliente dove i clienti connessi possono visualizzare i propri dati memorizzati e avviare richieste autonomamente. Questo approccio self-service ha diversi vantaggi.

Riduce il carico di lavoro manuale sul tuo team perche i clienti possono esportare i propri dati senza coinvolgere il tuo personale. Fornisce una risposta immediata per le richieste di accesso ai dati poiche l'esportazione viene generata sul momento. E crea una traccia documentata della richiesta e del suo soddisfacimento.

Tuttavia, le richieste di cancellazione inviate attraverso il portale self-service dovrebbero comunque essere revisionate prima dell'elaborazione. Una cancellazione automatica immediata potrebbe causare problemi se il cliente ha ordini aperti o se ci sono requisiti di conservazione che devono essere valutati. Configura il modulo per trattare le richieste di cancellazione self-service come richieste che richiedono la tua revisione e approvazione piuttosto che un'esecuzione automatica.

Gestione dei casi particolari

Checkout come ospite

I clienti che hanno completato l'acquisto come ospiti (senza creare un account) possono comunque inviare richieste del soggetto interessato. I loro dati sono collegati al loro indirizzo email piuttosto che a un ID account cliente. Il modulo GDPR puo cercare per indirizzo email per trovare i dati degli ordini degli ospiti. Le stesse procedure di esportazione e anonimizzazione si applicano.

Clienti con account multipli

Alcuni clienti creano piu account utilizzando indirizzi email diversi. Quando elabori una richiesta, verifica se il cliente ha account aggiuntivi. Il cliente dovrebbe essere in grado di dirti quali indirizzi email ha utilizzato. Elabora ogni account separatamente a meno che tu non possa verificare che tutti gli account appartengano alla stessa persona.

Dati nei backup

Il GDPR riconosce che l'eliminazione dei dati dai backup potrebbe non essere sempre tecnicamente fattibile. Se i tuoi backup del database contengono dati personali che sono stati cancellati dal sistema live, documentalo nei tuoi registri. Se un backup viene mai ripristinato, devi rielaborare tutte le richieste di cancellazione che sono state soddisfatte dopo che il backup e stato effettuato. Mantieni il tuo registro delle richieste GDPR separatamente dal database in modo che sopravviva a un ripristino del backup.

Dipendenti che accedono ai dati dei clienti

Il GDPR richiede che i dati personali siano accessibili solo a coloro che ne hanno bisogno per il proprio ruolo. Rivedi i permessi dei dipendenti di PrestaShop per assicurarti che solo il personale autorizzato possa accedere ai dati dei clienti, eseguire esportazioni di dati o elaborare richieste di cancellazione. Il sistema di profili dei dipendenti in PrestaShop ti permette di limitare l'accesso a sezioni specifiche del back office.

Conseguenze della non conformita

L'applicazione del GDPR e gestita dalle Autorita Nazionali per la Protezione dei Dati (DPA). Le sanzioni possono raggiungere fino a 20 milioni di euro o il 4% del fatturato annuo globale, a seconda di quale sia superiore. In pratica, le sanzioni per le piccole e medie imprese di e-commerce sono state significativamente inferiori, ma non sono trascurabili. Le DPA hanno emesso sanzioni nell'ordine delle decine di migliaia di euro per mancata risposta alle richieste dei soggetti interessati entro i tempi previsti.

Oltre alle sanzioni, la mancata gestione adeguata delle richieste dei soggetti interessati danneggia la fiducia dei clienti. I clienti che sentono che i propri diritti alla privacy vengono ignorati porteranno i loro affari altrove e potrebbero presentare reclami alla propria DPA nazionale, il che attiva indagini che consumano tempo e risorse indipendentemente dall'esito.

Riepilogo e checklist

La gestione delle richieste GDPR dei soggetti interessati in PrestaShop richiede preparazione, non solo reazione. Installa e configura il modulo GDPR ufficiale. Crea un inventario del trattamento dei dati che mappi ogni posizione in cui i dati personali sono memorizzati, inclusi moduli di terze parti e servizi esterni. Stabilisci un flusso di lavoro documentato per la ricezione, la verifica, l'elaborazione e la risposta alle richieste. Comprendi i tuoi requisiti di conservazione dei dati locali in modo da sapere cosa deve essere conservato e per quanto tempo. Implementa l'anonimizzazione anziche la cancellazione completa per i dati con obblighi di conservazione legale. Mantieni un audit trail di ogni richiesta e azione intrapresa. Forma il tuo team per riconoscere le richieste dei soggetti interessati anche quando sono formulate in modo informale.

La conformita al GDPR non e una configurazione una tantum ma un impegno operativo continuo. Revisioni regolari delle tue attivita di trattamento dei dati, delle integrazioni dei moduli e delle procedure di gestione assicurano che tu rimanga conforme man mano che il tuo negozio si evolve e le linee guida normative si sviluppano.

Leggi la risposta completa

Perché la scelta del server web è importante per PrestaShop

PrestaShop è un'applicazione PHP che genera pagine HTML dinamicamente, serve risorse statiche come immagini, file CSS e JavaScript e gestisce richieste AJAX sia dal front office che dal back office. Il server web si trova tra i visitatori e l'applicazione PHP, gestendo ogni singola richiesta HTTP. La sua architettura influisce direttamente sul numero di visitatori simultanei che il negozio può gestire, sulla velocità di caricamento delle pagine e sulla quantità di memoria del server consumata da ciascun visitatore.

Apache e Nginx sono i due server web dominanti per l'hosting di PrestaShop. Apache è stata la scelta predefinita fin dalle prime versioni di PrestaShop, e PrestaShop viene fornito con file .htaccess progettati specificamente per Apache. Nginx ha guadagnato un'adozione massiccia nell'ultimo decennio grazie alla sua gestione superiore delle connessioni simultanee e al minor consumo di memoria. Entrambi possono eseguire PrestaShop in modo efficace, ma differiscono in modi che contano per le prestazioni del negozio, la complessità della configurazione e il sovraccarico operativo.

Architettura: Modello a processi vs Loop di eventi

La differenza fondamentale tra Apache e Nginx sta nel modo in cui gestiscono le connessioni in ingresso. Questa differenza architetturale determina ogni differenza prestazionale tra i due server.

Il modello a processi/thread di Apache

Apache utilizza tradizionalmente un modello basato su processi tramite il suo prefork MPM (Multi-Processing Module). In questo modello, Apache crea un pool di processi worker e ciascun processo gestisce una richiesta alla volta. Quando arriva una richiesta, le viene assegnato un processo. Quel processo legge la richiesta, esegue il codice PHP (se si utilizza mod_php), invia la risposta e solo allora diventa disponibile per la richiesta successiva.

Il worker MPM utilizza thread anziché processi separati, consentendo più connessioni simultanee con meno memoria. L'event MPM va oltre, utilizzando un approccio basato sugli eventi per le connessioni keepalive pur continuando a utilizzare thread per l'elaborazione attiva delle richieste. Le installazioni moderne di Apache tipicamente utilizzano l'event MPM, ma il modello fondamentale prevede ancora la dedicazione di un thread a ciascuna richiesta attiva.

L'implicazione pratica è che la concorrenza di Apache è limitata dal numero di thread o processi worker configurati. Se configuri 150 worker e arrivano 151 richieste simultaneamente, l'ultima attende in coda. Ogni worker consuma memoria (tipicamente 10-30 MB per processo con mod_php, meno con PHP-FPM), quindi il numero massimo di worker è vincolato dalla RAM disponibile.

Il modello event-driven di Nginx

Nginx utilizza un'architettura asincrona basata sugli eventi. Un piccolo numero di processi worker (tipicamente uno per core della CPU) gestisce migliaia di connessioni simultaneamente utilizzando un event loop. Quando arriva una richiesta, Nginx la elabora in modo non bloccante. Se Nginx deve attendere qualcosa (una risposta da PHP-FPM, una lettura di file dal disco, una risposta da un server backend), non blocca il worker. Invece, passa a gestire altre connessioni e ritorna quando l'operazione attesa si completa.

Questo significa che un processo worker Nginx che gestisce 1.000 connessioni simultanee utilizza approssimativamente la stessa memoria di quando ne gestisce 10. Il consumo di memoria è determinato dal numero di processi worker (una manciata), non dal numero di connessioni (potenzialmente migliaia). Ecco perché Nginx eccelle sotto alta concorrenza ed è la scelta preferita per i siti ad alto traffico.

.htaccess vs configurazione del server

Una delle differenze pratiche più significative tra Apache e Nginx riguarda il modo in cui vengono gestite la riscrittura degli URL, il controllo degli accessi e altre configurazioni per directory.

Apache e .htaccess

Apache supporta i file .htaccess, che sono file di configurazione per directory che possono sovrascrivere le impostazioni a livello di server. PrestaShop fa ampio affidamento su .htaccess per la riscrittura degli URL amichevoli, il controllo degli accessi, gli header di caching e gli header di sicurezza. Quando abiliti gli URL amichevoli in PrestaShop, viene generato un file .htaccess con regole mod_rewrite che traducono URL puliti come /shoes/running-shoe nell'URL interno del dispatcher.

Il vantaggio di .htaccess è la comodità. Non hai bisogno dell'accesso root per modificare il comportamento del server web, e le modifiche hanno effetto immediato senza riavviare il server. PrestaShop può scrivere il proprio file .htaccess dal back office, il che significa che funzionalità come URL amichevoli, configurazione del media server e determinate impostazioni di sicurezza funzionano immediatamente.

Lo svantaggio è la prestazione. Ogni richiesta fa sì che Apache cerchi e analizzi i file .htaccess in ogni directory dalla document root alla directory del file richiesto. In una tipica richiesta PrestaShop, Apache potrebbe controllare la presenza di .htaccess in /, /var, /var/www, /var/www/html e oltre. Questo aggiunge I/O su disco e tempo di elaborazione a ogni richiesta. Per un sito che gestisce centinaia di richieste al secondo, questo overhead è misurabile.

Se hai accesso root alla configurazione di Apache, puoi spostare tutte le direttive .htaccess nella configurazione del VirtualHost e disabilitare l'elaborazione di .htaccess con AllowOverride None. Questo elimina l'overhead per richiesta mantenendo la stessa funzionalità. Tuttavia, le modifiche richiedono un reload di Apache per avere effetto.

Configurazione di Nginx

Nginx non supporta i file .htaccess. Tutta la configurazione risiede nei file di configurazione dei blocchi server, tipicamente sotto /etc/nginx/sites-available/ o /etc/nginx/conf.d/. Ogni regola di riscrittura URL, direttiva di controllo degli accessi e header di caching deve essere definita in questi file.

Questo significa che quando configuri PrestaShop su Nginx, devi tradurre manualmente le regole .htaccess di PrestaShop nella sintassi di configurazione di Nginx. Le regole di riscrittura sono fondamentalmente diverse tra i due server. Apache utilizza RewriteRule con pattern regex e flag come [L,R=301], mentre Nginx utilizza blocchi location con direttive try_files, rewrite e return.

Il vantaggio della configurazione centralizzata è la prestazione (nessuna scansione di file per richiesta) e la chiarezza (tutte le regole in un unico posto). Lo svantaggio è che PrestaShop non può generare la configurazione Nginx per te. Devi scriverla e mantenerla tu stesso, e ogni modifica richiede l'esecuzione di nginx -t per testare la sintassi e systemctl reload nginx per applicarla.

Integrazione PHP

Entrambi i server web devono eseguire codice PHP per generare le pagine PrestaShop. Il metodo di integrazione PHP influisce sulle prestazioni, la stabilità e la gestione delle risorse.

Apache con mod_php

L'approccio tradizionale è Apache con mod_php, dove PHP viene eseguito come modulo all'interno di ciascun processo Apache. Questo è semplice da configurare e non ha overhead di comunicazione tra processi perché PHP viene eseguito nello stesso processo che gestisce la richiesta HTTP. Tuttavia, ogni processo worker Apache porta in memoria l'intero runtime PHP, anche quando serve file statici come immagini o CSS. Questo spreca memoria perché la maggior parte delle richieste a un negozio PrestaShop riguarda risorse statiche, non pagine PHP.

Apache o Nginx con PHP-FPM

PHP-FPM (FastCGI Process Manager) esegue PHP come un pool di processi separato. Il server web comunica con PHP-FPM tramite un socket Unix o una connessione TCP utilizzando il protocollo FastCGI. Quando una richiesta richiede l'elaborazione PHP, il server web la inoltra a PHP-FPM. Quando l'elaborazione PHP è completata, PHP-FPM restituisce il risultato al server web, che lo invia al client.

Con PHP-FPM, i processi del server web che gestiscono file statici non portano il runtime PHP, risparmiando una quantità significativa di memoria. PHP-FPM offre anche la propria gestione dei processi con funzionalità come il dimensionamento dinamico del pool, lo slow log (registrazione quando una richiesta supera una soglia di tempo) e la possibilità di eseguire più versioni PHP simultaneamente per siti diversi.

Nginx utilizza esclusivamente PHP-FPM perché la sua architettura event-driven è incompatibile con l'incorporamento di PHP. Apache può utilizzare PHP-FPM tramite mod_proxy_fcgi. Nelle implementazioni moderne, PHP-FPM è l'approccio raccomandato per entrambi i server.

Configurazione PHP-FPM per PrestaShop

Indipendentemente dal server web scelto, la configurazione di PHP-FPM influisce significativamente sulle prestazioni di PrestaShop. Le impostazioni chiave includono:

pm = dynamic è solitamente la modalità migliore del process manager. Avvia un numero base di worker e ne crea altri sotto carico, fino a un massimo configurato. Questo bilancia il consumo di memoria e la reattività.

pm.max_children determina il numero massimo di processi PHP. Ogni richiesta PrestaShop tipicamente utilizza 30-80 MB di memoria, quindi dividi la RAM disponibile (meno ciò che servono il server web e il sistema operativo) per 80 per ottenere un massimo conservativo. Per un server con 4 GB di RAM utilizzabile, 50 processi figlio è un punto di partenza ragionevole.

pm.max_requests = 500 ricicla ciascun worker dopo 500 richieste, prevenendo l'accumulo di memory leak. I moduli PrestaShop occasionalmente presentano piccoli memory leak, e questa impostazione impedisce che diventino un problema.

Servizio di file statici

Un negozio PrestaShop serve grandi quantità di file statici: immagini dei prodotti, fogli di stile CSS, file JavaScript, font e upload multimediali. Le prestazioni del servizio di file statici influiscono direttamente sui tempi di caricamento delle pagine e sull'utilizzo delle risorse del server.

Prestazioni dei file statici di Apache

Apache serve i file statici attraverso i suoi processi worker. Ogni richiesta di file statico occupa un worker per la durata del trasferimento. Per file piccoli (CSS, JS, immagini piccole), questo è rapido. Per file grandi o connessioni client lente, il worker è impegnato più a lungo. Con mod_php caricato, ogni worker porta un overhead di memoria PHP non necessario anche per le richieste statiche.

Apache supporta sendfile, che consente al kernel di trasferire file direttamente dal disco al socket di rete senza copiare i dati attraverso lo spazio utente. Questo è abilitato per impostazione predefinita e aiuta con i trasferimenti di file grandi. Apache supporta anche la negoziazione del contenuto, i range di byte e le richieste condizionali (If-Modified-Since) nativamente.

Prestazioni dei file statici di Nginx

Nginx eccelle nel servizio di file statici perché il suo modello event-driven può gestire migliaia di trasferimenti di file simultanei senza aumentare proporzionalmente l'utilizzo delle risorse. Un singolo processo worker Nginx può servire centinaia di richieste di file statici simultanee. Combinato con l'uso efficiente della chiamata di sistema sendfile e il supporto integrato per la cache dei file aperti (caching dei descrittori di file per file accessibili frequentemente), il servizio di file statici è straordinariamente veloce.

Per i negozi PrestaShop con molte immagini di prodotto (che sono la maggior parte dei negozi), il vantaggio prestazionale di Nginx nel servizio dei file statici è significativo. Le pagine prodotto con 5-10 immagini, più file CSS, JavaScript e font, generano 20-30 richieste di file statici per caricamento pagina. Con traffico elevato, Nginx gestisce queste richieste con risorse sostanzialmente inferiori rispetto ad Apache.

Terminazione SSL/TLS

Ogni negozio PrestaShop dovrebbe funzionare su HTTPS, e il server web gestisce la crittografia e la decrittografia SSL/TLS (terminazione). Entrambi i server supportano bene il TLS moderno, ma ci sono differenze nella configurazione e nelle prestazioni.

Apache configura SSL tramite mod_ssl, con direttive come SSLEngine on, SSLCertificateFile e SSLProtocol nel blocco VirtualHost. Lo stapling OCSP, il caching delle sessioni e la selezione delle suite di cifratura sono tutti configurabili.

Nginx configura SSL nel blocco server con direttive come ssl_certificate, ssl_protocols e ssl_ciphers. Nginx supporta anche lo stapling OCSP e il caching delle sessioni, e la sua configurazione tende ad essere più concisa.

Dal punto di vista prestazionale, l'handshake TLS è intensivo a livello di CPU a causa della crittografia asimmetrica coinvolta. La capacità di Nginx di gestire molte connessioni simultanee con pochi processi worker significa che può gestire più handshake TLS al secondo con meno memoria. Per i negozi che ricevono grandi picchi di nuovi visitatori (durante una vendita, ad esempio), il vantaggio prestazionale TLS di Nginx può prevenire l'accodamento delle connessioni.

Reverse proxy e bilanciamento del carico

Per i negozi PrestaShop ad alto traffico, un'architettura reverse proxy separa le responsabilità e migliora la scalabilità. La configurazione più comune utilizza Nginx come reverse proxy davanti ad Apache o a un'altra istanza Nginx con PHP-FPM.

Nginx come reverse proxy per Apache

Questa configurazione ibrida combina i punti di forza di entrambi i server. Nginx si posiziona davanti, gestendo tutte le connessioni in ingresso, servendo i file statici direttamente, gestendo la terminazione SSL e inoltrando solo le richieste PHP ad Apache. Apache gestisce l'elaborazione PHP, e poiché riceve solo richieste PHP (non richieste di file statici), necessita di molti meno processi worker.

Questa architettura offre l'efficienza di gestione delle connessioni di Nginx e le prestazioni sui file statici, preservando al contempo il supporto .htaccess di Apache per le regole di riscrittura generate da PrestaShop. È un percorso di migrazione comune per i negozi che vogliono le prestazioni di Nginx senza riscrivere tutta la configurazione Apache.

La configurazione proxy di Nginx utilizza la direttiva proxy_pass per inoltrare le richieste ad Apache, tipicamente in esecuzione su una porta non standard come 8080. I file statici vengono serviti direttamente da Nginx utilizzando un blocco location che corrisponde alle estensioni dei file come .jpg, .css, .js e .png.

Configurazione completa Nginx

Per le massime prestazioni, Nginx serve tutto: file statici e richieste PHP (tramite PHP-FPM). Non c'è Apache nello stack. Questo elimina la comunicazione tra processi tra Nginx e Apache e rimuove l'overhead di memoria dell'esecuzione di due server web. Tuttavia, richiede la creazione e la manutenzione manuale della configurazione Nginx per la riscrittura degli URL di PrestaShop, che comporta più lavoro iniziale.

Configurazione Nginx raccomandata per PrestaShop

Una configurazione Nginx di produzione per PrestaShop deve gestire URL amichevoli, accesso al pannello di amministrazione, caching dei file statici, comunicazione con PHP-FPM e sicurezza. Gli elementi chiave includono un blocco server in ascolto sulle porte 80 e 443, un blocco di configurazione SSL con i certificati, una direttiva root che punta all'installazione di PrestaShop e diversi blocchi location.

Il blocco location principale utilizza try_files $uri $uri/ /index.php?$args per gestire gli URL amichevoli di PrestaShop. Questo tenta di servire la richiesta come file statico prima, poi come directory, e infine la passa al dispatcher di PrestaShop tramite index.php.

Un blocco location che corrisponde a ~ \.php$ inoltra le richieste PHP a PHP-FPM utilizzando fastcgi_pass. Include i parametri FastCGI standard e imposta SCRIPT_FILENAME sul percorso corretto.

Un blocco location per le risorse statiche imposta header di scadenza cache lunghi e disabilita il logging degli accessi per ridurre l'I/O. Pattern di corrispondenza come \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ catturano i tipi di file statici comuni.

I blocchi location relativi alla sicurezza negano l'accesso a file e directory sensibili: .htaccess, .git, config/ (eccetto config/xml/ di cui PrestaShop ha bisogno), vendor/, app/config/ e altre directory che non dovrebbero mai essere accessibili via web.

Configurazione Apache raccomandata per PrestaShop

Apache con event MPM e PHP-FPM fornisce il miglior hosting PrestaShop basato su Apache. La configurazione VirtualHost dovrebbe abilitare i moduli rewrite, headers, expires, deflate e proxy_fcgi.

Il DocumentRoot punta all'installazione di PrestaShop. AllowOverride All abilita l'elaborazione di .htaccess, necessaria a meno che non si spostino tutte le regole di riscrittura di PrestaShop nella configurazione del VirtualHost.

L'integrazione PHP-FPM utilizza SetHandler o ProxyPassMatch per inoltrare le richieste .php al socket PHP-FPM. L'approccio SetHandler con proxy:unix:/run/php/php-fpm.sock|fcgi://localhost è più semplice ed è raccomandato per la maggior parte delle configurazioni.

Abilita la compressione gzip con mod_deflate per i tipi di contenuto testuali: HTML, CSS, JavaScript, JSON, XML e SVG. Abilita il caching del browser con mod_expires, impostando tempi di scadenza lunghi per le risorse statiche e più brevi per HTML.

Benchmark prestazionali e differenze nel mondo reale

I numeri grezzi dei benchmark variano enormemente in base all'hardware, alla configurazione, alla versione PHP e alla versione PrestaShop. Piuttosto che presentare numeri specifici che sarebbero fuorvianti fuori contesto, ecco i pattern che emergono costantemente nei benchmark di hosting PrestaShop.

Per il servizio di file statici, Nginx è costantemente 2-3 volte più veloce di Apache e utilizza significativamente meno memoria. Questo divario si allarga all'aumentare della concorrenza. A 100 connessioni simultanee, la differenza potrebbe essere del 20%. A 1.000 connessioni simultanee, Nginx potrebbe utilizzare 10 volte meno memoria.

Per l'elaborazione delle richieste PHP, il server web non è il collo di bottiglia. Il tempo di elaborazione PHP-FPM domina il ciclo di vita della richiesta, ed entrambi i server web aggiungono un overhead trascurabile rispetto al tempo che PHP impiega per eseguire il codice PrestaShop, interrogare il database e renderizzare i template. La differenza nella gestione delle richieste PHP tra Apache con PHP-FPM e Nginx con PHP-FPM è tipicamente inferiore al 5%, che rientra nel margine di errore di misurazione per la maggior parte dei negozi.

Per i carichi di lavoro misti (lo scenario realistico), il vantaggio di Nginx deriva dalla sua gestione efficiente dei file statici insieme alle richieste PHP. Il caricamento di una pagina genera una richiesta PHP e 20-30 richieste di file statici. Nginx gestisce le 20-30 richieste statiche con un consumo di risorse trascurabile, mentre Apache assegna un thread worker a ciascuna. Con traffico elevato, questa differenza nel consumo di risorse significa che Nginx può sostenere una concorrenza più alta prima che le prestazioni degradino.

La conclusione pratica è che per i negozi con meno di 50 visitatori simultanei, la scelta del server web non fa quasi nessuna differenza percepibile. Per i negozi che si avvicinano o superano i 100 visitatori simultanei, i vantaggi architetturali di Nginx diventano significativi.

Guida alla migrazione: da Apache a Nginx

La migrazione di un negozio PrestaShop esistente da Apache a Nginx comporta la traduzione della configurazione, test approfonditi e lo switchover.

Passaggio 1: Traduci le regole .htaccess

Apri il tuo file .htaccess di PrestaShop e identifica tutte le regole di riscrittura attive. La sezione critica è la riscrittura degli URL amichevoli, che tipicamente inizia con RewriteCond %{REQUEST_FILENAME} !-f e RewriteRule .* - [E=REWRITEBASE:/]. Queste si traducono nella direttiva try_files di Nginx menzionata nella sezione di configurazione sopra.

Le riscritture del media server, la gestione dei prefissi di lingua e qualsiasi redirect personalizzato necessitano anch'essi di traduzione. Ogni coppia RewriteRule e RewriteCond di Apache deve essere convertita nella corrispondente direttiva location, rewrite o return di Nginx.

Passaggio 2: Configura Nginx accanto ad Apache

Installa Nginx e configuralo per ascoltare su una porta diversa (come 8080) mentre Apache continua a funzionare sulla porta 80. Questo ti permette di testare la configurazione Nginx senza influenzare il sito in produzione. Punta Nginx alla stessa document root di Apache in modo che serva gli stessi file.

Passaggio 3: Testa tutto

Accedi al sito tramite la porta di Nginx e testa ogni aspetto: la home page, le pagine delle categorie, le pagine dei prodotti, il carrello, il checkout, il pannello di amministrazione, gli URL amichevoli, il caricamento delle immagini e il routing multilingua degli URL. Presta particolare attenzione ai pattern di URL che coinvolgono caratteri speciali o parametri di query.

Passaggio 4: Effettua lo switch

Una volta completati i test, ferma Apache e riconfigura Nginx per ascoltare sulle porte 80 e 443. Ricarica Nginx e verifica che il sito in produzione funzioni correttamente. Mantieni la configurazione di Apache intatta per alcuni giorni nel caso in cui sia necessario fare un rollback.

Problemi comuni nella migrazione

Il problema più comune sono le regole di riscrittura mancanti per il routing multilingua degli URL di PrestaShop. Se il tuo negozio utilizza più lingue con codici di lingua nell'URL (come /en/, /de/, /fr/), assicurati che la configurazione Nginx gestisca correttamente questi prefissi.

Un altro problema comune sono i limiti di dimensione per l'upload dei file. Apache utilizza LimitRequestBody mentre Nginx utilizza client_max_body_size. Se importi prodotti con immagini grandi, imposta client_max_body_size ad almeno 20M.

Le richieste AJAX del pannello di amministrazione che si basano sulla riscrittura di .htaccess possono interrompersi se le regole Nginx corrispondenti sono mancanti. Testa il pannello di amministrazione accuratamente, inclusa la modifica dei prodotti, la gestione degli ordini e la configurazione dei moduli.

Quale dovresti scegliere

Scegli Apache se ti trovi su un hosting condiviso dove non controlli il server web, se fai ampio affidamento su .htaccess per la configurazione (regole generate dai moduli, plugin di sicurezza) o se non ti senti a tuo agio nello scrivere e mantenere file di configurazione Nginx. Apache con event MPM e PHP-FPM è una configurazione solida e ben supportata per i negozi PrestaShop con traffico moderato.

Scegli Nginx se hai accesso root al tuo server, il tuo negozio gestisce un traffico significativo (centinaia o migliaia di visitatori simultanei), vuoi il consumo di risorse più basso possibile per un dato livello di traffico o stai configurando un nuovo server e preferisci i benefici a lungo termine dell'architettura Nginx. Lo sforzo iniziale di configurazione è un costo una tantum che ripaga in termini di prestazioni ed efficienza delle risorse.

Scegli l'approccio del reverse proxy Nginx davanti ad Apache se vuoi le prestazioni di Nginx per i file statici e la gestione delle connessioni ma hai bisogno del supporto .htaccess di Apache per la compatibilità con i moduli PrestaShop che generano o dipendono dalle regole .htaccess.

Per la maggior parte delle nuove installazioni PrestaShop su un VPS o server dedicato, Nginx con PHP-FPM è la scelta raccomandata. La configurazione è ben documentata, i vantaggi prestazionali sono reali e la semplicità operativa di un singolo stack web server riduce l'overhead di manutenzione. Per i negozi esistenti su Apache che funzionano adeguatamente, la migrazione a Nginx è un'ottimizzazione utile ma non una necessità urgente, a meno che non si stiano raggiungendo i limiti di prestazione.

Leggi la risposta completa

Come funziona internamente la ricerca in PrestaShop

PrestaShop include un motore di ricerca prodotti integrato che opera su un indice full-text memorizzato direttamente nel database MySQL. A differenza dei servizi di ricerca esterni, questo indice risiede accanto ai dati dei prodotti nello stesso database, il che significa che è veloce da interrogare ma richiede una manutenzione esplicita per rimanere aggiornato. Comprendere come funziona questo sistema di ricerca è il primo passo per diagnosticare e risolvere i problemi di ricerca.

Quando un cliente digita una query nella barra di ricerca del tuo negozio, PrestaShop non scansiona in tempo reale ogni nome e descrizione di prodotto. Invece, cerca i termini della query in un indice pre-costruito che mappa le singole parole ai prodotti. Questo indice viene costruito scomponendo i campi di testo dei prodotti in singole parole (tokenizzazione), normalizzandole (conversione in minuscolo, rimozione degli accenti) e memorizzando la relazione tra ogni parola e i prodotti in cui appare, insieme a un peso di rilevanza.

Questo approccio è fondamentalmente lo stesso dei motori di ricerca come Google, solo su una scala molto più piccola. Il compromesso è che l'indice deve essere ricostruito ogni volta che i dati dei prodotti cambiano in modi che l'indicizzazione automatica non cattura, il che è la causa principale della maggior parte dei problemi di ricerca in PrestaShop.

Le tabelle del database di ricerca

L'indice di ricerca di PrestaShop è distribuito su diverse tabelle del database, ciascuna con uno scopo specifico nel processo di ricerca.

ps_search_word

Questa tabella memorizza ogni parola univoca estratta dai dati dei prodotti, insieme alla lingua a cui appartiene. Ogni parola riceve un id_word che serve come chiave di riferimento. La tabella è consapevole delle lingue, il che significa che la parola "shoe" nel tuo catalogo inglese e "Schuh" nel tuo catalogo tedesco sono voci separate, ciascuna collegata al rispettivo ID lingua.

Quando guardi questa tabella, vedrai migliaia o decine di migliaia di righe a seconda della dimensione del tuo catalogo e del numero di lingue. Ogni parola distinta da ogni campo prodotto indicizzato è rappresentata qui.

ps_search_index

Questa è la tabella di mappatura principale. Ogni riga collega un prodotto (id_product) a una parola (id_word) con un valore di peso. Il peso determina quanto quella parola è rilevante per quel prodotto. Una parola che appare nel nome del prodotto ha un peso maggiore rispetto alla stessa parola che appare nella descrizione, e i valori dei pesi sono configurabili nel back office.

Quando un cliente cerca "portafoglio pelle blu", PrestaShop cerca ogni parola in ps_search_word, trova i corrispondenti valori id_word, poi interroga ps_search_index per i prodotti che corrispondono a quegli ID di parole. I prodotti vengono classificati in base alla somma dei loro pesi per le parole corrispondenti, con i prodotti con peso totale più alto che appaiono per primi nei risultati.

ps_search_engine

Questa tabella memorizza i pattern dei motori di ricerca referrer utilizzati per tracciare quali motori di ricerca inviano traffico al tuo negozio. Non è direttamente correlata alla funzionalità di ricerca interna ma viene spesso confusa con essa a causa della nomenclatura simile.

ps_alias

La tabella degli alias memorizza gli alias dei termini di ricerca, ovvero grafie alternative o sinonimi che dovrebbero essere mappati su un termine di ricerca canonico. Ad esempio, potresti configurare "sneakers" come alias per "scarpe da ginnastica" in modo che i clienti che cercano uno dei due termini ottengano gli stessi risultati. Gli alias sono configurati nel back office in Parametri del negozio > Ricerca > Cerca > Alias.

Quando e perché la reindicizzazione è necessaria

PrestaShop ha una funzione di indicizzazione automatica che aggiorna l'indice di ricerca ogni volta che un prodotto viene salvato tramite il back office. Quando modifichi un prodotto e fai clic su Salva, PrestaShop reindicizza quel prodotto specifico, aggiornando le sue voci in ps_search_word e ps_search_index. Questo funziona bene per la gestione quotidiana dei prodotti.

Tuttavia, l'indicizzazione automatica non copre ogni scenario. Ci sono diverse situazioni comuni in cui è necessaria una reindicizzazione completa.

Importazioni massive di prodotti

Quando importi prodotti tramite CSV, il processo di importazione potrebbe non attivare gli hook di indicizzazione della ricerca per ogni prodotto. Questo è particolarmente comune con le importazioni grandi dove le ottimizzazioni delle prestazioni saltano i passaggi di elaborazione non essenziali. Dopo un'importazione massiva, i nuovi prodotti potrebbero esistere nel catalogo ma essere completamente invisibili alla ricerca del sito.

Modifiche dirette al database

Se tu o un modulo modificate i dati dei prodotti direttamente nel database (aggirando il modello a oggetti di PrestaShop), l'indice di ricerca non verrà aggiornato. Questo include aggiornamenti SQL a nomi dei prodotti, descrizioni o altri campi indicizzati. Qualsiasi migrazione del database, pulizia dei dati o strumento di sincronizzazione esterno che scrive direttamente in ps_product_lang lascerà l'indice di ricerca obsoleto.

Modifiche linguistiche

L'aggiunta di una nuova lingua al tuo negozio richiede una reindicizzazione completa perché l'indice di ricerca è specifico per lingua. I prodotti esistenti necessitano che il loro contenuto nella nuova lingua venga tokenizzato e aggiunto all'indice. Allo stesso modo, se modifichi il contenuto dei prodotti in una lingua specifica (specialmente tramite operazioni massive), una reindicizzazione assicura che le modifiche siano riflesse nella ricerca.

Modifiche alla configurazione dei pesi

Quando modifichi i valori dei pesi assegnati ai diversi campi dei prodotti (maggiori dettagli di seguito), le voci dell'indice esistenti mantengono i vecchi pesi. Una reindicizzazione ricalcola tutti i pesi utilizzando la nuova configurazione.

Installazioni o aggiornamenti di moduli

Alcuni moduli modificano le strutture dati dei prodotti o aggiungono campi ricercabili. Dopo l'installazione o l'aggiornamento di tali moduli, una reindicizzazione assicura che i dati nuovi o modificati siano inclusi nell'indice di ricerca.

Indice corrotto

Crash del database, migrazioni fallite o operazioni di indicizzazione interrotte possono lasciare l'indice di ricerca in uno stato inconsistente. I sintomi includono prodotti che dovrebbero apparire nei risultati di ricerca ma non appaiono, prodotti che appaiono per termini di ricerca completamente sbagliati, o la ricerca che non restituisce alcun risultato. Una reindicizzazione completa ricostruisce l'indice da zero, risolvendo queste inconsistenze.

Come reindicizzare i prodotti

Metodo dal back office

Vai a Parametri del negozio > Ricerca nel back office di PrestaShop. In cima alla pagina troverai una sezione "Indicizzazione" con le opzioni per ricostruire l'indice di ricerca. Tipicamente ci sono due opzioni: aggiungere all'indice i prodotti che non sono ancora stati indicizzati (incrementale) o ricostruire l'intero indice da zero (reindicizzazione completa).

Per la maggior parte degli scenari di risoluzione dei problemi, scegli la ricostruzione completa. L'opzione incrementale aggiunge solo i prodotti mancanti e non aggiorna le voci esistenti che potrebbero avere dati obsoleti.

Il metodo dal back office funziona bene per cataloghi piccoli e medi (fino a qualche migliaio di prodotti). Per cataloghi più grandi, potrebbe andare in timeout a causa dei limiti di tempo di esecuzione PHP, rendendo necessario il metodo CLI.

Comando CLI per la reindicizzazione

Per cataloghi grandi o flussi di lavoro automatizzati, usa la riga di comando per avviare una reindicizzazione. In PrestaShop 1.7 e successivi, il comando è:

php bin/console prestashop:search-index:rebuild

Per PrestaShop 1.6, chiameresti direttamente lo script di indicizzazione. Il percorso esatto dipende dalla tua installazione, ma la logica di indicizzazione risiede nella classe Search.

Il metodo CLI non ha gli stessi vincoli di timeout dell'interfaccia web. Per cataloghi molto grandi (decine di migliaia di prodotti in più lingue), la reindicizzazione può richiedere diversi minuti. Puoi monitorare il progresso attraverso l'output.

Se esegui PrestaShop in Docker, esegui il comando all'interno del contesto del container dove PHP e la codebase di PrestaShop sono disponibili. Assicurati di eseguirlo come l'utente del server web per evitare problemi di permessi con i file di cache che vengono generati durante il processo.

Automatizzare la reindicizzazione

Se il tuo negozio si basa su importazioni automatizzate di prodotti o sincronizzazione dati esterna, pianifica una reindicizzazione periodica come cron job. Una reindicizzazione notturna assicura che i prodotti aggiunti o modificati tramite processi automatizzati siano ricercabili il giorno successivo. La voce cron chiamerebbe lo stesso comando CLI secondo un programma.

Tieni presente che la reindicizzazione blocca brevemente le tabelle di ricerca durante la ricostruzione. Su un negozio trafficato, pianifica la reindicizzazione durante le ore di basso traffico per evitare di impattare sulla disponibilità della ricerca per i clienti attivi.

Configurazione dei pesi: Controllo della rilevanza della ricerca

PrestaShop ti permette di configurare quanto peso hanno i diversi campi dei prodotti nei risultati di ricerca. Questa è una delle funzionalità più potenti e più sottoutilizzate del sistema di ricerca integrato.

Campi di peso disponibili

La configurazione dei pesi si trova in Parametri del negozio > Ricerca. Puoi assegnare un peso (tipicamente da 1 a 10, anche se valori più alti funzionano) a ciascuno di questi campi prodotto:

Nome del prodotto: Dovrebbe tipicamente avere il peso più alto. Quando un cliente cerca un prodotto per nome, il prodotto con quel nome esatto dovrebbe apparire per primo.

Riferimento: I codici di riferimento dei prodotti sono spesso utilizzati dai clienti B2B che conoscono l'esatto SKU di cui hanno bisogno. Un peso moderato assicura che le ricerche per riferimento funzionino bene senza sopraffare le ricerche per nome.

Descrizione breve: La descrizione breve spesso contiene i punti vendita chiave e le caratteristiche del prodotto. Un peso moderato è appropriato.

Descrizione: La descrizione completa contiene il maggior testo e quindi il maggior numero di potenziali corrispondenze di parole chiave. Tuttavia, poiché contiene così tanto testo, un peso alto può causare corrispondenze irrilevanti dove un termine di ricerca appare incidentalmente in una descrizione lunga. Si raccomanda un peso inferiore rispetto al nome del prodotto.

Categoria: Includere i nomi delle categorie nella ricerca permette ai clienti di trovare prodotti tramite termini di categoria anche quando quei termini non appaiono nel testo del prodotto stesso.

Marchio (produttore): I clienti spesso cercano per nome del marchio. Un peso da moderato ad alto assicura che le ricerche per marchio restituiscano risultati rilevanti.

Tag: I tag sono termini di ricerca esplicitamente assegnati ai prodotti. Un peso alto per i tag ti dà un controllo diretto su quali prodotti appaiono per specifiche query di ricerca.

Attributi: I valori degli attributi del prodotto (taglia, colore, materiale) possono essere inclusi nell'indice di ricerca. Questo permette ricerche come "rosso XL" per restituire prodotti con quelle combinazioni di attributi.

Caratteristiche: Anche i valori delle caratteristiche del prodotto (peso, dimensioni, tipo di materiale) possono essere indicizzati.

Strategia dei pesi

Una configurazione iniziale ragionevole potrebbe essere: nome del prodotto a 6, riferimento a 4, descrizione breve a 3, descrizione a 1, categoria a 2, produttore a 3, tag a 4, attributi a 2, caratteristiche a 2. Ma i pesi ottimali dipendono interamente dal tuo catalogo e dal comportamento di ricerca dei tuoi clienti.

Se i tuoi clienti cercano frequentemente per SKU o numero di riferimento, aumenta il peso del riferimento. Se le ricerche per marchio sono importanti, aumenta il peso del produttore. Se trovi che le descrizioni lunghe causano risultati irrilevanti con ranking elevato, riduci il peso della descrizione o impostalo a zero per escludere completamente le descrizioni dall'indice.

Dopo aver modificato i pesi, esegui sempre una reindicizzazione completa affinché i nuovi valori abbiano effetto su tutti i prodotti.

Problemi di ricerca comuni e soluzioni

Prodotti che non appaiono nei risultati di ricerca

Questa è la lamentela più comune sulla ricerca. Un prodotto esiste nel catalogo ma cercarlo per nome non restituisce risultati. Le cause includono: il prodotto è stato aggiunto tramite un'importazione che non ha attivato l'indicizzazione, il prodotto è disabilitato o esaurito e la ricerca è configurata per escludere tali prodotti, oppure l'indice di ricerca è corrotto.

Soluzione: Prima verifica che il prodotto sia attivo e visibile. Poi esegui una reindicizzazione completa. Se il prodotto ancora non appare, controlla se il nome del prodotto contiene caratteri speciali che potrebbero essere rimossi durante la tokenizzazione, e controlla se l'impostazione della lunghezza minima della parola (nella configurazione della ricerca) sta escludendo parole brevi dal nome del prodotto.

Prodotti sbagliati in cima ai risultati

Quando una ricerca per "widget blu" restituisce un prodotto chiamato "supporto per widget" prima dell'effettivo prodotto "widget blu", è solitamente un problema di configurazione dei pesi. Il prodotto che si classifica più in alto ha accumulato più peso totale in tutti i campi indicizzati. Forse "widget" appare molte volte nella descrizione del prodotto supporto, e con un peso alto della descrizione, quelle occorrenze superano una singola corrispondenza nel nome del prodotto.

Soluzione: Regola i pesi dei campi per dare priorità al nome del prodotto. Imposta il peso del nome del prodotto significativamente più alto del peso della descrizione. Reindicizza dopo le modifiche.

La ricerca restituisce troppi risultati irrilevanti

Questo accade quando il peso della descrizione è troppo alto o quando parole comuni appaiono in molte descrizioni di prodotti. Una ricerca per "premium" restituisce ogni prodotto la cui descrizione contiene la parola "premium" anche quando non è una caratteristica distintiva di quei prodotti.

Soluzione: Riduci il peso della descrizione o utilizza la funzione delle parole in blacklist per escludere parole comuni non discriminanti dall'indice. La blacklist è configurata in Parametri del negozio > Ricerca e ti permette di specificare le parole che dovrebbero essere ignorate durante l'indicizzazione.

La ricerca non trova corrispondenze parziali

La ricerca integrata di PrestaShop non supporta il vero matching fuzzy. Se un cliente cerca "scarpa" non troverà prodotti che contengono solo la parola "scarpe" a meno che le funzioni di stemming o alias gestiscano la variazione. Questa è una limitazione fondamentale dell'approccio basato sull'indice di parole.

Soluzione: Usa la funzione alias per mappare le variazioni comuni ("scarpa" a "scarpe", "TV" a "televisione"). Per un matching parziale più completo, considera una soluzione di ricerca esterna come Elasticsearch.

Caratteri accentati che causano mancate corrispondenze

PrestaShop normalizza i caratteri accentati durante l'indicizzazione (ad esempio, convertendo "cafe" e "café" nella stessa forma base). Se questa normalizzazione non funziona correttamente, le ricerche con o senza accenti possono produrre risultati diversi.

Soluzione: Verifica che la configurazione della ricerca abbia la rimozione degli accenti abilitata. Reindicizza dopo la verifica. Se il problema persiste, controlla il set di caratteri e la collation del database, poiché codifiche non corrispondenti possono interferire con la normalizzazione del testo.

Ottimizzazione delle prestazioni di ricerca

Per i negozi con cataloghi grandi (oltre 10.000 prodotti), le prestazioni di ricerca possono diventare un problema. La ricerca integrata esegue query al database sulle tabelle dell'indice ad ogni richiesta di ricerca, e con un indice grande, queste query possono diventare lente.

Indicizzazione del database

Assicurati che le tabelle ps_search_word e ps_search_index abbiano indici di database appropriati. PrestaShop li crea per impostazione predefinita, ma se le tabelle sono state alterate o ricostruite, gli indici potrebbero mancare. Gli indici chiave sono su id_word e id_lang in ps_search_word, e su id_product e id_word in ps_search_index.

Lunghezza minima della parola

L'impostazione della lunghezza minima della parola controlla la parola più corta che viene indicizzata. Il valore predefinito è solitamente 3 caratteri, il che significa che le parole di uno e due caratteri sono escluse. Aumentare questo a 4 riduce la dimensione dell'indice e può migliorare la velocità di ricerca, ma significa che le ricerche per termini brevi come "XL" o "TV" non funzioneranno. Bilancia la dimensione dell'indice con i tuoi requisiti di ricerca.

Parole in blacklist

Aggiungere parole comuni ("il", "e", "per", "con") alla blacklist riduce significativamente la dimensione dell'indice perché queste parole appaiono in quasi ogni descrizione di prodotto. Tabelle di indice più piccole significano query più veloci.

Ottimizzazione delle tabelle

Dopo una reindicizzazione completa, esegui OPTIMIZE TABLE ps_search_word, ps_search_index in MySQL. Il processo di reindicizzazione cancella e reinserisce grandi quantità di righe, il che può lasciare le tabelle frammentate. L'ottimizzazione recupera quello spazio e migliora le prestazioni delle query.

Elasticsearch come alternativa

Per i negozi che hanno superato la ricerca integrata di PrestaShop, Elasticsearch fornisce un significativo upgrade sia nella qualità della ricerca che nelle prestazioni. Elasticsearch è un motore di ricerca dedicato che funziona come servizio separato e offre funzionalità che la ricerca basata su MySQL integrata non può eguagliare.

Cosa aggiunge Elasticsearch

Il matching fuzzy permette a Elasticsearch di trovare risultati anche quando il termine di ricerca è scritto male. Una ricerca per "pell" troverà comunque prodotti contenenti "pelle". Lo stemming riduce le parole alla loro forma radice, quindi "correre", "corre" e "correva" corrispondono tutti a prodotti contenenti una qualsiasi di queste variazioni. Il supporto dei sinonimi ti permette di definire relazioni tra parole ("divano" e "sofà") a livello del motore di ricerca piuttosto che tramite alias manuali.

La ricerca a faccette (filtrare i risultati per attributi come fascia di prezzo, colore, marchio) è drasticamente più veloce con Elasticsearch perché è progettato esattamente per questo tipo di query di aggregazione. I suggerimenti di autocompletamento e le funzionalità "forse cercavi" sono anche capacità native di Elasticsearch.

In termini di prestazioni, Elasticsearch gestisce cataloghi grandi (oltre 100.000 prodotti) con tempi di risposta inferiori al secondo perché utilizza indici invertiti ottimizzati per la ricerca full-text, a differenza di MySQL che è principalmente progettato per dati relazionali.

Integrazione con PrestaShop

Diversi moduli PrestaShop forniscono l'integrazione con Elasticsearch. Questi moduli tipicamente sostituiscono il controller di ricerca predefinito con uno che interroga Elasticsearch invece delle tabelle di ricerca MySQL. I dati dei prodotti vengono sincronizzati da PrestaShop a Elasticsearch in tempo reale (al salvataggio del prodotto) o tramite sincronizzazione batch periodica.

L'esecuzione di Elasticsearch richiede un server o container dedicato con RAM adeguata (minimo 2GB per piccoli cataloghi, di più per quelli più grandi). Aggiunge complessità operativa poiché ora hai un altro servizio da monitorare e mantenere. Per molti negozi piccoli e medi, la ricerca integrata con una corretta configurazione dei pesi e una reindicizzazione regolare è sufficiente.

Quando considerare Elasticsearch

Considera Elasticsearch quando il tuo catalogo supera i 10.000 prodotti e le prestazioni di ricerca stanno degradando, quando i clienti spesso scrivono male i termini di ricerca e si aspettano matching fuzzy, quando hai bisogno di funzionalità avanzate come autocompletamento o filtraggio a faccette, o quando la qualità della ricerca è un differenziatore competitivo per il tuo business (negozi B2B con cataloghi prodotti complessi, per esempio).

La checklist della reindicizzazione

Quando la ricerca non funziona correttamente nel tuo negozio PrestaShop, segui questo processo diagnostico e di risoluzione. Primo, verifica che i prodotti problematici siano attivi, visibili e disponibili (se la ricerca esclude i prodotti esauriti). Secondo, controlla la configurazione dei pesi di ricerca e assicurati che corrisponda alle tue priorità. Terzo, esegui una ricostruzione completa dell'indice di ricerca dal back office o CLI. Quarto, svuota la cache di PrestaShop dopo la reindicizzazione. Quinto, testa la ricerca con termini specifici per verificare la correzione. Sesto, se i problemi persistono, controlla le tabelle ps_search_word e ps_search_index direttamente per verificare che i prodotti problematici abbiano voci. Settimo, se l'indice sembra corretto ma la ricerca ancora fallisce, indaga la logica del controller di ricerca e qualsiasi modulo che lo sovrascrive.

La reindicizzazione regolare, combinata con una configurazione dei pesi ponderata e una lista di alias ben mantenuta, mantiene la ricerca integrata di PrestaShop funzionante in modo affidabile per la maggior parte dei negozi. Per coloro che necessitano di più, Elasticsearch fornisce un percorso di aggiornamento senza richiedere un cambio di piattaforma.

Leggi la risposta completa

Comprendere i tre livelli di cache in PrestaShop

PrestaShop utilizza diversi meccanismi di caching per distribuire le pagine rapidamente. Ogni livello opera a un diverso livello dello stack e comprendere cosa fa ciascuno, quando interviene e quando e necessario svuotarlo e essenziale sia per l'ottimizzazione delle prestazioni che per la risoluzione dei problemi. I tre livelli di cache piu importanti sono la cache dei template Smarty, PHP OPcache e la cache del browser. Lavorano insieme, ma risolvono problemi diversi e richiedono approcci di gestione differenti.

Quando un cliente visita il tuo negozio, la richiesta passa attraverso tutti e tre i livelli in ordine inverso. Il browser controlla prima la sua cache locale. Se ha una copia aggiornata della risorsa, non contatta affatto il server. Se il browser invia una richiesta, PHP la elabora. OPcache garantisce che i file PHP vengano compilati una sola volta e riutilizzati dalla memoria invece di essere analizzati nuovamente a ogni richiesta. Infine, la cache Smarty garantisce che il rendering dei template, che include l'analisi della sintassi dei template e l'esecuzione della logica dei template, avvenga solo quando necessario e non a ogni caricamento di pagina.

I problemi sorgono quando questi livelli servono contenuti obsoleti. Modifichi un file template, ma la pagina appare uguale. Aggiorni un file PHP, ma il vecchio comportamento persiste. Modifichi il CSS, ma il browser mostra ancora i vecchi stili. Ciascuno di questi sintomi punta a un diverso livello di cache, e svuotare quello sbagliato fa perdere tempo senza risolvere il problema.

Cache dei template Smarty - come funziona

Smarty e il motore di template che PrestaShop utilizza per generare l'HTML. Ogni file .tpl nel tuo tema e nei moduli passa attraverso Smarty prima di diventare HTML inviato al browser. Il caching di Smarty opera in due fasi distinte: compilazione e caching dell'output.

Compilazione dei template

Quando Smarty incontra un file .tpl per la prima volta, lo compila in un file PHP. Questo file compilato viene memorizzato nella directory /var/cache/prod/smarty/compile/ (o /var/cache/dev/smarty/compile/ in modalita debug). Il file compilato contiene la logica del template tradotta in PHP puro, che si esegue molto piu velocemente dell'analisi della sintassi Smarty a ogni richiesta.

Smarty verifica se la versione compilata e aggiornata confrontando i timestamp. Se il file sorgente .tpl e piu recente della versione compilata, Smarty lo ricompila automaticamente. Questo e controllato dall'impostazione compile_check. In produzione, puoi disabilitare il controllo di compilazione per le massime prestazioni, il che significa che Smarty assume che i template compilati siano sempre aggiornati e non controlla mai i file sorgente.

Cache dell'output dei template

Oltre alla compilazione, Smarty puo anche memorizzare nella cache l'output renderizzato dei template. Quando la cache dell'output e abilitata, Smarty memorizza l'output HTML finale di un template e lo serve direttamente nelle richieste successive senza eseguire alcuna logica del template. Questo e piu aggressivo della cache di compilazione perche salta non solo la fase di analisi ma anche l'elaborazione dei dati e l'esecuzione della logica all'interno del template.

La cache dell'output in PrestaShop e gestita per hook del modulo. Ogni modulo puo dichiarare se il suo output dell'hook e cacheable, e PrestaShop assegna chiavi di cache basate su fattori come la lingua corrente, il negozio, la valuta e il gruppo clienti. Questo significa che un cliente francese e un cliente inglese ottengono versioni in cache separate.

Impostazioni della cache Smarty in PrestaShop

Configuri la cache Smarty nel back office in Parametri avanzati > Prestazioni. Le impostazioni rilevanti sono:

Compilazione dei template: Questo controlla come Smarty gestisce la compilazione dei template. Le opzioni sono tipicamente "Non ricompilare mai" (piu veloce, usa sempre la versione compilata), "Ricompila se modificato" (controlla i timestamp dei file, buon compromesso) e "Forza compilazione" (ricompila a ogni richiesta, solo per lo sviluppo). In produzione, usa "Ricompila se modificato" a meno che tu non sia sicuro che i tuoi template non cambino mai tra i deployment, nel qual caso "Non ricompilare mai" offre un piccolo guadagno di prestazioni aggiuntivo.

Cache: Questo attiva/disattiva la cache dell'output di Smarty. Quando abilitato, Smarty memorizza l'output HTML renderizzato e lo serve senza rieseguire la logica del template. Questo fornisce vantaggi significativi in termini di prestazioni per i negozi con template complessi o molti hook di moduli. Il tipo di cache puo essere impostato su filesystem (predefinito) o un gestore di cache personalizzato.

Ottimizzazioni multi-front: Questo abilita il caching su piu server front-end. Rilevante solo per configurazioni cluster.

Svuota cache: Le opzioni includono "Non svuotare mai i file di cache", "Svuota cache a ogni modifica" e strategie di svuotamento specifiche. Per la maggior parte dei negozi, lo svuotamento alla modifica e la scelta giusta perche garantisce che gli aggiornamenti siano visibili immediatamente beneficiando comunque della cache tra le modifiche.

Svuotare la cache Smarty

Per svuotare manualmente la cache Smarty, puoi usare il pulsante "Svuota cache" nella pagina Prestazioni del back office. Questo elimina i template compilati e l'output in cache dalla directory /var/cache/. Puoi anche svuotarla eliminando i file direttamente dal server:

Eliminare i template compilati: rimuovere il contenuto di var/cache/prod/smarty/compile/

Eliminare l'output in cache: rimuovere il contenuto di var/cache/prod/smarty/cache/

Devi svuotare la cache Smarty quando modifichi file di template .tpl (se il controllo di compilazione e disabilitato), quando installi o aggiorni un modulo che modifica i template, quando cambi tema o quando modifichi la configurazione relativa ai template. Se modifichi un file .tpl e la modifica non appare nel front-end, la cache di compilazione Smarty e quasi sempre la causa.

PHP OPcache - come funziona

PHP OPcache e una cache di bytecode integrata in PHP. Quando PHP esegue uno script, passa attraverso tre fasi: lexing (scomposizione del codice sorgente in token), parsing (costruzione di un albero sintattico astratto) e compilazione (generazione del bytecode che il motore PHP esegue). OPcache memorizza il bytecode compilato in memoria condivisa in modo che le richieste successive per lo stesso script saltino completamente le fasi di lexing, parsing e compilazione.

Questo e diverso dalla cache Smarty. Smarty memorizza nella cache l'output del rendering dei template (HTML). OPcache memorizza nella cache l'output della compilazione PHP (bytecode). Operano a livelli completamente diversi. Un template Smarty che e stato compilato in un file PHP da Smarty beneficia comunque di OPcache perche quel file PHP compilato stesso viene memorizzato nella cache come bytecode da OPcache.

Configurazione OPcache per PrestaShop

OPcache e configurato nel file php.ini. Le impostazioni piu importanti per PrestaShop sono:

opcache.enable=1 attiva OPcache. Dovrebbe essere sempre attivato in produzione. La differenza di prestazioni e significativa: l'esecuzione PHP diventa da 2 a 5 volte piu veloce con OPcache attivato.

opcache.memory_consumption=256 imposta la quantita di memoria condivisa (in megabyte) disponibile per memorizzare il bytecode compilato. PrestaShop con diversi moduli puo facilmente consumare 128 MB o piu. Se questo valore e troppo basso, OPcache rimuove le voci piu vecchie per fare spazio a quelle nuove, il che vanifica lo scopo. Impostalo a 256 MB o superiore per i negozi con molti moduli. Puoi verificare l'utilizzo con opcache_get_status() per vedere quanta memoria viene effettivamente consumata.

opcache.max_accelerated_files=20000 imposta il numero massimo di file PHP che possono essere memorizzati nella cache. Il core di PrestaShop piu i moduli possono facilmente avere 10.000 o piu file PHP. Il valore effettivo utilizzato da OPcache viene arrotondato per eccesso al numero primo successivo da un insieme predefinito, quindi impostare 20000 risulta in un limite effettivo di 20479. Verifica con opcache_get_status() che non stai raggiungendo questo limite.

opcache.validate_timestamps=1 dice a OPcache di verificare se i file sorgente sono cambiati. Quando abilitato, OPcache controlla l'ora di modifica del file a intervalli definiti da revalidate_freq. In produzione, puoi impostarlo a 0 (disabilitato) per le massime prestazioni, ma devi poi riavviare PHP-FPM o chiamare opcache_reset() ogni volta che distribuisci nuovo codice.

opcache.revalidate_freq=60 definisce con quale frequenza (in secondi) OPcache controlla le modifiche ai file quando validate_timestamps e abilitato. Un valore di 60 significa che OPcache controlla ogni file al massimo una volta al minuto. Valori piu alti significano prestazioni migliori ma ritardi piu lunghi prima che le modifiche al codice abbiano effetto. Per lo sviluppo attivo, impostalo a 0 o 2. Per la produzione, 60 e un buon compromesso.

opcache.interned_strings_buffer=16 alloca memoria per le stringhe internalizzate, che PHP usa per deduplicare stringhe identiche tra diversi script. PrestaShop ne beneficia perche molti moduli condividono gli stessi nomi di classi, nomi di funzioni e letterali di stringa. Impostalo a 16 MB o superiore.

opcache.save_comments=1 deve essere abilitato per PrestaShop. PrestaShop e alcune delle sue dipendenze utilizzano annotazioni PHP DocBlock che vengono lette a runtime. Se lo disabiliti, alcune funzionalita smettono di funzionare.

OPcache e la separazione CLI vs Web

Un dettaglio importante su OPcache e che gli ambienti CLI (riga di comando) e web (PHP-FPM o mod_php) mantengono pool OPcache separati. Svuotare OPcache dalla riga di comando (ad esempio, eseguendo uno script PHP che chiama opcache_reset() via CLI) non svuota l'OPcache web. Per svuotare l'OPcache web, devi riavviare il servizio PHP-FPM o eseguire opcache_reset() tramite una richiesta web.

Questa distinzione e importante nei workflow di deployment. Se distribuisci nuovo codice e svuoti OPcache tramite un comando CLI, il tuo sito web continua a servire il vecchio bytecode finche anche l'OPcache web non viene svuotato. Molti strumenti di deployment gestiscono questo chiamando un endpoint URL speciale che attiva opcache_reset(), o riavviando PHP-FPM come parte del processo di deployment.

Quando svuotare OPcache

Devi svuotare OPcache ogni volta che modifichi, carichi o sostituisci file PHP sul tuo server. Questo include il deployment di una nuova versione di PrestaShop, l'installazione o l'aggiornamento di moduli, la modifica di file PHP direttamente sul server e l'aggiornamento delle dipendenze Composer. Se modifichi un file PHP e il vecchio comportamento persiste nonostante il file sia chiaramente modificato sul disco, OPcache sta servendo il vecchio bytecode. Riavviare PHP-FPM e il modo piu affidabile per svuotarlo.

Cache del browser - come funziona

La cache del browser e l'ultimo livello e opera interamente sul lato client. Quando un browser scarica una risorsa (file CSS, file JavaScript, immagine, font o anche una pagina HTML), puo memorizzare una copia locale e riutilizzarla per le richieste successive. Questo elimina completamente i roundtrip di rete per le risorse in cache, che e il miglioramento delle prestazioni piu grande possibile perche nessuna ottimizzazione lato server puo battere una latenza di rete pari a zero.

La cache del browser e controllata dagli header di risposta HTTP che il tuo server invia insieme a ogni risorsa. Gli header piu importanti sono Cache-Control, Expires, ETag e Last-Modified.

Header Cache-Control

L'header Cache-Control e il meccanismo principale per controllare la cache del browser. Supporta diverse direttive:

max-age=31536000 dice al browser di memorizzare nella cache la risorsa per un massimo di 31.536.000 secondi (un anno). Durante questo periodo, il browser usa la sua copia locale senza contattare il server. Questo e ideale per risorse statiche come CSS, JavaScript e immagini che includono un identificatore di versione nel loro URL (come un hash o una query string).

no-cache non significa "non memorizzare nella cache". Significa che il browser puo memorizzare la risorsa nella cache ma deve validarla con il server prima di usare la copia in cache. Il server risponde con uno stato 304 (Not Modified), che indica che la versione in cache e ancora valida, o con un 200 con il nuovo contenuto.

no-store impedisce effettivamente il caching. Il browser deve scaricare la risorsa nuova ogni volta. Usa questo per contenuti sensibili che non dovrebbero mai essere memorizzati localmente.

public indica che la risposta puo essere memorizzata nella cache da qualsiasi cache, inclusi CDN e server proxy. Usa questo per risorse statiche.

private indica che la risposta e specifica per un singolo utente e non dovrebbe essere memorizzata da cache condivise come i CDN. Usa questo per pagine che contengono contenuti specifici dell'utente, come la pagina dell'account cliente o il carrello.

Header ETag

Un ETag (Entity Tag) e un identificatore univoco per una versione specifica di una risorsa. Il server lo genera (tipicamente un hash del contenuto del file) e lo invia con la risposta. Quando il browser deve validare la sua copia in cache, invia l'ETag al server in un header If-None-Match. Il server confronta gli ETag e restituisce 304 (usa la tua versione in cache) o 200 (ecco la nuova versione).

Gli ETag sono utili quando vuoi il caching del browser con validazione. Il browser fa comunque una richiesta al server, ma se il contenuto non e cambiato, il server restituisce una piccola risposta 304 invece della risorsa completa. Questo risparmia banda garantendo al contempo l'aggiornamento.

Last-Modified e If-Modified-Since

Questi header funzionano in modo simile agli ETag ma usano timestamp invece di hash del contenuto. Il server invia il timestamp Last-Modified con la risorsa, e il browser lo reinvia come If-Modified-Since durante la validazione. Il server controlla se il file e stato modificato da quel momento e restituisce 304 o 200 di conseguenza.

Gli ETag sono generalmente preferiti rispetto a Last-Modified perche sono basati sul contenuto piuttosto che sul tempo, il che evita problemi di sincronizzazione dell'orologio ed e piu preciso. Tuttavia, la maggior parte dei server invia entrambi, e i browser usano quello disponibile.

Configurazione della cache del browser per PrestaShop

Le risorse statiche di PrestaShop (CSS, JavaScript, immagini) dovrebbero essere memorizzate aggressivamente nella cache dai browser. L'approccio standard e configurare il tuo server web per aggiungere gli header Cache-Control appropriati alle risposte dei file statici.

Per Apache, usi i moduli mod_expires e mod_headers nel tuo file .htaccess. Il file .htaccess predefinito di PrestaShop include alcune regole di caching, ma potresti volerle estendere. Una configurazione tipica imposta max-age=31536000 per immagini, font, CSS e file JavaScript, mentre le risposte HTML ricevono no-cache per garantire contenuti aggiornati.

Per Nginx, aggiungi direttive expires nei tuoi blocchi location per i file statici. Ad esempio: location ~* \\.(css|js|jpg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } memorizza nella cache le risorse statiche per un anno e le contrassegna come immutabili (dicendo al browser di non validarle nemmeno).

Cache busting in PrestaShop

Se imposti tempi di cache lunghi per i file CSS e JavaScript, come fanno i browser a ottenere le versioni aggiornate quando distribuisci modifiche? Qui entra in gioco il cache busting. PrestaShop gestisce questo in modo diverso a seconda che CCC (Combine, Compress, Cache) sia abilitato.

Con CCC abilitato, PrestaShop combina i file CSS e JavaScript in bundle e genera nomi di file che includono un hash del contenuto. Quando il contenuto cambia, il nome del file cambia, e i browser scaricano il nuovo file perche non hanno mai visto quell'URL prima. Questo e l'approccio di cache busting piu affidabile.

Senza CCC, PrestaShop serve i file CSS e JavaScript individuali ai loro URL originali. Alcuni temi e moduli aggiungono una query string di versione (come ?v=1.2.3) a questi URL, che cambia quando il modulo viene aggiornato. I browser trattano l'URL con una query string diversa come una risorsa diversa e la scaricano nuova.

Le immagini sono piu complicate perche i loro URL tipicamente non cambiano a meno che l'immagine stessa non venga sostituita. Se sostituisci un'immagine con una nuova allo stesso URL, i browser che hanno la vecchia versione in cache continueranno a mostrarla fino alla scadenza della cache. In questo caso, devi cambiare il nome del file dell'immagine o svuotare le cache dei browser (cosa che non puoi fare per i tuoi visitatori). La soluzione pratica e usare URL di immagini con versione o attendere che la cache scada naturalmente.

Come i tre livelli interagiscono

Comprendere come questi tre livelli di cache interagiscono e fondamentale per una risoluzione efficace dei problemi. Ecco il ciclo di vita di una richiesta tipica:

Un cliente visita una pagina prodotto. Il browser controlla la sua cache per l'HTML di quella pagina. Poiche l'HTML e tipicamente servito con no-cache, il browser invia una richiesta al server (possibilmente con un header If-Modified-Since o If-None-Match per la validazione).

Il server web riceve la richiesta e la passa a PHP. L'OPcache di PHP-FPM ha il bytecode per index.php di PrestaShop, il dispatcher, i controller e tutti i file dei moduli memorizzati nella cache in memoria condivisa. PHP esegue il bytecode senza ricompilare alcun file sorgente.

Il controller di PrestaShop chiama Smarty per renderizzare il template. Smarty controlla la sua cache per una versione compilata del template. Se la cache dell'output e abilitata e un output in cache valido esiste per questa combinazione di lingua, gruppo clienti e altre chiavi di cache, Smarty restituisce l'HTML in cache direttamente. In caso contrario, Smarty esegue il template compilato (che OPcache ha anche memorizzato nella cache come bytecode poiche i template Smarty compilati sono file PHP), genera l'HTML, lo memorizza nella cache dell'output e lo restituisce.

PHP invia la risposta HTML al browser, insieme agli header HTTP che controllano la cache del browser. Il browser renderizza l'HTML e richiede tutti i file CSS, JavaScript e le immagini referenziati in esso. Per ciascuna di queste risorse, il browser controlla la sua cache locale. Se ha una copia aggiornata (basata sul max-age di Cache-Control), usa la copia locale senza contattare il server. Se la copia in cache necessita di validazione, invia una richiesta condizionale con header ETag o If-Modified-Since.

Risoluzione dei problemi con contenuti obsoleti

Quando le modifiche apportate non appaiono nel front-end, devi identificare quale livello di cache e responsabile. Ecco un approccio sistematico:

Passo 1: Controllare il browser

Apri la pagina in una finestra di navigazione privata o in incognito, o esegui un aggiornamento forzato (Ctrl+Shift+R nella maggior parte dei browser). Se la modifica appare in incognito ma non in una finestra normale, la cache del browser e la causa. Svuota la cache del browser o attendi la sua scadenza.

Per le modifiche CSS e JavaScript in particolare, controlla la scheda rete nei DevTools del browser. Guarda gli header di risposta per il file che hai modificato. Se la risposta mostra un 304 (Not Modified) e il contenuto e vecchio, il file lato server potrebbe non essere effettivamente cambiato (controlla OPcache). Se il browser non sta nemmeno facendo una richiesta per il file (mostra "from disk cache" o "from memory cache"), il max-age di Cache-Control non e scaduto.

Passo 2: Controllare la cache Smarty

Se la modifica non appare nemmeno in incognito, il problema e lato server. Per le modifiche ai template, svuota la cache Smarty dal back office (Parametri avanzati > Prestazioni > Svuota cache) o elimina il contenuto di var/cache/prod/smarty/. Ricarica la pagina e verifica se la modifica appare.

Passo 3: Controllare OPcache

Se svuotare la cache Smarty non aiuta e la modifica riguarda un file PHP (non un template), OPcache sta probabilmente servendo il vecchio bytecode. Riavvia PHP-FPM o chiama opcache_reset() tramite una richiesta web. Su hosting condiviso dove non puoi riavviare PHP-FPM, il pannello di controllo dell'hosting potrebbe avere un'opzione per svuotare OPcache, oppure puoi creare un piccolo file PHP che chiama opcache_reset() e accedervi tramite il browser.

Passo 4: Controllare altre cache

PrestaShop ha meccanismi di cache aggiuntivi oltre a questi tre livelli. La cache di Symfony (in PrestaShop 1.7 e 8.x) memorizza i container dei servizi Symfony compilati, le definizioni delle rotte e altri dati del framework. Svuotala eliminando le directory var/cache/prod/ e var/cache/dev/. Se usi un reverse proxy come Varnish o un CDN come Cloudflare, questi aggiungono un ulteriore livello di cache che deve essere svuotato separatamente.

Configurazione ottimale per la produzione

Per un negozio PrestaShop in produzione, la configurazione ottimale della cache bilancia prestazioni e manutenibilita:

Smarty: Imposta la compilazione dei template su "Ricompila se modificato". Abilita la cache dell'output. Imposta lo svuotamento della cache su "Svuota alla modifica". Questo offre solide prestazioni di cache garantendo al contempo che le modifiche dal back office (come la modifica di pagine CMS o la modifica della configurazione dei moduli) abbiano effetto immediato.

OPcache: Abilita con almeno 256 MB di memoria, 20000 max accelerated files, validate_timestamps abilitato con revalidate_freq di 60 secondi. Questa configurazione significa che le modifiche al codice impiegano fino a 60 secondi per avere effetto, il che e accettabile in produzione. Se distribuisci raramente modifiche al codice e vuoi le massime prestazioni, disabilita validate_timestamps e riavvia PHP-FPM dopo ogni deployment.

Cache del browser: Imposta Cache-Control con valori max-age lunghi (almeno un mese, idealmente un anno) per le risorse statiche (CSS, JavaScript, immagini, font). Usa no-cache per le risposte HTML in modo che le pagine siano sempre validate. Abilita CCC in PrestaShop per ottenere nomi di file con hash del contenuto per i file CSS e JavaScript combinati, il che fornisce cache busting automatico quando le risorse cambiano.

Con questa configurazione, il tuo negozio beneficia di tutti e tre i livelli di cache che lavorano insieme. Le risorse statiche vengono servite dalla cache del browser senza alcun contatto con il server. I file PHP vengono eseguiti dal bytecode in cache senza ricompilazione. E il rendering dei template viene memorizzato nella cache in modo che la logica Smarty venga eseguita solo quando il contenuto cambia. Il risultato e un negozio che si carica rapidamente per i visitatori di ritorno e gestisce il traffico elevato in modo efficiente lato server.

Quando svuotare ogni livello di cache

Per evitare sia contenuti obsoleti che svuotamenti di cache non necessari, segui queste linee guida:

Svuota la cache Smarty quando modifichi file .tpl, cambi posizioni o hook dei moduli, installi o aggiorni moduli che modificano template, o cambi impostazioni relative al tema. Non devi svuotare la cache Smarty quando modifichi file PHP o aggiorni file CSS o JavaScript.

Svuota OPcache quando modifichi file PHP, installi o aggiorni moduli, aggiorni il core di PrestaShop, o esegui Composer per aggiornare le dipendenze. Non devi svuotare OPcache per modifiche ai template o al CSS.

Svuota la cache del browser quando devi vedere le modifiche CSS, JavaScript o delle immagini immediatamente durante lo sviluppo. Per la produzione, affidati al cache busting (URL con versione, nomi di file con hash CCC) invece di chiedere agli utenti di svuotare le loro cache. Non puoi controllare le cache dei browser dei tuoi visitatori, quindi il tuo processo di deployment deve tenerne conto utilizzando tecniche di cache busting appropriate.

Una sequenza completa di svuotamento della cache dopo un deployment importante sarebbe: svuotare le directory di compilazione e cache Smarty, riavviare PHP-FPM per svuotare OPcache, purgare la cache del CDN o reverse proxy se applicabile, e verificare in una finestra di navigazione privata. Per modifiche minori (come la modifica di un singolo template), svuotare solo il livello rilevante e sufficiente e piu veloce.

Leggi la risposta completa

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Leggi la risposta completa

Cos'è Varnish e perché è importante per PrestaShop

Varnish Cache è un reverse proxy HTTP che si posiziona tra il tuo server web e internet, servendo copie cachate delle pagine senza mai toccare PHP o MySQL. Quando un visitatore richiede una pagina che Varnish ha in cache, la risposta arriva direttamente dalla memoria in microsecondi. PHP non viene eseguito. MySQL non riceve alcuna query. Il server web nota appena che la richiesta è avvenuta.

Questo è fondamentalmente diverso da come funzionano i moduli di full page cache (FPC) basati su PHP in PrestaShop. Un modulo FPC viene comunque eseguito all'interno di PHP. La richiesta raggiunge Apache o Nginx, PHP si avvia, PrestaShop si inizializza (caricando la configurazione, stabilendo connessioni al database, analizzando le rotte), e poi il modulo FPC intercetta la richiesta prima che la logica completa del controller venga eseguita, servendo un file HTML memorizzato nella cache. Sebbene sia significativamente più veloce rispetto al rendering della pagina da zero, comporta comunque l'avvio di PHP e il caricamento del framework PrestaShop. Questo overhead, tipicamente di 50-200 millisecondi anche per un cache hit, si accumula sotto carico.

Varnish elimina completamente questo overhead. Un cache hit di Varnish viene servito in 1-5 millisecondi. Con traffico elevato, la differenza è drammatica. Un negozio PrestaShop che fatica a gestire 100 utenti simultanei con un modulo FPC può servire migliaia di utenti simultanei con Varnish, perché la stragrande maggioranza delle richieste non raggiunge mai il backend PHP.

Quando i moduli PHP Full Page Cache sono sufficienti

Prima di investire in Varnish, vale la pena capire quando un modulo FPC basato su PHP è sufficiente. Per molti negozi PrestaShop, lo è.

Se il tuo negozio riceve meno di 50.000 visualizzazioni di pagina giornaliere, un modulo FPC ben configurato gestirà il carico senza problemi. La complessità aggiuntiva di Varnish non è giustificata quando il tuo server ha capacità di riserva. Se i tempi di risposta del server con FPC sono costantemente sotto i 200 millisecondi, i tuoi visitatori stanno già ottenendo caricamenti rapidi delle pagine. Il collo di bottiglia a quel punto è probabilmente il rendering frontend (CSS, JavaScript, immagini) piuttosto che il tempo di risposta del server.

I moduli FPC gestiscono alcuni scenari specifici di PrestaShop con più eleganza rispetto a Varnish perché vengono eseguiti all'interno dell'applicazione. Possono verificare se un utente è loggato, se il carrello contiene articoli e se determinati contenuti dinamici necessitano di personalizzazione — tutto all'interno dello stesso processo PHP. Con Varnish, questi controlli devono essere gestiti tramite l'ispezione dei cookie e regole di variazione della cache, il che aggiunge complessità alla configurazione.

Considera Varnish quando il tuo negozio gestisce regolarmente picchi di traffico (vendite flash, campagne marketing, picchi stagionali) che sovraccaricano la tua capacità PHP, quando hai bisogno di tempi di risposta inferiori a 10 ms per ragioni SEO o di esperienza utente, quando il budget per l'hosting è limitato e devi servire più traffico con lo stesso hardware, o quando il tuo negozio serve un'alta percentuale di navigazione anonima (pagine di categoria, pagine prodotto) rispetto all'attività del carrello e del checkout.

Come funziona Varnish: il flusso delle richieste

Comprendere il flusso delle richieste attraverso Varnish è essenziale per configurarlo correttamente con PrestaShop.

Arrivo della richiesta

Quando un visitatore richiede una pagina, la richiesta raggiunge prima Varnish (Varnish è in ascolto sulla porta 80 o 443 se la terminazione SSL è gestita da un proxy frontend). Varnish esamina la richiesta: l'URL, il metodo HTTP, i cookie e gli header.

Ricerca nella cache

Varnish controlla la sua cache alla ricerca di una risposta memorizzata che corrisponda a questa richiesta. La chiave della cache è tipicamente basata sull'URL e su header selezionati. Se una risposta corrispondente esiste e non è scaduta, Varnish la serve direttamente. Questo è un cache hit. La risposta viene inviata al visitatore e il server backend non viene mai contattato.

Cache miss

Se non esiste una risposta cachata corrispondente, Varnish inoltra la richiesta al server backend (Apache o Nginx che esegue PrestaShop). PrestaShop elabora la richiesta normalmente, genera la risposta HTML e la invia a Varnish. Varnish memorizza la risposta nella sua cache (se la risposta è cacheable) e la inoltra al visitatore. Le richieste successive per la stessa pagina verranno servite dalla cache.

Invalidazione della cache

Quando i dati del prodotto cambiano, i prezzi vengono aggiornati o il contenuto viene modificato, la versione in cache diventa obsoleta. Varnish deve essere informato di scartare la vecchia versione cachata in modo che ne recuperi una fresca dal backend. Questa è l'invalidazione della cache, ed è la parte più difficile di qualsiasi sistema di caching da implementare correttamente.

Configurazione VCL per PrestaShop

Varnish Configuration Language (VCL) è un linguaggio specifico di dominio che controlla come Varnish gestisce le richieste. Una configurazione VCL corretta per PrestaShop deve gestire diversi comportamenti specifici di PrestaShop.

Definizione del backend

La definizione del backend indica a Varnish dove inoltrare i cache miss. Per una tipica configurazione PrestaShop dove Apache o Nginx gira sullo stesso server sulla porta 8080:

backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 5s; .first_byte_timeout = 60s; .between_bytes_timeout = 10s; }

I timeout sono importanti. Le pagine PrestaShop possono richiedere diversi secondi per essere generate con cache fredda, specialmente le pagine di categoria con molti prodotti. Impostare first_byte_timeout troppo basso fa sì che Varnish restituisca un errore 503 prima che PrestaShop abbia finito di generare la pagina.

Gestione dei cookie e delle sessioni

I cookie sono la sfida più grande quando si fa caching di PrestaShop con Varnish. PrestaShop imposta diversi cookie per impostazione predefinita, e Varnish tratta qualsiasi richiesta con cookie come non cacheable a meno che non venga istruito diversamente. Se non gestisci i cookie nel tuo VCL, Varnish non cacheerà praticamente nulla.

PrestaShop imposta questi cookie sulla maggior parte delle richieste: il cookie di sessione (tipicamente chiamato PrestaShop-xxxx), i cookie relativi al carrello, i cookie di Google Analytics (_ga, _gid, _gat) e vari cookie di tracciamento da strumenti di marketing. Di questi, solo il cookie di sessione PrestaShop è importante per il comportamento della cache. I cookie di analytics e tracciamento dovrebbero essere rimossi dalla richiesta prima della ricerca nella cache in modo che non impediscano il caching.

Nella subroutine VCL vcl_recv, rimuovi i cookie non essenziali:

sub vcl_recv { # Rimuovi cookie di Google Analytics e altri traccianti set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", ""); # Rimuovi header cookie vuoto if (req.http.Cookie ~ "^\s*$") { unset req.http.Cookie; } }

Decidere cosa cachare

Non tutte le pagine PrestaShop dovrebbero essere cachate. Il VCL deve distinguere tra richieste cacheable e non cacheable.

Cacha sempre: Pagine prodotto per visitatori anonimi, pagine di elenco categorie, pagine CMS (chi siamo, termini, contatti), la homepage, pagine di produttori e fornitori, pagine della sitemap.

Non cachare mai: La pagina del carrello, le pagine del checkout (tutti i passaggi), l'area account cliente (ordini, indirizzi, informazioni personali), le pagine di login e registrazione, qualsiasi pagina per un cliente loggato, richieste POST, richieste AJAX che modificano lo stato (aggiungi al carrello, aggiorna quantità).

La logica VCL per questo tipicamente controlla il percorso URL e la presenza di cookie di sessione:

sub vcl_recv { # Non cachare le richieste POST if (req.method == "POST") { return (pass); } # Non cachare l'area admin if (req.url ~ "^/admin") { return (pass); } # Non cachare checkout e carrello if (req.url ~ "(cart|order|login|my-account|module/)" ) { return (pass); } # Non cachare se il cliente ha articoli nel carrello if (req.http.Cookie ~ "PrestaShop-") { return (pass); } return (hash); }

Impostare la durata della cache

Nella subroutine vcl_backend_response, controlli per quanto tempo Varnish cacha ogni risposta. PrestaShop invia header Cache-Control che tipicamente indicano no-cache o private perché presume che ogni risposta possa contenere contenuto personalizzato. Devi sovrascriverli per le pagine che sai essere sicure da cachare:

sub vcl_backend_response { # Cacha pagine prodotto e categoria per 1 ora if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") { set beresp.ttl = 1h; unset beresp.http.Set-Cookie; } # Cacha asset statici per 1 giorno if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") { set beresp.ttl = 1d; unset beresp.http.Set-Cookie; } }

Rimuovere Set-Cookie dalle risposte cachate è critico. Se una risposta cachata include un header Set-Cookie, Varnish non la cacheerà per impostazione predefinita, e anche se forzato a cachare, imposterebbe lo stesso cookie di sessione per ogni visitatore, causando session hijacking.

Invalidazione della cache con richieste PURGE

Quando il prezzo di un prodotto cambia, viene aggiunto un nuovo prodotto o il contenuto viene aggiornato, la versione cachata deve essere invalidata. Varnish supporta le richieste PURGE: un metodo HTTP speciale che indica a Varnish di rimuovere un URL specifico dalla sua cache.

Configurare il supporto PURGE

Aggiungi la gestione PURGE al tuo VCL:

acl purge { "127.0.0.1"; "localhost"; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } return (purge); } }

L'ACL limita le richieste PURGE a localhost, impedendo agli utenti esterni di svuotare la tua cache.

Attivare i purge da PrestaShop

PrestaShop non invia nativamente richieste PURGE. Hai bisogno di un modulo o di un hook personalizzato che rilevi quando il contenuto cacheable cambia e invii una richiesta PURGE a Varnish. Il modulo si aggancia agli eventi PrestaShop come actionProductUpdate, actionCategoryUpdate e actionCMSPageUpdate. Quando questi eventi si attivano, il modulo invia una richiesta HTTP PURGE all'URL corrispondente sul server Varnish.

Per un aggiornamento di prodotto, il modulo dovrebbe purgare l'URL del prodotto, gli URL delle categorie a cui appartiene il prodotto (perché le pagine elenco delle categorie mostrano prezzi e disponibilità dei prodotti) e potenzialmente la homepage se mostra prodotti in evidenza. Questa cascata di purge è necessaria per evitare che dati obsoleti appaiano in qualsiasi punto del sito.

Invalidazione basata su BAN

Per scenari in cui molti URL devono essere purgati contemporaneamente (un aggiornamento prezzi a livello di sito, un cambio di design, un nuovo banner promozionale), le singole richieste PURGE sono impraticabili. Varnish supporta i ban, che sono regole di invalidazione basate su pattern. Un ban indica a Varnish di scartare qualsiasi oggetto cachato che corrisponda a un pattern:

sub vcl_recv { if (req.method == "BAN") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } ban("req.url ~ " + req.http.X-Ban-Pattern); return (synth(200, "Banned.")); } }

Inviare una richiesta BAN con l'header X-Ban-Pattern: /category/ invaliderebbe tutte le pagine di categoria cachate in un'unica operazione.

Edge Side Includes (ESI) per blocchi dinamici

Molte pagine PrestaShop contengono un mix di contenuto statico e dinamico. L'elenco prodotti in una pagina di categoria è lo stesso per ogni visitatore, ma l'header che mostra il conteggio del carrello è personalizzato. Senza ESI, non puoi cachare la pagina affatto perché l'header dinamico rende l'intera risposta specifica per il visitatore.

Gli Edge Side Includes risolvono questo problema permettendo di contrassegnare sezioni della pagina come frammenti recuperati separatamente. Varnish assembla la pagina finale da frammenti cachati e non cachati.

Come funziona ESI

Nel tuo template Smarty, invece di renderizzare direttamente il widget del carrello, includi un tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Quando Varnish elabora la pagina cachata, incontra il tag ESI e effettua una richiesta separata al backend per quel frammento. Il corpo principale della pagina viene servito dalla cache, mentre il widget del carrello viene recuperato fresco da PrestaShop. La risposta assemblata include sia il corpo cachato che il widget del carrello aggiornato.

Abilita l'elaborazione ESI nel tuo VCL:

sub vcl_backend_response { set beresp.do_esi = true; }

Considerazioni ESI per PrestaShop

Implementare ESI richiede la modifica dei template PrestaShop per separare il contenuto dinamico in frammenti compatibili con ESI. Ogni frammento necessita del proprio endpoint URL che restituisce solo l'HTML per quel blocco. I frammenti che sono tipicamente dinamici e necessitano di trattamento ESI includono il widget riepilogo carrello (conteggio articoli, totale), il saluto al cliente ("Ciao, Giovanni"), eventuali raccomandazioni di prodotti personalizzate, il link login/logout e i prodotti visualizzati di recente.

Lo sforzo richiesto per implementare ESI correttamente è significativo. Ogni frammento dinamico necessita di un controller dedicato, i template richiedono ristrutturazione e le regole di caching per ogni frammento necessitano di regolazione individuale. Questo è uno dei motivi per cui Varnish è considerato un'ottimizzazione avanzata — funziona meglio quando l'applicazione è progettata tenendolo a mente.

Controlli di salute del backend

Varnish può monitorare lo stato del tuo server backend e agire quando diventa non disponibile. Questo viene configurato nella definizione del backend:

backend default { .host = "127.0.0.1"; .port = "8080"; .probe = { .url = "/ping.php"; .timeout = 2s; .interval = 5s; .window = 5; .threshold = 3; } }

Varnish invia una richiesta a /ping.php ogni 5 secondi. Se 3 degli ultimi 5 controlli falliscono, Varnish contrassegna il backend come malato. Mentre il backend è malato, Varnish può servire contenuto cachato obsoleto (modalità grace) invece di restituire errori ai visitatori. Questo significa che il tuo negozio rimane parzialmente disponibile anche quando il backend PHP va in crash o si riavvia.

La configurazione della modalità grace determina per quanto tempo Varnish servirà contenuto obsoleto:

sub vcl_backend_response { set beresp.grace = 6h; }

Con un grace di 6 ore, se il tuo backend va giù, i visitatori vedranno pagine cachate (anche se vecchie di 6 ore) invece di pagine di errore. I prezzi dei prodotti potrebbero essere leggermente non aggiornati, ma il negozio resta funzionante mentre risolvi il problema del backend.

Benchmark delle prestazioni

La differenza di prestazioni tra nessuna cache, PHP FPC e Varnish è sostanziale e misurabile.

Senza cache (PrestaShop base): Una tipica pagina prodotto PrestaShop richiede 200-800 millisecondi per essere generata, a seconda dell'hardware del server, del numero di moduli caricati e del numero di query al database. Sotto carico, i tempi di risposta aumentano perché i worker PHP sono saturi. Un singolo server può gestire 20-50 utenti simultanei prima che i tempi di risposta diventino inaccettabili.

Modulo PHP FPC: I cache hit vengono serviti in 30-100 millisecondi perché PHP si avvia comunque e il framework si inizializza parzialmente. Sotto carico, le prestazioni sono molto migliori perché le risposte cachate richiedono un tempo di elaborazione PHP minimo. Un singolo server può gestire 200-500 utenti simultanei a seconda della configurazione. I cache miss richiedono comunque il tempo completo di rendering.

Varnish: I cache hit vengono serviti in 1-5 millisecondi. Sotto carico, Varnish stesso può gestire migliaia di connessioni simultanee perché è scritto in C ed è progettato specificamente per questo tipo di carico. Il server backend gestisce solo i cache miss, che sono una piccola frazione del traffico totale in un sistema correttamente configurato. Lo stesso hardware che fatica con 50 utenti simultanei senza caching può gestirne 5.000 o più con Varnish.

Questi numeri illustrano perché Varnish vale la complessità di configurazione per i negozi ad alto traffico. Il miglioramento delle prestazioni non è incrementale — è di un ordine di grandezza.

Requisiti di hosting

Varnish ha requisiti di hosting specifici che non tutti gli ambienti di hosting PrestaShop possono soddisfare.

Accesso al server

Hai bisogno dell'accesso root per installare e configurare Varnish. I piani di hosting condiviso non supportano Varnish perché richiede un proprio processo in ascolto su una porta che intercetta tutto il traffico HTTP. Hai bisogno di un VPS, server dedicato o istanza cloud dove controlli l'intero stack del server.

Memoria

Varnish memorizza la sua cache nella RAM. La quantità di RAM necessaria dipende dal numero di pagine uniche nel tuo catalogo e dalla dimensione di ogni risposta cachata. Una formula approssimativa: il numero di pagine cacheabili moltiplicato per la dimensione media della pagina fornisce la dimensione minima della cache. Un negozio con 5.000 prodotti, 200 categorie e una dimensione media della pagina di 50KB necessita di circa 260MB di cache RAM. Aggiungi l'overhead per Varnish stesso e dovresti allocare almeno 512MB. Per cataloghi più grandi, 1-2GB è la norma.

Configurazione delle porte

In una configurazione standard, Varnish è in ascolto sulla porta 80 (la porta HTTP predefinita) e inoltra i cache miss al server web su una porta diversa (comunemente 8080). Questo significa che devi riconfigurare Apache o Nginx per ascoltare sulla porta 8080 invece che sulla 80. Se usi HTTPS (e dovresti), tipicamente metti Nginx davanti a Varnish per gestire la terminazione SSL: Nginx sulla porta 443 termina SSL e inoltra a Varnish sulla porta 80, che inoltra i cache miss ad Apache o PHP-FPM sulla porta 8080.

Esempio di configurazione Docker

Eseguire Varnish in Docker insieme a un container PrestaShop è un modo pulito per aggiungere Varnish a una configurazione esistente senza modificare il sistema host.

Configurazione Docker Compose

Una configurazione Docker Compose di base con Varnish, Nginx per SSL e PrestaShop:

services: varnish: image: varnish:7.4 ports: - "80:80" volumes: - ./varnish/default.vcl:/etc/varnish/default.vcl:ro environment: - VARNISH_SIZE=512m depends_on: - prestashop prestashop: image: prestashop/prestashop:8 expose: - "80" environment: - DB_SERVER=db db: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORD=secretpassword - MYSQL_DATABASE=prestashop

In questa configurazione, Varnish è il punto di ingresso sulla porta 80. Il container PrestaShop non espone la sua porta all'host, solo alla rete Docker. L'host del backend VCL sarebbe prestashop (il nome del servizio Docker) sulla porta 80.

VCL per Docker

La definizione del backend VCL per Docker usa il nome del servizio invece di localhost:

backend default { .host = "prestashop"; .port = "80"; }

Il DNS interno di Docker risolve il nome del servizio nell'IP del container. Il resto della configurazione VCL rimane lo stesso di una configurazione senza Docker.

Storage della cache in Docker

Per impostazione predefinita, l'immagine Docker di Varnish usa lo storage in memoria (malloc), che è ideale per le prestazioni. La variabile d'ambiente VARNISH_SIZE controlla quanta memoria Varnish alloca per la sua cache. Imposta questo valore su uno che rientri nei limiti di memoria del tuo container lasciando spazio per il processo Varnish stesso.

Per una cache persistente che sopravviva ai riavvii del container, puoi usare lo storage basato su file montando un volume, ma è raramente necessario. La cache si scalda rapidamente (entro pochi minuti dalla ricezione del traffico) e lo storage su file è più lento di quello in memoria.

Monitoraggio delle prestazioni di Varnish

Varnish fornisce strumenti integrati per monitorare le prestazioni della cache.

Il comando varnishstat mostra statistiche in tempo reale incluso il tasso di hit della cache, le connessioni al backend e l'utilizzo della memoria. La metrica più importante è il tasso di hit, che dovrebbe essere dell'85% o superiore per una configurazione ben configurata. Se il tuo tasso di hit è sotto il 70%, rivedi le regole VCL perché troppe richieste passano al backend.

Il comando varnishlog mostra log dettagliati per ogni richiesta, che sono inestimabili per il debug del motivo per cui specifiche richieste non vengono cachate. Puoi filtrare per pattern URL, codice di risposta o stato di cache hit/miss.

Il comando varnishtop mostra una lista classificata delle voci di log più frequenti, aiutandoti a identificare pattern nei cache miss o negli errori.

Errori comuni

Dimenticare di rimuovere i cookie

La configurazione errata più comune di Varnish con PrestaShop è non rimuovere i cookie di analytics e tracciamento. Questi cookie sono presenti in praticamente ogni richiesta e rendono ogni richiesta unica dal punto di vista di Varnish, risultando in un tasso di hit dello 0%. Rimuovi sempre i cookie che non ti servono per la variazione della cache.

Cachare contenuto personalizzato

Se il tuo VCL è troppo aggressivo, cacherà pagine che contengono contenuto personalizzato (saluto dell'utente loggato, contenuto del carrello) e le servirà ad altri visitatori. Questo causa seri problemi di usabilità e potenziali problemi di privacy. Passa sempre le richieste che contengono cookie di sessione al backend.

Non invalidare ai cambi di contenuto

Senza un meccanismo di purging adeguato, le modifiche al contenuto nel back office non saranno visibili fino alla scadenza naturale delle pagine cachate. Per un negozio con cambiamenti attivi dell'inventario, questo significa che i visitatori potrebbero vedere prodotti esauriti, prezzi sbagliati o descrizioni obsolete. Implementa il supporto PURGE o BAN e integralo con gli hook di aggiornamento di PrestaShop.

Ignorare HTTPS

Varnish non gestisce SSL nativamente. Devi mettere un proxy di terminazione SSL (Nginx, HAProxy o un load balancer cloud) davanti a Varnish. Non pianificare questo nella tua architettura porta a problemi di contenuto misto (mixed content), loop di redirect o l'impossibilità di servire traffico HTTPS.

Varnish è adatto al tuo negozio?

Varnish è uno strumento potente, ma non è la scelta giusta per ogni negozio PrestaShop. Aggiunge complessità operativa: un altro servizio da monitorare, un altro linguaggio di configurazione da imparare, un altro livello nel tuo processo di debug. I benefici sono chiari e misurabili per i negozi che ne hanno bisogno, ma comportano un costo in termini di tempo di setup, manutenzione e difficoltà di troubleshooting.

Se il tuo negozio serve meno di 50.000 visualizzazioni di pagina al giorno e il tuo server gestisce il carico comodamente con un modulo FPC, Varnish è complessità non necessaria. Se il tuo negozio affronta regolarmente picchi di traffico che sovraccaricano il server, serve un alto volume di traffico di navigazione anonima o necessita dei tempi di risposta più rapidi possibili per SEO o esperienza utente, Varnish fornisce un livello di prestazioni che nessuna soluzione di caching basata su PHP può eguagliare.

Inizia con una corretta ottimizzazione di PrestaShop (ottimizzazione delle query, audit dei moduli, PHP OPcache, ottimizzazione delle immagini) e un modulo FPC. Se queste ottimizzazioni non bastano, Varnish è il passo successivo nella scala del performance scaling.

Leggi la risposta completa

Come PrestaShop gestisce le immagini dei prodotti

Ogni immagine caricata su PrestaShop passa attraverso una pipeline di elaborazione. Quando aggiungi un'immagine prodotto, il sistema memorizza il file originale e poi genera diverse versioni ridimensionate chiamate miniature (thumbnail). Ogni miniatura corrisponde a un tipo di immagine definito nel back office sotto Design > Impostazioni immagini. Questi tipi di immagine specificano dimensioni esatte in pixel e sono legati a contesti specifici: elenchi prodotti, pagine prodotto, anteprime carrello, intestazioni categorie, loghi produttori e altro.

PrestaShop memorizza le immagini nella directory /img/. In PrestaShop 1.7 e 8.x, le immagini dei prodotti sono organizzate usando una struttura di directory basata sull'ID dell'immagine. Ad esempio, un'immagine con ID 1234 è memorizzata in /img/p/1/2/3/4/. All'interno di quella directory, troverai l'immagine originale (denominata per ID, come 1234.jpg) e tutte le miniature generate (come 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

La convenzione di denominazione segue il pattern: {image_id}-{image_type_name}.{extension}. Questo significa che ogni tipo di immagine che definisci crea un file aggiuntivo per ogni immagine prodotto nel tuo catalogo. Un negozio con 5.000 immagini prodotto e 8 tipi di immagine avrà circa 45.000 file di immagini (5.000 originali più 5.000 per 8 miniature). Questa scala è importante quando devi rigenerarle.

Comprendere i tipi di immagine

I tipi di immagine sono definiti nella tabella del database ps_image_type e gestiti tramite il back office. Ogni tipo di immagine ha un nome, larghezza, altezza e flag che indicano a quali tipi di entità si applica (prodotti, categorie, produttori, fornitori, negozi). L'installazione predefinita di PrestaShop include diversi tipi di immagine:

cart_default è tipicamente 125x125 pixel, usato nel carrello e nel mini carrello. small_default è circa 98x98 pixel, usato negli elenchi prodotti su alcuni temi. medium_default è circa 452x452 pixel, usato per le miniature dei prodotti nella pagina prodotto. home_default è circa 250x250 pixel, usato nella homepage e negli elenchi categorie. large_default è circa 800x800 pixel, usato come immagine principale del prodotto nella pagina prodotto.

I temi possono definire i propri requisiti per i tipi di immagine. Quando installi un nuovo tema, tipicamente registra i suoi tipi di immagine preferiti durante l'installazione. Il punto critico è che i file immagine effettivi su disco devono corrispondere a ciò che il tema si aspetta. Se il tema richiede home_default a 340x340 ma i tuoi file immagine sono stati generati a 250x250 perché usavi un tema diverso in precedenza, ogni elenco prodotti mostrerà immagini con dimensioni errate.

Quando la rigenerazione delle immagini è necessaria

Diverse situazioni richiedono una rigenerazione completa o parziale delle miniature. Comprendere quando è veramente necessaria ti risparmia l'esecuzione di un processo che può richiedere ore su cataloghi di grandi dimensioni.

Cambio tema

Questa è la ragione più comune. Temi diversi richiedono dimensioni immagine diverse. Quando passi da un tema a un altro, i template del nuovo tema fanno riferimento a tipi di immagine con dimensioni specifiche. Se quelle dimensioni non corrispondono ai file miniatura esistenti, le immagini appaiono stirate, ritagliate in modo errato o sfocate. Dopo aver installato un nuovo tema, controlla sempre i suoi requisiti per i tipi di immagine e rigenera le miniature per farle corrispondere.

Modifiche alle dimensioni del tipo di immagine

Se modifichi la larghezza o l'altezza di un tipo di immagine esistente tramite Design > Impostazioni immagini, la modifica influisce solo sulla definizione nel database. Tutti i file miniatura esistenti su disco mantengono le loro vecchie dimensioni. Devi rigenerare le miniature per il tipo di immagine modificato per applicare le nuove dimensioni alle immagini esistenti.

Aggiunta di un nuovo tipo di immagine

Quando crei un nuovo tipo di immagine, non esistono ancora file miniatura per esso. Se un template fa riferimento a questo nuovo tipo di immagine, mostrerà link immagine rotti fino a quando non rigeneri. Il processo di rigenerazione crea i file miniatura mancanti per ogni immagine esistente.

Problemi di qualità delle immagini

Se cambi l'impostazione della qualità di compressione JPEG in PrestaShop (che si trova in Prestazioni > Impostazioni immagini o nella sezione configurazione immagini a seconda della versione), le miniature esistenti sono state generate con la vecchia impostazione di qualità. La rigenerazione applica il nuovo livello di qualità a tutte le miniature.

Dopo una migrazione o spostamento del server

A volte durante la migrazione, i file miniatura vengono persi o corrotti mentre le immagini originali sopravvivono. Se le immagini dei prodotti appaiono rotte ma gli originali esistono nelle directory previste, la rigenerazione ricrea tutte le miniature dagli originali.

Abilitazione del formato WebP

PrestaShop 8.x ha introdotto il supporto WebP per le immagini dei prodotti. Quando abiliti la generazione WebP, le immagini esistenti non ottengono automaticamente le varianti WebP. Devi rigenerare le miniature per creare le versioni .webp accanto ai file JPEG o PNG esistenti.

Rigenerazione tramite il pannello di amministrazione

PrestaShop fornisce uno strumento di rigenerazione integrato nel back office sotto Design > Impostazioni immagini (o Preferenze > Immagini nelle versioni precedenti). In fondo alla pagina troverai la sezione di rigenerazione.

Opzioni disponibili

Puoi scegliere di cancellare le immagini precedenti prima della rigenerazione. Quando abilitato, PrestaShop elimina tutte le miniature esistenti prima di crearne di nuove. Questo è utile quando vuoi rimuovere miniature per tipi di immagine che non esistono più, ma significa che tutte le immagini saranno non disponibili durante il processo di rigenerazione. Quando disabilitato, PrestaShop sovrascrive le miniature esistenti e crea quelle mancanti senza eliminare nulla prima.

Puoi selezionare quali tipi di entità rigenerare: prodotti, categorie, produttori, fornitori o negozi. Se hai cambiato solo le dimensioni delle immagini dei prodotti, non c'è bisogno di rigenerare le immagini delle categorie o dei produttori.

Limitazioni dell'approccio tramite pannello di amministrazione

La rigenerazione tramite pannello di amministrazione viene eseguita come una richiesta web. Questo crea diversi problemi per cataloghi di grandi dimensioni. I server web hanno limiti di tempo di esecuzione, tipicamente da 30 a 300 secondi a seconda della configurazione. Un negozio con 10.000 immagini di prodotti e 8 tipi di immagine deve generare 80.000 file miniatura. Anche a un ritmo generoso di 10 immagini al secondo, ci vogliono più di due ore. La maggior parte dei server web terminerà il processo molto prima che finisca.

Si applicano anche i limiti di memoria. Ogni immagine deve essere caricata in memoria, ridimensionata usando GD o ImageMagick e salvata. Le immagini originali ad alta risoluzione possono consumare da 20 a 50 MB di memoria ciascuna durante l'elaborazione. Il limite di memoria predefinito di PHP di 128 MB o 256 MB può essere esaurito rapidamente, specialmente quando si elaborano immagini in sequenza senza una corretta pulizia della memoria.

Se il processo viene interrotto da un timeout o errore di memoria, ti ritrovi con un catalogo parzialmente rigenerato. Alcuni prodotti hanno le nuove miniature, altri hanno quelle vecchie e alcuni potrebbero non averne affatto. Questo stato incoerente è peggiore del problema originale.

Rigenerazione CLI per cataloghi di grandi dimensioni

Per negozi con più di qualche centinaio di prodotti, la rigenerazione da riga di comando è fortemente raccomandata. Bypassa i limiti di timeout del server web e può essere configurata con limiti di memoria più alti.

Utilizzo della console PrestaShop

PrestaShop 1.7.5 e versioni successive includono una console Symfony. Puoi rigenerare le miniature usando:

php bin/console prestashop:image:regenerate

Questo comando accetta diverse opzioni. Per rigenerare solo tipi di immagine specifici, usa il flag --image-type seguito dal nome del tipo di immagine. Per elaborare solo prodotti, categorie o altri tipi di entità specifici, usa il flag --entity. Il flag --format ti permette di specificare quali formati di output generare (jpg, png, webp).

Esegui il comando dalla directory root di PrestaShop. Se stai usando Docker, eseguilo all'interno del container:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

Il flag -u www-data assicura che i file generati siano di proprietà dell'utente del server web. Eseguire come root crea file che il server web non può servire o modificare successivamente.

Configurazione di memoria e tempo

Per l'esecuzione CLI, puoi aumentare i limiti PHP direttamente nel comando:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Impostare max_execution_time=0 rimuove completamente il limite di tempo, e 512 MB di memoria sono sufficienti per la maggior parte dei cataloghi. Per negozi con originali a risoluzione estremamente alta (4000x4000 pixel o più), potresti aver bisogno di 1 GB o più.

Approccio di rigenerazione personalizzato

Per cataloghi molto grandi (50.000 o più immagini), anche il comando della console può essere lento o problematico. Un approccio PHP personalizzato ti permette di elaborare le immagini in lotti con tracciamento del progresso, gestione degli errori e la possibilità di riprendere dopo un'interruzione.

L'approccio consiste nell'interrogare il database per tutti i record immagine, iterare attraverso di essi in lotti di 100 o 200, generare miniature per ogni immagine e registrare il progresso. Se il processo viene interrotto, puoi riprenderlo da dove si era fermato controllando quali miniature esistono già.

Un approccio a lotti permette anche di distribuire la rigenerazione su più esecuzioni durante le ore di minor traffico, evitando l'impatto sulle prestazioni del negozio attivo.

Generazione WebP durante la rigenerazione

WebP è un formato immagine moderno che fornisce dimensioni di file significativamente più piccole rispetto al JPEG a qualità comparabile. PrestaShop 8.x può generare versioni WebP delle miniature durante il processo di rigenerazione.

Abilitare il supporto WebP

Prima della rigenerazione, abilita WebP nella configurazione di PrestaShop. In PrestaShop 8.x, questa opzione si trova nelle impostazioni immagini. Quando abilitata, il processo di rigenerazione crea sia la miniatura tradizionale JPEG/PNG che una versione .webp per ogni tipo di immagine.

Requisiti del server

La generazione WebP richiede l'estensione GD compilata con supporto WebP (--with-webp) o l'estensione ImageMagick con delegati WebP. Puoi verificare il supporto GD con phpinfo() o gd_info(). Cerca WebP Support nell'output. Se il supporto WebP è mancante, il processo di rigenerazione salta silenziosamente la creazione WebP senza produrre errori.

Considerazioni sullo spazio su disco

I file WebP sono tipicamente dal 25 al 35 percento più piccoli dei file JPEG equivalenti, ma stai memorizzando entrambi i formati. Un negozio con 40.000 miniature JPEG che occupano 2 GB di spazio su disco avrà bisogno di circa 3,4 GB in totale dopo la generazione WebP (i 2 GB originali più circa 1,4 GB di file WebP). Pianifica di conseguenza il tuo spazio su disco prima di avviare una rigenerazione completa.

Servire WebP ai browser

Generare file WebP è solo metà della soluzione. Il tuo tema e server devono essere configurati per servire WebP ai browser che lo supportano, con fallback su JPEG/PNG per i browser che non lo fanno. Questo è tipicamente gestito tramite elementi <picture> nei template del tema o tramite la negoziazione del contenuto lato server usando l'header Accept.

In Apache, puoi aggiungere regole di rewrite che verificano il supporto WebP e servono la versione WebP quando disponibile. In Nginx, la direttiva try_files può verificare se esiste una versione .webp dell'immagine richiesta e servirla se l'header Accept del browser include image/webp.

Impatto sulle prestazioni e mitigazione

La rigenerazione delle immagini è intensiva per la CPU e pesante per l'I/O. Su un negozio attivo, può degradare significativamente le prestazioni se non gestita con attenzione.

Impatto sulla CPU

Ogni operazione di ridimensionamento immagine richiede il caricamento dell'originale in memoria, l'esecuzione dell'algoritmo di ridimensionamento, l'applicazione delle impostazioni di qualità/compressione e la scrittura del risultato su disco. L'operazione di ridimensionamento stessa è computazionalmente costosa, specialmente per immagini grandi ridotte a miniature piccole. Su un ambiente di hosting condiviso, questo può saturare la CPU e rallentare l'intero negozio.

Impatto sull'I/O

La rigenerazione legge ogni immagine originale e scrive diversi file miniatura. Su dischi rigidi tradizionali, questo crea un carico I/O significativo. Su storage SSD, l'impatto è molto minore ma comunque percepibile su larga scala. Il pattern I/O è particolarmente sfavorevole per i dischi rotanti perché comporta letture casuali (originali sparsi tra le directory) combinate con scritture sequenziali (miniature nelle stesse directory).

Eseguire la rigenerazione nelle ore di minor traffico

Programma la rigenerazione nel periodo di traffico più basso. Per i negozi europei, questo è tipicamente tra le 2:00 e le 6:00. Per negozi con traffico globale, potrebbe non esserci un vero momento di basso traffico, ma puoi identificare punti relativamente bassi dai tuoi dati di analytics.

Utilizzo di nice e ionice

Su server Linux, puoi ridurre la priorità del processo di rigenerazione in modo che non privi altri processi delle risorse. Il comando nice abbassa la priorità CPU, e ionice abbassa la priorità I/O:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Un valore nice di 19 è la priorità più bassa. La classe ionice 3 è la classe idle, il che significa che il processo ottiene tempo I/O solo quando nient'altro ne ha bisogno. Questo riduce drasticamente l'impatto sul negozio attivo ma rende la rigenerazione più lunga.

Scaling temporaneo

Se sei su un server cloud, considera di aumentare temporaneamente le risorse del server (più core CPU, più RAM, storage più veloce) per la durata della rigenerazione, per poi ridimensionare. Il costo extra di qualche ora di risorse di livello superiore è generalmente minimo rispetto all'impatto di una rigenerazione lenta e multi-giornaliera sulle prestazioni del negozio.

Evitare i timeout durante la rigenerazione

I timeout sono il problema più comune con la rigenerazione delle immagini. Ecco le impostazioni e configurazioni specifiche che li prevengono.

Configurazione PHP

La direttiva max_execution_time limita la durata di esecuzione di un processo PHP. Per l'esecuzione CLI, tipicamente è già impostata a 0 (illimitata), ma verifica controllando php -i | grep max_execution_time. Per la rigenerazione web tramite il pannello di amministrazione, aumenta questo valore nel tuo php.ini o .htaccess:

php_value max_execution_time 7200

Aumenta anche max_input_time se usi il pannello di amministrazione, poiché il timeout di invio del form è separato dal timeout di esecuzione:

php_value max_input_time 7200

Timeout del server web

La direttiva Timeout di Apache e proxy_read_timeout / fastcgi_read_timeout di Nginx possono terminare richieste di lunga durata anche se PHP stesso non è andato in timeout. Per Apache: Timeout 7200. Per Nginx, aggiungi al tuo blocco server: fastcgi_read_timeout 7200; o proxy_read_timeout 7200;.

Configurazione PHP-FPM

Se usi PHP-FPM (come la maggior parte delle configurazioni moderne), il request_terminate_timeout nella configurazione del pool può anche terminare processi di lunga durata. Impostalo a 0 per disabilitare il timeout, o adattalo al tempo massimo di esecuzione desiderato:

request_terminate_timeout = 7200

Timeout di Cloudflare e CDN

Se il tuo negozio è dietro Cloudflare o un altro CDN, il CDN ha il proprio timeout delle richieste (il piano gratuito di Cloudflare ha un timeout di 100 secondi). Questo rende la rigenerazione tramite pannello di amministrazione dietro un CDN effettivamente impossibile. Devi usare la rigenerazione CLI, bypassare il CDN per l'accesso admin, o usare una soluzione che elabori le immagini in modo asincrono.

Strategie di rigenerazione incrementale

La rigenerazione completa elabora ogni immagine nel catalogo. Per negozi con decine di migliaia di immagini, questo può richiedere molte ore. Gli approcci incrementali elaborano solo le immagini che necessitano effettivamente di nuove miniature.

Rigenerazione selettiva del tipo di immagine

Se hai aggiunto o modificato solo un tipo di immagine, non devi rigenerare tutti i tipi. Usa l'opzione --image-type nel comando della console per mirare solo al tipo di immagine specifico che è cambiato. Questo riduce il lavoro a un ottavo (o qualunque frazione dei tuoi tipi di immagine totali) di una rigenerazione completa.

Elaborazione basata sulla data

Se devi rigenerare le miniature solo per prodotti aggiunti di recente (ad esempio, dopo aver risolto un problema di elaborazione immagini), puoi interrogare il database per le immagini aggiunte dopo una data specifica ed elaborare solo quelle. La tabella ps_image non ha una colonna data per impostazione predefinita, ma la tabella associata ps_product ha i campi date_add e date_upd che possono essere usati per identificare i prodotti modificati di recente.

Rilevamento delle miniature mancanti

Invece di rigenerare tutto, scansiona le directory delle immagini per trovare immagini a cui mancano miniature specifiche e rigenera solo quelle. Questo è l'approccio più veloce quando hai aggiunto un nuovo tipo di immagine o quando una rigenerazione parziale è stata interrotta.

La logica è semplice: per ogni ID immagine nel database, verifica se il file miniatura previsto esiste su disco. Se non esiste, rigenera solo quella miniatura. Questo trasforma una rigenerazione completa di diverse ore in un processo mirato che potrebbe richiedere minuti.

Elaborazione parallela

Per cataloghi molto grandi, puoi dividere l'intervallo di ID immagine in blocchi ed elaborarli in parallelo usando più processi PHP. Ad esempio, un processo gestisce gli ID immagine da 1 a 10000, un altro da 10001 a 20000, e così via. Ogni processo funziona indipendentemente, e il throughput combinato è approssimativamente proporzionale al numero di processi paralleli (limitato dai core CPU e dalla larghezza di banda I/O).

Fai attenzione con l'elaborazione parallela e l'I/O disco. Eseguire troppi processi contemporaneamente su un disco rigido tradizionale causerà contesa I/O e rallenterà effettivamente le cose. Su storage SSD, da 4 a 8 processi paralleli funzionano tipicamente bene.

Considerazioni sul formato delle immagini

PrestaShop supporta JPEG, PNG e GIF come formati sorgente e può generare miniature in questi formati più WebP. Il formato sorgente influenza il comportamento della rigenerazione.

Immagini JPEG

JPEG è il formato più comune per le foto dei prodotti. Supporta la compressione lossy, il che significa che ogni volta che un JPEG viene salvato, si perde un po' di qualità. Questo è il motivo per cui rigenerare le miniature dagli upload originali produce risultati migliori rispetto alla rigenerazione da miniature precedentemente ridimensionate. Assicurati sempre di lavorare dall'immagine originale caricata, non da una miniatura precedentemente generata.

Immagini PNG

PNG supporta la trasparenza e la compressione lossless. Se le tue immagini prodotto usano sfondi trasparenti, le miniature PNG preservano quella trasparenza. Tuttavia, i file PNG sono tipicamente molto più grandi dei file JPEG. Considera se hai realmente bisogno della trasparenza. Se no, convertire le immagini prodotto PNG in JPEG durante la rigenerazione può ridurre significativamente lo spazio su disco e migliorare i tempi di caricamento delle pagine.

Gestione GIF

PrestaShop può accettare upload GIF, ma le miniature generate da sorgenti GIF sono statiche (l'animazione non viene preservata). Se hai immagini prodotto GIF animate, sappi che la rigenerazione produce miniature statiche dal primo frame.

Verifica post-rigenerazione

Dopo il completamento della rigenerazione, verifica i risultati prima di presumere che tutto sia corretto.

Controllo visivo della qualità delle immagini

Apri diverse pagine prodotto e ispeziona le immagini visivamente. Verifica che le miniature siano nitide, correttamente proporzionate e non stirate o pixelate. Presta particolare attenzione alle immagini che erano originalmente piccole (vicine o più piccole delle dimensioni della miniatura), poiché queste hanno più probabilità di mostrare problemi di qualità quando ingrandite.

Verifica del conteggio dei file

Confronta il numero di miniature generate con le aspettative. Se hai 5.000 immagini prodotto e 8 tipi di immagine, dovresti avere circa 40.000 file miniatura (più gli originali e potenzialmente le varianti WebP). Un conteggio significativamente inferiore indica che il processo di rigenerazione è stato interrotto o ha incontrato errori su alcune immagini.

Verifica dei permessi dei file

Verifica che i file rigenerati siano di proprietà dell'utente del server web (tipicamente www-data su Debian/Ubuntu o apache su CentOS). Se hai eseguito la rigenerazione come root, i file potrebbero non essere leggibili dal server web, causando immagini rotte nel frontend. Correggi con: chown -R www-data:www-data img/p/.

Pulizia della cache

Dopo la rigenerazione, pulisci tutte le cache. Questo include la cache interna di PrestaShop (Parametri avanzati > Prestazioni), qualsiasi cache opcode (OPcache), e qualsiasi cache CDN o reverse proxy. Le vecchie pagine cachate potrebbero ancora fare riferimento a vecchi URL o dimensioni delle immagini. Se usi un modulo che genera sprite CSS o immagini inline, rigenera anche quelli.

Se il tuo negozio è dietro Cloudflare, purga la cache per il percorso /img/ o fai un purge completo della cache. Cloudflare cacha le immagini aggressivamente, e i visitatori potrebbero vedere vecchie miniature fino alla scadenza o al purge della cache CDN.

Risoluzione dei problemi comuni di rigenerazione

Miniature nere o corrotte

Questo indica solitamente un problema con la libreria GD. L'estensione GD potrebbe non supportare il formato sorgente (ad esempio, GD compilato senza supporto JPEG). Verifica le capacità di GD con gd_info(). Un'altra causa è la memoria insufficiente: se PHP non può allocare abbastanza memoria per caricare l'immagine originale, GD potrebbe produrre un'immagine nera invece di generare un errore.

Dimensioni errate nelle miniature generate

Se le miniature hanno dimensioni inaspettate, controlla le definizioni dei tipi di immagine nel database. Il pannello di amministrazione potrebbe mostrare un valore mentre il database ne contiene un altro (questo può succedere dopo un import fallito o una modifica manuale del database). Interroga direttamente: SELECT * FROM ps_image_type WHERE name = 'home_default';

La rigenerazione si blocca senza progresso

Un processo di rigenerazione bloccato solitamente significa che ha incontrato un'immagine molto grande che ha esaurito la memoria disponibile. Controlla il log degli errori PHP per errori di allocazione memoria. La soluzione è aumentare il limite di memoria o pre-elaborare le immagini sorgente problematiche per ridurne la risoluzione prima della rigenerazione.

Errori di permesso negato

Se la rigenerazione riporta errori di permesso, il processo PHP non può scrivere nelle directory delle immagini. Questo accade comunemente in ambienti Docker dove i volumi bind-mounted hanno proprietà diverse all'interno e all'esterno del container. Assicurati che l'utente che esegue il comando di rigenerazione abbia accesso in scrittura all'intero albero della directory /img/.

Riepilogo

La rigenerazione delle immagini è un'attività di manutenzione che ogni proprietario di negozio PrestaShop incontra, solitamente durante un cambio tema o quando ottimizza le impostazioni delle immagini. Per cataloghi piccoli (sotto 500 prodotti), lo strumento del pannello di amministrazione funziona adeguatamente. Per qualsiasi cosa più grande, la rigenerazione CLI è l'unico approccio affidabile. I principi chiave sono: lavora sempre dalle immagini originali, adatta le definizioni dei tipi di immagine ai requisiti del tuo tema, gestisci proattivamente le risorse del server e i timeout, usa approcci incrementali quando possibile e verifica i risultati dopo il completamento del processo. Con WebP che sta diventando lo standard per le immagini web, la rigenerazione serve anche come meccanismo per creare varianti in formato moderno dell'intero catalogo prodotti, offrendo file di dimensioni ridotte e caricamenti pagina più rapidi ai tuoi clienti.

Leggi la risposta completa

Matrice di compatibilità delle versioni PHP per PrestaShop

Scegliere la versione PHP corretta per il tuo negozio PrestaShop è una delle decisioni infrastrutturali più critiche che prenderai. L'esecuzione di una versione PHP incompatibile può causare schermate bianche, processi di checkout malfunzionanti, errori nei moduli e vulnerabilità di sicurezza. Questa guida completa copre ogni versione di PrestaShop dalla 1.6 alla 9.x e associa ciascuna alle versioni PHP supportate, configurazioni raccomandate e considerazioni per l'aggiornamento.

Perché la versione PHP è importante per PrestaShop

PHP è il linguaggio lato server che alimenta PrestaShop. Ogni versione principale di PHP introduce miglioramenti delle prestazioni, nuove funzionalità del linguaggio e depreca le funzioni più vecchie. Il codice di PrestaShop si evolve parallelamente a PHP, il che significa che le versioni più recenti di PrestaShop sfruttano le funzionalità moderne di PHP abbandonando il supporto per quelle obsolete.

L'utilizzo della versione PHP sbagliata causa tre categorie di problemi:

Errori fatali - Le funzioni rimosse nelle versioni PHP più recenti (ad es., le funzioni mysql_* rimosse in PHP 7.0, each() rimossa in PHP 8.0) causano crash immediati.
Avvisi di deprecazione - Le funzioni deprecate generano avvisi che possono interrompere le risposte AJAX, l'output JSON e la generazione di PDF quando display_errors è abilitato.
Esposizione a rischi di sicurezza - Le versioni PHP che hanno raggiunto la fine del ciclo di vita non ricevono più patch di sicurezza, lasciando il tuo negozio vulnerabile.

Matrice di compatibilità completa

PrestaShop 1.6.x

Versione PrestaShop	PHP 5.4	PHP 5.5	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2+
1.6.0.x - 1.6.0.14	Sì	Sì	Sì	No	No	No
1.6.1.0 - 1.6.1.4	Sì	Sì	Sì	Parziale	No	No
1.6.1.5 - 1.6.1.23	Sì	Sì	Sì	Sì	Sì	No
1.6.1.24+	Sì	Sì	Sì	Sì	Sì	No

PHP raccomandato per 1.6.x - PHP 7.1. Offre il miglior equilibrio tra prestazioni e compatibilità. L'esecuzione di 1.6.x su PHP 7.2+ richiede modifiche ai file core che interrompono il percorso di aggiornamento e non è raccomandata.

PrestaShop 1.7.x

Versione PrestaShop	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0+
1.7.0.x - 1.7.4.x	Sì (raccomandato)	No	No	No	No
1.7.5.x	Sì	Sì (raccomandato)	No	No	No
1.7.6.x	Sì	Sì (raccomandato)	Sì	No	No
1.7.7.x	Sì	Sì	Sì (raccomandato)	Parziale	No
1.7.8.x	Sì	Sì	Sì	Sì (raccomandato)	No

Avviso critico - Nessuna versione di PrestaShop 1.7 supporta PHP 8.0 o successivo. Se esegui PS 1.7.6 su PHP 8, Smarty si bloccherà immediatamente perché il motore dei template utilizza funzioni rimosse in PHP 8.0. La rimozione della funzione each() e i cambiamenti nel funzionamento di array_key_exists() con gli oggetti causano errori fatali.

PrestaShop 8.x

Versione PrestaShop	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.1	PHP 8.2	PHP 8.3
8.0.0 - 8.0.2	Sì (min)	Sì	Sì	Sì	Parziale	No	No
8.0.3 - 8.0.5	Sì (min)	Sì	Sì	Sì	Sì (raccomandato)	No	No
8.1.0 - 8.1.2	No	Sì (min)	Sì	Sì	Sì (raccomandato)	Parziale	No
8.1.3 - 8.1.7	No	Sì (min)	Sì	Sì	Sì (raccomandato)	Sì	Parziale

PHP raccomandato per 8.x - PHP 8.1. È il punto ottimale che offre piena compatibilità, supporto di sicurezza attivo ed eccellenti prestazioni con la compilazione JIT. PHP 8.1 introduce fibers, enums, proprietà readonly e tipi intersection che PrestaShop 8 può sfruttare.

PrestaShop 9.x

Versione PrestaShop	PHP 8.1	PHP 8.2	PHP 8.3	PHP 8.4
9.0.x	Sì (min)	Sì	Sì (raccomandato)	Sì

PHP raccomandato per 9.x - PHP 8.3 o 8.4. PrestaShop 9 funziona su Symfony 6.4 LTS e richiede PHP 8.1 come minimo. PHP 8.4 introduce i Property Hooks e la visibilità asimmetrica che i futuri aggiornamenti di PrestaShop sfrutteranno.

Date di fine vita PHP che devi conoscere

Versione PHP	Supporto attivo fino a	Fix di sicurezza fino a	Stato (2026)
PHP 7.4	Nov 2021	Nov 2022	EOL - Pericoloso
PHP 8.0	Nov 2022	Nov 2023	EOL - Pericoloso
PHP 8.1	Nov 2023	Dic 2025	EOL - Aggiorna presto
PHP 8.2	Dic 2024	Dic 2026	Solo sicurezza
PHP 8.3	Dic 2025	Dic 2027	Solo sicurezza
PHP 8.4	Dic 2026	Dic 2028	Supporto attivo

Se nel 2026 stai usando PHP 7.4 o 8.0, stai operando su una versione non supportata che non riceve più patch di sicurezza. Questo è un rischio critico per qualsiasi negozio e-commerce che gestisce dati di pagamento.

Come verificare la versione PHP attuale

Metodo 1 - Back Office PrestaShop

Naviga su Parametri avanzati > Informazioni. La sezione Informazioni sul server mostra la tua versione PHP, insieme al limite di memoria, tempo massimo di esecuzione e altre impostazioni pertinenti.

Metodo 2 - File PHP Info

Crea un file chiamato phpinfo.php nella directory root del tuo negozio con questo contenuto:

<?php phpinfo();

Accedilo tramite il tuo browser all'indirizzo https://tuonegozio.com/phpinfo.php. Elimina questo file immediatamente dopo la verifica - espone dettagli sensibili della configurazione del server.

Metodo 3 - Riga di comando

php -v
php -r "echo PHP_VERSION;"

Nota che la versione PHP CLI può differire dalla versione PHP del server web. Verifica sempre tramite l'interfaccia web o phpinfo().

Problemi comuni con la versione PHP sbagliata

Schermata bianca della morte (WSOD)

Il sintomo più comune di incompatibilità PHP. Controlla il log degli errori PHP (solitamente in /var/log/php-errors.log o accessibile tramite il pannello di hosting). Errori tipici:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Gli avvisi di deprecazione interrompono AJAX

Quando display_errors = On e aggiorni PHP, le notice di deprecazione vengono preposte alle risposte AJAX. Questo interrompe il parsing JSON nel back office, causando il fallimento silenzioso di funzionalità come la ricerca prodotti, la ricerca clienti e la creazione ordini. La soluzione:

; php.ini
display_errors = Off
log_errors = On
error_log = /percorso/verso/php-error.log

Incompatibilità dei moduli

I moduli di terze parti potrebbero non supportare la tua versione PHP. Prima di aggiornare PHP, verifica la compatibilità di ogni modulo installato. Aree problematiche comuni:

Moduli che utilizzano create_function() - rimossa in PHP 8.0
Moduli che utilizzano le funzioni mysql_* - rimosse in PHP 7.0
Moduli che utilizzano l'accesso posizionale alle stringhe con parentesi graffe $str{0} - rimosso in PHP 8.0
Moduli che non gestiscono i tipi di ritorno nullable - più rigorosi da PHP 8.1+

Come aggiornare PHP per PrestaShop in sicurezza

Passo 1 - Audit della configurazione attuale

Prima di modificare qualsiasi cosa, documenta il tuo ambiente attuale:

php -v                    # Versione PHP attuale
php -m                    # Estensioni caricate
php -i | grep memory      # Limite di memoria
php -i | grep max_exec    # Limite del tempo di esecuzione

Passo 2 - Verificare la compatibilità dei moduli

Esamina ogni modulo installato. Consulta la documentazione dello sviluppatore del modulo per il supporto delle versioni PHP. Se un modulo non è stato aggiornato da oltre due anni, è probabilmente incompatibile con PHP 8.x.

Passo 3 - Testare prima su staging

Non aggiornare mai PHP sul server di produzione senza test preliminari. Crea una copia staging del tuo negozio e testa con la nuova versione PHP. Verifica:

Le pagine del front office si caricano correttamente
Pagine prodotto, pagine categoria, pagine CMS
Il processo di carrello e checkout si completa
I moduli di pagamento elaborano le transazioni di test
Le funzionalità del back office funzionano (modifica prodotti, gestione ordini)
Tutti i moduli di terze parti funzionano correttamente
I cron job vengono eseguiti senza errori

Passo 4 - Aggiornamento con piano di rollback

La maggior parte dei provider di hosting consente di cambiare la versione PHP dal pannello di controllo (cPanel, Plesk, DirectAdmin). Mantieni la versione PHP precedente disponibile per un rollback rapido se sorgono problemi.

Passo 5 - Svuotare tutte le cache dopo l'aggiornamento

Dopo il cambio di versione PHP, svuota ogni livello di cache:

# Svuotare la cache di PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Svuotare i template Smarty compilati
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Se usi OPcache, riavviare PHP-FPM
systemctl restart php8.3-fpm

# Svuotare la cache CDN (Cloudflare, ecc.)

Best practice di configurazione PHP per PrestaShop

Indipendentemente dalla versione PHP scelta, queste impostazioni sono essenziali per prestazioni ottimali di PrestaShop:

; Impostazioni php.ini raccomandate
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Impostazioni OPcache (critiche per le prestazioni)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Estensioni richieste
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Considerazioni per gli sviluppatori di moduli

Se sviluppi moduli PrestaShop, devi considerare attentamente la compatibilità PHP:

Versione PHP minima - Punta a PHP 7.2 come minimo per moduli che devono funzionare su PrestaShop 8.0+, o PHP 8.1 per moduli esclusivi per PrestaShop 9.
Usa PHPStan o Psalm - Gli strumenti di analisi statica rilevano le incompatibilità di versione PHP prima che lo facciano i tuoi utenti.
Evita la sintassi specifica di versione - Funzionalità come le espressioni match (PHP 8.0), gli enums (PHP 8.1) e le proprietà readonly (PHP 8.1) limitano il tuo modulo a quelle versioni PHP e superiori.
Testa su più versioni - Utilizza contenitori Docker con diverse versioni PHP per testare il tuo modulo su tutto l'intervallo di compatibilità.

Domande frequenti

Posso eseguire PrestaShop 1.7 su PHP 8?

No. Nessuna versione di PrestaShop 1.7 supporta ufficialmente PHP 8.0 o successivo. Sebbene alcuni utenti abbiano applicato patch per farlo funzionare parzialmente, questo non è supportato e causerà problemi con gli aggiornamenti. Il percorso corretto è migrare a PrestaShop 8.x.

Dovrei usare PHP 8.4 con PrestaShop 8.1?

Sconsigliato. PrestaShop 8.1 è stato sviluppato e testato principalmente con PHP 8.1. Sebbene PHP 8.2 sia parzialmente supportato nelle versioni 8.1.x successive, PHP 8.4 introduce cambiamenti che possono causare problemi con i componenti Symfony più vecchi. Resta con PHP 8.1 per PrestaShop 8.x.

Quanto è più veloce PHP 8.x rispetto a 7.x?

I benchmark mostrano che PHP 8.1 è circa il 20-30% più veloce di PHP 7.4 per i carichi di lavoro tipici di PrestaShop. Il compilatore JIT offre il maggior beneficio per le attività computazionali. Per le operazioni legate all'I/O (query al database, lettura di file), il miglioramento è minore ma comunque misurabile.

L'aggiornamento di PHP richiede l'aggiornamento di PrestaShop?

Non necessariamente, ma vanno di pari passo. Puoi aggiornare PHP nell'intervallo supportato per la tua versione di PrestaShop senza aggiornare PrestaShop stesso. Tuttavia, se vuoi utilizzare una versione PHP moderna (8.3+), avrai bisogno di PrestaShop 8.1 o 9.x.

Leggi la risposta completa

Lazy Loading nel 2026: cosa gestiscono nativamente i browser e cosa richiede un modulo

Il lazy loading e una tecnica di ottimizzazione delle prestazioni che differisce il caricamento delle risorse fuori schermo fino a quando l'utente non scorre vicino ad esse. Nel 2026, il supporto nativo dei browser per il lazy loading e maturato significativamente, ma ci sono ancora scenari in cui i proprietari di negozi PrestaShop hanno bisogno di moduli aggiuntivi o implementazioni personalizzate. Questa guida spiega esattamente cosa i browser gestiscono da soli, quali lacune rimangono e come implementare la migliore strategia di lazy loading per il tuo negozio PrestaShop.

Cosa copre il lazy loading nativo nel 2026

L'attributo HTML loading="lazy" e ora supportato da oltre il 95% dei browser a livello mondiale. Questo include Chrome (dalla v77), Firefox (dalla v75), Safari (dalla v15.4), Edge (dalla v79) e tutti i browser basati su Chromium.

Come funziona il lazy loading nativo

<img src="immagine-prodotto.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nome prodotto">

Cosa i browser gestiscono nativamente

Funzionalita	Supporto nativo	Note
Immagini (`<img>`)	Si - tutti i browser principali	Usa `loading="lazy"`
Iframes (`<iframe>`)	Si	Usa `loading="lazy"`
Immagini responsive (`<picture>`)	Si	`loading="lazy"` sull'`<img>` interno

Cosa i browser NON gestiscono

Funzionalita	Supporto nativo	Soluzione necessaria
Immagini di sfondo CSS	No	API IntersectionObserver o modulo
Elementi video	No	JavaScript personalizzato o modulo
Effetti placeholder/blur-up	No	Libreria JavaScript o modulo
Contenuto caricato dinamicamente/AJAX	No	Lazy loading basato su JavaScript

Implementare il lazy loading nativo in PrestaShop

Per i temi PrestaShop 8.x e 9.x

{* Prima - senza lazy loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Dopo - con lazy loading nativo *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Regola critica: mai lazy loadare le immagini above-the-fold

L'errore piu comune del lazy loading e applicarlo alle immagini visibili senza scorrimento. Questo in realta peggiora le prestazioni perche il browser ritarda il caricamento del contenuto che l'utente vede immediatamente.

Immagini che NON devono essere lazy loadate:

Il logo del tuo negozio
Immagini hero/banner in cima alla pagina
Le prime 1-2 immagini prodotto nelle pagine categoria

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Banner promozione estiva">

Quando serve un modulo: immagini di sfondo CSS

I temi PrestaShop usano frequentemente immagini di sfondo CSS per slider, banner e intestazioni di categoria. L'attributo loading="lazy" non funziona per gli sfondi CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Quando serve un modulo: effetti placeholder

Effetto blur-up (LQIP) - Carica prima una versione piccola e sfocata
Schermate scheletro - Blocchi placeholder grigi corrispondenti alle dimensioni
Placeholder colore dominante - Usa il colore dominante dell'immagine come sfondo

Impatto su prestazioni e Core Web Vitals

LCP - Il lazy loading delle immagini above-the-fold PEGGIORA il LCP
CLS - Le immagini senza attributi width/height causano spostamenti del layout
INP - Meno risorse caricate simultaneamente migliorano l'interattivita

<!-- MALE - causa spostamento layout -->
<img src="prodotto.jpg" loading="lazy" alt="Prodotto">

<!-- BENE - riserva spazio -->
<img src="prodotto.jpg" loading="lazy" 
     width="400" height="400" alt="Prodotto">

Raccomandazioni specifiche PrestaShop

Pagine lista prodotti

Lazy loadare tutte le immagini prodotto tranne la prima riga. Applicare fetchpriority="high" alla prima riga.

Pagine dettaglio prodotto

L'immagine principale deve essere caricata eager con fetchpriority="high". Le miniature della galleria possono essere lazy loadate.

Riepilogo: Modulo vs. Nativo

Scenario	Soluzione
Immagini prodotto standard	Nativo `loading="lazy"` - nessun modulo
Immagini di sfondo CSS	Modulo o JS con IntersectionObserver
Placeholder blur-up/LQIP	Modulo o libreria JS
Lazy loading video	JS personalizzato
Embed YouTube/Vimeo	Nativo `loading="lazy"` su iframe
Immagini contenuto CMS	Modulo per auto-aggiunta attributo

Leggi la risposta completa

Redirect .htaccess PrestaShop: scrivere regole senza rompere il negozio

Il file .htaccess e uno dei file piu potenti e pericolosi nella tua installazione PrestaShop. Un singolo carattere fuori posto puo mettere offline l'intero negozio. Ma padroneggiare i redirect .htaccess e essenziale per la SEO.

Come PrestaShop usa .htaccess

PrestaShop genera e gestisce automaticamente il file .htaccess. Quando attivi gli URL semplificati nelle impostazioni SEO e URL, PrestaShop scrive regole di riscrittura tra due commenti marcatori.

Regola critica - Non aggiungere mai i tuoi redirect personalizzati all'interno di questo blocco. PrestaShop li sovrascrivera alla prossima rigenerazione. Posiziona le tue regole PRIMA del blocco PrestaShop.

Tipi di redirect

301 - Redirect permanente

Usa quando una pagina si e spostata permanentemente. I motori di ricerca trasferiscono il valore SEO al nuovo URL.

302 - Redirect temporaneo

Usa quando una pagina e temporaneamente non disponibile.

410 - Gone

Usa quando una pagina e stata rimossa permanentemente senza sostituto.

Sintassi di base dei redirect

Redirect 301 /vecchia-pagina.html https://tuonegozio.com/nuova-pagina.html
Redirect 301 /vecchio-prodotto.html https://tuonegozio.com/it/nuovo-prodotto.html

Redirect basati su pattern con RewriteRule

RewriteEngine On
RewriteRule ^vecchia-cartella/(.*)$ https://tuonegozio.com/nuova-cartella/$1 [R=301,L]

Scenari comuni di redirect PrestaShop

Scenario 1 - Migrazione da un'altra piattaforma

RewriteRule ^product/vecchio-slug/?$ https://tuonegozio.com/it/nuovo-url.html [R=301,L]

Scenario 2 - Forzare HTTPS e WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Regole che possono rompere PrestaShop

Loop di redirect infiniti

L'errore piu pericoloso. Usa sempre condizioni per prevenire i loop.

# PERICOLOSO
RewriteRule ^(.*)$ https://tuonegozio.com/$1 [R=301,L]

# SICURO
RewriteCond %{HTTP_HOST} !^www\.tuonegozio\.com$ [NC]
RewriteRule ^(.*)$ https://www.tuonegozio.com/$1 [R=301,L]

Rompere l'accesso al back office

# SICURO - escludere admin e API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteRule ^(.*)$ https://tuonegozio.com/it/$1 [R=301,L]

Testare i redirect in sicurezza

cp .htaccess .htaccess.backup
curl -I -L https://tuonegozio.com/vecchia-pagina.html

Dove posizionare le regole personalizzate

# I TUOI REDIRECT QUI (prima del blocco PrestaShop)
Redirect 301 /vecchia-pagina.html https://tuonegozio.com/nuova-pagina.html

# ~~start~~ Blocco PrestaShop
# ... regole auto-generate ...
# ~~end~~ Blocco PrestaShop

Quando usare un modulo

Considera un modulo di redirect quando personale non tecnico deve gestire i redirect, hai centinaia di redirect, o vuoi il rilevamento automatico dei 404.

Leggi la risposta completa

Metodo	Protegge da	Costo
.htaccess	Scraper conosciuti	Gratuito
fail2ban	Brute force	Gratuito
Nginx	Richieste eccessive	Gratuito
CAPTCHA	Spam	Gratuito
Cloudflare Free	Bot, DDoS	Gratuito

Come funzionano i modelli di e-mail PrestaShop

PrestaShop invia e-mail transazionali in ogni momento chiave del percorso del cliente: creazione dell'account, conferma dell'ordine, notifica di spedizione, reimpostazione della password e molto altro. Queste e-mail vengono generate da file modello archiviati sul vostro server e sono completamente personalizzabili. Comprendere il funzionamento del sistema di modelli è il primo passo per creare e-mail di conferma ordine professionali e coerenti con il brand, che rafforzino l'identità del vostro negozio.

Ogni e-mail PrestaShop è composta da due file modello: una versione HTML per i client di posta che supportano la formattazione avanzata e una versione in testo semplice (TXT) per i client di posta che non la supportano. Entrambi i file devono essere presenti affinché un'e-mail venga inviata correttamente. La versione HTML è quella che la stragrande maggioranza dei vostri clienti vedrà. La versione TXT serve come fallback ed è utilizzata anche dagli strumenti di accessibilità e da alcuni filtri di posta aziendale.

I modelli di e-mail si trovano nella struttura di directory mails/. La posizione esatta dipende dall'utilizzo di e-mail del core, e-mail sovrascritte dal tema o e-mail specifiche di un modulo. Comprendere questa gerarchia è essenziale, poiché PrestaShop controlla più posizioni per ogni modello e utilizza il primo che trova.

La struttura delle directory dei modelli e-mail

PrestaShop organizza i modelli di e-mail in una gerarchia di directory specifica. Quando deve inviare un'e-mail, il sistema cerca in queste posizioni in ordine di priorità:

Override a livello di tema (Priorità massima)

I modelli in /themes/vostro-tema/mails/it/ (dove it è il codice ISO della lingua) hanno la priorità su tutte le altre posizioni. Se desiderate personalizzare un modello di e-mail senza modificare i file del core, è qui che i vostri modelli personalizzati devono essere collocati. Questo approccio sopravvive agli aggiornamenti di PrestaShop poiché i file del tema non vengono sovrascritti durante gli aggiornamenti del core.

Modelli del core (Predefiniti)

I modelli predefiniti si trovano in /mails/it/ nella directory principale di PrestaShop. Questi sono i modelli forniti con PrestaShop e vengono utilizzati quando non esiste alcun override del tema. Modificare direttamente questi file funziona, ma non è consigliato poiché le vostre modifiche andranno perse con l'aggiornamento di PrestaShop.

Modelli specifici per modulo

I moduli che inviano le proprie e-mail archiviano i modelli in /modules/nome-modulo/mails/it/. Ad esempio, le e-mail di notifica ordine inviate dai moduli di pagamento del core sono archiviate nelle rispettive directory dei moduli. Potete sovrascriverle inserendo copie modificate nella directory mails/ del vostro tema con lo stesso nome file.

Sottodirectory linguistiche

Ogni directory mails/ contiene sottodirectory per ogni lingua installata, utilizzando il codice ISO della lingua: en per l'inglese, fr per il francese, de per il tedesco e così via. Quando PrestaShop invia un'e-mail, utilizza il modello dalla directory corrispondente alla preferenza linguistica del cliente. Se un modello non esiste nella lingua del cliente, PrestaShop utilizza la lingua predefinita.

Anatomia di un modello di conferma ordine

L'e-mail di conferma ordine è l'e-mail transazionale più importante che il vostro negozio invia. Si tratta del file denominato order_conf.html (e del suo accompagnatore order_conf.txt) nella vostra directory mails. Esaminiamone la struttura nel dettaglio.

Struttura del modello HTML

I modelli di e-mail PrestaShop sono documenti HTML autonomi. Non utilizzano file CSS esterni poiché la maggior parte dei client di posta rimuove i fogli di stile esterni. Tutto lo styling deve essere CSS inline. Un tipico modello di conferma ordine include queste sezioni:

Il documento inizia con un doctype HTML standard e una sezione head. Il body contiene un layout basato su tabelle (poiché i client di posta hanno scarso supporto per i metodi di layout CSS moderni come flexbox e grid). All'interno di questo layout trovate una sezione di intestazione con il logo del vostro negozio, l'area di contenuto principale con i dettagli dell'ordine, una tabella prodotti che elenca ogni articolo ordinato, un riepilogo dei prezzi con subtotali e totali, informazioni sulla spedizione, dettagli del metodo di pagamento e un piè di pagina con le informazioni di contatto del negozio e le note legali.

Il sistema di variabili

PrestaShop utilizza un semplice sistema di sostituzione delle variabili nei modelli di e-mail. Le variabili sono racchiuse tra parentesi graffe: {nome_variabile}. Quando l'e-mail viene generata, PrestaShop sostituisce ogni variabile con il suo valore effettivo. Il modello di conferma ordine utilizza queste variabili chiave:

{firstname} e {lastname} contengono il nome del cliente. {order_name} è il numero di riferimento dell'ordine (come ABCDEF123). {shop_name} è il nome del vostro negozio come configurato nel back office. {shop_url} è l'URL del vostro negozio. {shop_logo} è il percorso dell'immagine del logo del vostro negozio. {date} è la data dell'ordine. {payment} è il metodo di pagamento utilizzato. {total_paid} è l'importo totale pagato. {delivery_company} e {delivery_address} contengono le informazioni sul corriere e l'indirizzo di consegna.

Per l'elenco dei prodotti, PrestaShop utilizza una sintassi a blocchi speciale. La sezione degli articoli è racchiusa in un ciclo che si ripete per ogni prodotto nell'ordine: {items} contiene l'HTML preformattato per l'intera tabella dell'elenco prodotti, inclusi nomi dei prodotti, quantità, prezzi e tutti i dettagli di personalizzazione.

Riferimento delle variabili disponibili

Per vedere tutte le variabili disponibili per un modello di e-mail specifico, consultate il codice PHP che invia l'e-mail. Per la conferma ordine, controllate la classe PaymentModule (in /classes/PaymentModule.php). Il metodo validateOrder() costruisce l'array delle variabili del modello. Ogni chiave nell'array corrisponde a un nome di variabile che potete utilizzare nel modello.

Le variabili comunemente disponibili nelle e-mail di conferma ordine includono: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} e {total_products}.

Personalizzare il modello di conferma ordine

Passaggio 1: Creare un override del tema

Non modificate mai direttamente i file dei modelli del core. Copiate invece il modello nella directory mails del vostro tema:

Copiate /mails/it/order_conf.html in /themes/vostro-tema/mails/it/order_conf.html. Fate lo stesso per order_conf.txt. Se la directory mails/it/ non esiste nel vostro tema, createla.

Se il vostro negozio supporta più lingue, copiate i modelli per ogni directory linguistica. La vostra conferma ordine in francese va in /themes/vostro-tema/mails/fr/order_conf.html e così via.

Passaggio 2: Modificare il layout HTML

Aprite il modello HTML in un editor di testo (non un editor visuale che potrebbe aggiungere codice indesiderato). L'HTML per le e-mail differisce dall'HTML per il web in diversi aspetti importanti:

Utilizzate le tabelle per il layout, non i div. I client di posta, in particolare Outlook, hanno un supporto CSS molto limitato. Un layout a tre colonne deve utilizzare un <table> con tre elementi <td>, non colonne CSS o flexbox.

Utilizzate stili inline su ogni elemento. Invece di <p class="heading"> con un foglio di stile separato, usate <p style="font-size:18px; font-weight:bold; color:#333333;">. Ogni elemento stilizzato necessita del proprio attributo di stile inline.

Impostate larghezze esplicite su tabelle e celle. I client di posta non rispettano sempre le larghezze percentuali. Utilizzate una larghezza fissa per la vostra tabella di contenuto principale (600 pixel è lo standard) con colonne interne percentuali.

Utilizzate font web-safe. Non tutti i client di posta supportano font personalizzati. Attenetevi ad Arial, Helvetica, Georgia, Times New Roman, Verdana o Trebuchet MS. Potete provare a caricare un font personalizzato come fallback, ma specificate sempre un font web-safe come fallback finale.

Passaggio 3: Aggiungere il vostro branding

Sostituite l'intestazione PrestaShop predefinita con il branding del vostro negozio. Questo tipicamente comporta l'aggiornamento del logo (la variabile {shop_logo} utilizza automaticamente il logo del vostro negozio, ma potreste volere una versione specifica per le e-mail), la modifica del colore di sfondo dell'intestazione per abbinarsi al vostro brand, l'aggiunta della palette colori del vostro brand ai titoli e ai link, e l'inclusione del tagline del vostro negozio o di un breve messaggio promozionale.

Mantenete la struttura complessiva semplice. Design di e-mail eccessivamente complessi si rompono in diversi client di posta. Un layout pulito a colonna singola con i colori e il logo del vostro brand è più efficace e affidabile di un elaborato design multicolonna.

Passaggio 4: Personalizzare la tabella prodotti

La tabella prodotti predefinita nella conferma ordine PrestaShop è funzionale ma essenziale. Potete migliorarla aggiungendo immagini dei prodotti (utilizzate URL assoluti a immagini ospitate sul vostro server, non percorsi relativi), aggiungendo link alle pagine prodotto affinché i clienti possano facilmente riordinare o lasciare recensioni, aggiungendo campi personalizzati come date di consegna stimate o messaggi personalizzati, e regolando lo stile della tabella per abbinarsi al vostro brand.

Quando aggiungete immagini dei prodotti, mantenetele piccole (da 50 a 80 pixel di larghezza) e includete sempre un attributo alt. Alcuni client di posta bloccano le immagini per impostazione predefinita, e il testo alternativo garantisce che i clienti possano comunque identificare i loro prodotti.

Aggiungere campi personalizzati alle e-mail degli ordini

Le variabili predefinite di PrestaShop coprono le informazioni standard dell'ordine, ma potreste voler includere dati aggiuntivi come punti fedeltà guadagnati, data di consegna stimata, un messaggio di ringraziamento personalizzato o raccomandazioni di prodotti in cross-selling.

Aggiungere variabili tramite un modulo

Il modo più pulito per aggiungere variabili personalizzate è attraverso un modulo che si aggancia al processo di invio delle e-mail. Create un modulo che registra l'hook actionEmailSendBefore (disponibile da PrestaShop 1.7.6) o l'hook actionGetExtraMailTemplateVars. Nel vostro gestore dell'hook, aggiungete le vostre variabili personalizzate all'array delle variabili del modello:

La vostra funzione hook riceve l'array delle variabili del modello per riferimento. Potete aggiungere nuove variabili a questo array e diventano disponibili nel modello utilizzando la sintassi standard {nome_variabile}. Ad esempio, dopo aver aggiunto loyalty_points all'array nel vostro hook, potete utilizzare {loyalty_points} nel vostro modello HTML di conferma ordine.

Utilizzare i dati esistenti del database

Potete inserire qualsiasi dato dal vostro database PrestaShop nelle variabili delle e-mail. Esempi comuni includono il conteggio totale degli ordini del cliente (per mostrare "Grazie per il tuo 5° ordine!"), il saldo dei punti fedeltà del cliente, campi prodotto personalizzati memorizzati nelle caratteristiche o attributi dei prodotti, e informazioni sul magazzino o fornitore per i prodotti ordinati.

Configurazione delle e-mail multilingue

Se il vostro negozio serve clienti in più lingue, ogni modello di e-mail necessita di una versione per ogni lingua. PrestaShop gestisce automaticamente la selezione della lingua in base alla preferenza linguistica del cliente, ma dovete fornire i modelli.

Creare modelli specifici per lingua

Per ogni lingua supportata dal vostro negozio, create una directory nella cartella mails del vostro tema: /themes/vostro-tema/mails/en/, /themes/vostro-tema/mails/fr/, /themes/vostro-tema/mails/de/ e così via. Copiate e traducete ogni file modello nella directory appropriata.

Non utilizzate la traduzione automatica per le e-mail transazionali. Queste e-mail rappresentano la comunicazione del vostro negozio con i clienti, e traduzioni scadenti danneggiano la fiducia. Fate scrivere o revisionare ogni versione linguistica da un madrelingua.

Supporto per le lingue da destra a sinistra

Se supportate lingue come l'arabo o l'ebraico, i vostri modelli di e-mail necessitano del supporto per il layout RTL (da destra a sinistra). Aggiungete dir="rtl" all'elemento tabella principale e regolate l'allineamento del testo e i padding nei vostri stili inline. Create modelli separati per le lingue RTL piuttosto che cercare di far funzionare un singolo modello per entrambe le direzioni.

Formattazione di date e valute

PrestaShop formatta automaticamente i valori di date e valute secondo le impostazioni di lingua e valuta del cliente. I valori {date}, {total_paid} e altri valori formattati riflettono già le impostazioni locali corrette. Tuttavia, se aggiungete variabili personalizzate con valori di date o valute, assicuratevi di formattarle correttamente per la lingua di destinazione.

Configurazione SMTP per una consegna affidabile

Il miglior modello di e-mail del mondo è inutile se le vostre e-mail non raggiungono la casella di posta in arrivo. La configurazione predefinita delle e-mail di PrestaShop utilizza la funzione mail() integrata di PHP, che è inaffidabile per le e-mail transazionali. La maggior parte di queste e-mail finisce nella cartella spam o viene completamente rifiutata dai provider di posta moderni.

Perché l'SMTP è importante

L'SMTP (Simple Mail Transfer Protocol) con autenticazione appropriata è essenziale per la deliverability delle e-mail. Quando inviate e-mail tramite la funzione mail() di PHP, l'e-mail proviene dall'indirizzo IP del vostro server web senza alcuna autenticazione. I provider di posta come Gmail, Outlook e Yahoo vedono questo come un segnale d'allarme e spesso classificano queste e-mail come spam.

Con l'SMTP, le vostre e-mail vengono inviate attraverso un server di posta autenticato con record SPF, DKIM e DMARC appropriati. Questo dimostra ai server di posta riceventi che l'e-mail è legittima e autorizzata dal vostro dominio.

Configurare l'SMTP in PrestaShop

Andate su Parametri avanzati > E-mail nel vostro back office PrestaShop. Cambiate il metodo da "Usa la funzione mail() di PHP" a "Imposta i miei parametri SMTP". Inserite i dettagli del vostro server SMTP: l'indirizzo del server, la porta (tipicamente 587 per TLS o 465 per SSL), il tipo di crittografia, il nome utente e la password.

I provider SMTP comuni per PrestaShop includono Gmail SMTP (smtp.gmail.com, porta 587, TLS, richiede una password per le app se la 2FA è abilitata), Amazon SES (conveniente per volumi elevati), SendGrid (generoso livello gratuito), Mailgun (developer-friendly con buona registrazione) e il server SMTP del vostro hosting provider (verificate con il vostro host per le impostazioni).

Testare la configurazione SMTP

Dopo aver configurato l'SMTP, utilizzate il pulsante "Invia un'e-mail di test" in fondo alla pagina di configurazione delle e-mail. Inserite il vostro indirizzo e-mail e verificate che l'e-mail di test arrivi nella vostra casella di posta in arrivo (non nello spam). Se l'e-mail di test fallisce, verificate le vostre credenziali SMTP, assicuratevi che il vostro server possa raggiungere il server SMTP sulla porta configurata (alcuni hosting provider bloccano le porte in uscita 25 e 587) e controllate se il vostro provider SMTP richiede impostazioni di sicurezza specifiche.

Record SPF, DKIM e DMARC

Per la massima deliverability, configurate questi record DNS per il vostro dominio. SPF (Sender Policy Framework) specifica quali server sono autorizzati a inviare e-mail per conto del vostro dominio. DKIM (DomainKeys Identified Mail) aggiunge una firma digitale alle vostre e-mail che prova che sono state inviate dal vostro dominio. DMARC (Domain-based Message Authentication, Reporting, and Conformance) dice ai server riceventi cosa fare con le e-mail che non superano i controlli SPF o DKIM.

Il vostro provider SMTP vi fornirà i record DNS specifici da aggiungere. Ad esempio, se utilizzate SendGrid, forniscono i record SPF e DKIM durante il processo di autenticazione del dominio. Aggiungeteli come record TXT nelle impostazioni DNS del vostro dominio.

Testare i modelli di e-mail

Invio di e-mail di test

PrestaShop non ha un modo integrato per visualizzare in anteprima modelli di e-mail specifici. Per testare il vostro modello di conferma ordine, dovete effettuare un vero ordine di test. Create un account cliente di test, aggiungete prodotti al carrello e completate il checkout con un metodo di pagamento di test. Se avete un modulo di pagamento sandbox configurato, utilizzatelo. Altrimenti, i metodi di pagamento tramite bonifico bancario o assegno vi permettono di completare un ordine senza elaborazione del pagamento effettiva.

Test su diversi client di posta

Il rendering delle e-mail varia drasticamente tra i client di posta. Quello che appare perfetto in Gmail potrebbe essere rotto in Outlook. Come minimo, testate i vostri modelli in Gmail (web), Outlook (desktop e web), Apple Mail, Yahoo Mail e almeno un'app di posta mobile. Servizi come Litmus o Email on Acid automatizzano questi test renderizzando la vostra e-mail in decine di client di posta contemporaneamente, ma sono servizi a pagamento.

Problemi di rendering comuni

Se la vostra e-mail appare rotta in Outlook, è quasi certamente un problema di CSS. Outlook utilizza il motore di rendering di Microsoft Word per le e-mail HTML, che ha un supporto CSS estremamente limitato. Non supporta immagini di sfondo sulle celle delle tabelle (utilizzate colori di sfondo al loro posto), padding sugli elementi blocco (utilizzate il padding delle celle delle tabelle), max-width (utilizzate larghezze fisse), margin per il centraggio (utilizzate align="center" sulle tabelle) e float CSS.

Per la responsività mobile, avvolgete la vostra tabella di contenuto in un contenitore con max-width:600px e aggiungete una media query nel blocco di stile dell'head (che alcuni client di posta supportano) che imposta le larghezze delle tabelle al 100% su schermi piccoli. Questo non è un design responsive perfetto, ma previene lo scrolling orizzontale sulla maggior parte dei dispositivi mobili.

Problemi comuni e risoluzione

Immagini mancanti nelle e-mail

Questo è il problema più comune dei modelli di e-mail. Le immagini nelle e-mail devono utilizzare URL assoluti (che iniziano con https://), non percorsi relativi. Se il vostro modello fa riferimento a /img/logo.png, cambiatelo in https://www.vostrodominio.com/img/logo.png. La variabile {shop_logo} genera automaticamente un URL assoluto, ma tutte le immagini che aggiungete manualmente devono utilizzare URL completi.

Verificate inoltre che le vostre immagini siano accessibili dall'esterno della vostra rete. Se il vostro negozio è dietro un firewall o un'autenticazione HTTP, i client di posta non possono caricare le immagini. Testate aprendo l'URL dell'immagine in una finestra del browser privata/in incognito.

Layout rotto dopo la modifica

L'HTML delle e-mail è fragile. Un singolo tag non chiuso o una cella di tabella mancante può rompere l'intero layout. Validate sempre il vostro HTML dopo la modifica. Contate i vostri tag di apertura e chiusura table, tr e td. Ogni <table> necessita di un </table>, ogni <tr> necessita di un </tr> e ogni <td> necessita di un </td>. Verificate che ogni riga in una tabella abbia lo stesso numero di celle (o utilizzi colspan per compensare la differenza).

Variabili non sostituite

Se vedete il testo letterale {nome_variabile} nelle vostre e-mail inviate invece dei valori effettivi, controllate il nome della variabile per errori di battitura. I nomi delle variabili sono case-sensitive. Verificate inoltre che la variabile esista per il tipo specifico di e-mail che state personalizzando. Non tutte le variabili sono disponibili in tutti i modelli di e-mail. Le variabili specifiche dell'ordine come {order_name} sono disponibili solo nelle e-mail relative agli ordini.

Le e-mail non vengono inviate affatto

Se le e-mail non vengono inviate, controllate il back office PrestaShop sotto Parametri avanzati > E-mail. Qui potete vedere un registro delle e-mail inviate. Se il registro mostra errori, controllate la vostra configurazione SMTP. Se nessuna e-mail appare nel registro, l'e-mail potrebbe non essere attivata affatto. Verificate che le transizioni di stato dell'ordine siano configurate per inviare e-mail al cliente (Ordini > Stato > modifica stato > spuntate "Invia un'e-mail al cliente").

Controllate anche il registro errori PHP del vostro server per errori relativi alle e-mail. Problemi comuni includono la funzione mail() di PHP disabilitata dal provider di hosting, errori di autenticazione SMTP dovuti a password modificate e problemi di connettività di rete tra il vostro server e il server SMTP.

Le e-mail finiscono nello spam

Anche con una configurazione SMTP corretta, le e-mail possono comunque finire nello spam. Le ragioni più comuni sono record SPF/DKIM/DMARC mancanti o errati, contenuto dell'e-mail che attiva i filtri antispam (uso eccessivo di lettere maiuscole, parole che attivano lo spam come "gratis" o "agisci ora", troppe immagini con poco testo), invio da un indirizzo IP con cattiva reputazione (comune con l'hosting condiviso) e l'indirizzo e-mail "da" il cui dominio non corrisponde al dominio del server SMTP.

Correggete prima i record DNS, poi esaminate il contenuto delle vostre e-mail. Utilizzate uno strumento come mail-tester.com per analizzare le vostre e-mail alla ricerca di elementi che attivano lo spam. Inviate un'e-mail di test all'indirizzo che forniscono e riceverete un rapporto dettagliato che mostra cosa potrebbe causare la classificazione come spam.

Override e-mail specifici del tema

Alcuni temi PrestaShop includono i propri modelli di e-mail che corrispondono al design del tema. Se il vostro tema ha modelli in /themes/vostro-tema/mails/, questi sovrascrivono automaticamente i modelli del core.

Verificare i modelli e-mail del tema

Cercate nella directory del vostro tema attivo una cartella mails. Se esiste, il tema fornisce modelli di e-mail personalizzati. Questi modelli solitamente corrispondono alla palette colori e al design dell'intestazione/piè di pagina del tema, conferendo alle vostre e-mail coerenza visiva con la vostra vetrina.

Personalizzare i modelli e-mail del tema

Se il vostro tema fornisce modelli di e-mail, modificate quelli invece di copiare dalla directory mails/ del core. I modelli del tema possono utilizzare una struttura HTML diversa o includere CSS aggiuntivo specifico per il sistema di design del tema. Partire dalla versione del tema garantisce coerenza visiva.

Mantenere i modelli sincronizzati con gli aggiornamenti del tema

Quando aggiornate il vostro tema, controllate se l'aggiornamento include modifiche ai modelli di e-mail. In tal caso, le vostre personalizzazioni potrebbero essere sovrascritte. Prima dell'aggiornamento, fate il backup dei vostri modelli personalizzati. Dopo l'aggiornamento, confrontate i nuovi modelli con i vostri backup e riapplicate le personalizzazioni alle versioni aggiornate. È tedioso ma necessario per mantenere sia le vostre personalizzazioni sia eventuali miglioramenti o correzioni apportati dallo sviluppatore del tema.

Best practice per le e-mail di conferma ordine

Un'e-mail di conferma ordine ben realizzata fa molto di più che confermare la transazione. Costruisce fiducia, riduce le richieste di supporto e crea opportunità di coinvolgimento.

Includete un numero di riferimento dell'ordine chiaro e ben visibile in alto. I clienti hanno bisogno di questo numero quando contattano il supporto o tracciano il loro ordine. Elencate ogni prodotto con il suo nome, la quantità, il prezzo e tutte le opzioni o personalizzazioni. Includete il dettaglio completo di subtotale, costi di spedizione, tasse, sconti e totale. Mostrate l'indirizzo di consegna affinché i clienti possano verificarlo e contattarvi immediatamente se è sbagliato. Indicate il metodo di pagamento utilizzato e tutti i dettagli della transazione pertinenti. Fornite un link alla pagina di tracciamento dell'ordine o allo storico ordini del cliente nel suo account. Aggiungete le informazioni di contatto del servizio clienti affinché i clienti sappiano come raggiungervi in caso di problemi.

Mantenete il design pulito e mobile-friendly. Più della metà di tutte le e-mail viene letta su dispositivi mobili. Utilizzate un layout a colonna singola, testo grande e leggibile (minimo 14px per il testo del corpo) e pulsanti con target touch adeguati (minimo 44px di altezza). La vostra e-mail di conferma ordine è un riflesso della professionalità del vostro negozio. Investite il tempo necessario per farla bene.

Leggi la risposta completa

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Leggi la risposta completa

Cookie	Fornitore	Finalità	Durata
PrestaShop-*	PrestaShop	Gestione della sessione e funzionalità del carrello	Sessione
PHPSESSID	PHP	Identificativo sessione PHP	Sessione
mprcr_consent	MPR Cookies Revolution	Memorizza le preferenze di consenso dei cookie	365 giorno/i
mprcr_version	MPR Cookies Revolution	Traccia la versione della configurazione del consenso	365 giorno/i

Cookie	Fornitore	Finalità	Durata
TawkConnectionTime	Tawk.to	Czas polaczenia sesji czatu	Sessione
__tawkuuid	Tawk.to	Identyfikuje powracajacych uzytkownikow czatu	6 mese/i