Ottimizzazione prestazioni PrestaShop: Velocizza il tuo negozio

Perché la velocità del negozio non è opzionale

Ogni 100 millisecondi di tempo di caricamento aggiuntivo vi costa conversioni. Amazon ha scoperto che un ritardo di 100ms riduceva i ricavi dell’1%. Google ha confermato che le pagine che impiegano più di 3 secondi a caricarsi perdono il 53% dei visitatori mobile prima ancora che vedano i vostri prodotti.

Per un negozio PrestaShop, la velocità influisce direttamente su tre aspetti:

• Tassi di conversione: Un negozio che si carica in 2 secondi converte circa il doppio rispetto a uno che si carica in 5 secondi. I vostri clienti non aspetteranno — compreranno da qualcuno più veloce.
• Posizionamento SEO: Google utilizza la velocità della pagina come fattore di ranking. Dal 2021, i Core Web Vitals fanno parte dell’algoritmo. Un negozio lento si posiziona più in basso, riceve meno traffico organico e paga di più per la visibilità.
• Esperienza mobile: Oltre il 70% del traffico e-commerce è mobile. Processori più lenti, meno memoria, connessioni peggiori. Se il vostro negozio è lento su desktop, su mobile è penoso.

L’ottimizzazione della velocità non è un’attività una tantum — è una disciplina continua. Ogni modulo che installate, ogni modifica al tema, ogni immagine di prodotto influisce sulle prestazioni. Trattate la velocità come una funzionalità da mantenere, non un progetto da completare.

Misurate prima di ottimizzare

La cosa peggiore che possiate fare è iniziare a “ottimizzare” senza sapere dove siano i vostri problemi reali. Misurate sempre prima.

Gli strumenti giusti

• Google PageSpeed Insights: Gratuito, utilizza dati reali degli utenti Chrome (CrUX). Testate la homepage, una pagina di categoria e una pagina prodotto — sono i vostri punti di ingresso più comuni.
• GTmetrix: Vi fornisce un grafico a cascata che mostra esattamente cosa si carica, in quale ordine e quanto tempo richiede ogni richiesta. Inestimabile per individuare i colli di bottiglia.
• WebPageTest: Lo strumento più dettagliato disponibile. Testate da diverse località e velocità di connessione con visualizzazioni filmstrip.

Core Web Vitals spiegati

Queste sono le tre metriche che Google utilizza per valutare l’esperienza utente:

• LCP (Largest Contentful Paint): Tempo necessario affinché l’elemento visibile più grande finisca di caricarsi. Obiettivo: sotto i 2,5 secondi. La maggior parte dei negozi PrestaShop ha difficoltà qui — immagini non ottimizzate e script che bloccano il rendering sono i colpevoli.
• INP (Interaction to Next Paint): Quanto tempo impiega la pagina a rispondere a clic e tocchi. Ha sostituito FID a marzo 2024. Obiettivo: sotto i 200ms. JavaScript pesante e script dei moduli scritti male causano un INP elevato.
• CLS (Cumulative Layout Shift): Quanto il layout si sposta durante il caricamento. Obiettivo: sotto 0,1. Immagini senza dimensioni, banner caricati in ritardo e cambio di font causano CLS.

Obiettivi realistici

Un negozio PrestaShop ricco di funzionalità non raggiungerà mai un punteggio di 100 su PageSpeed. Puntate a: mobile 50-70, desktop 80-95, LCP sotto i 3s su mobile / 2s su desktop, peso totale della pagina sotto i 2MB, meno di 80 richieste HTTP.

Non rincorrete un punteggio PageSpeed perfetto. Un punteggio di 65 con un tasso di conversione del 3% batte un punteggio di 98 su una pagina minimale da cui nessuno compra. Ottimizzate per l’esperienza reale dell’utente, non per un numero.

Ottimizzazione del server

Nessun trucco frontend può compensare un server lento. Se il vostro server impiega 2 secondi per generare l’HTML prima ancora che il browser inizi a caricare le risorse, avete già perso.

Configurazione di PHP OPcache

OPcache memorizza il bytecode PHP precompilato in memoria, così PHP non deve ri-analizzare i file ad ogni richiesta. Per PrestaShop (centinaia di file PHP per pagina), è obbligatorio.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

I valori predefiniti sono troppo bassi per PrestaShop. max_accelerated_files deve essere almeno 20000 (il valore predefinito è 4000, ma un’installazione tipica di PS ha 10.000-15.000 file PHP). Impostate memory_consumption a 128-256MB — se la memoria di OPcache si riempie, le voci vengono eliminate e perdete il beneficio.

Sugli host cPanel con validate_timestamps=0, OPcache NON rileggerà MAI i file dal disco. Dovete resettarlo tramite una richiesta web dopo ogni deployment — i reset da CLI cancellano solo la cache CLI, non quella web.

Ottimizzazione di MySQL / MariaDB

Una tipica pagina prodotto PrestaShop esegue 50-200 query SQL. L’impostazione del database più importante in assoluto è:

[mysqld]
# Set to 50-70% of available RAM on dedicated DB server
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# MySQL 5.7 / MariaDB only (removed in MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Find problem queries
slow_query_log = 1
long_query_time = 1

# Connection settings
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Il parametro innodb_buffer_pool_size determina quanti dati del database vengono mantenuti in RAM. Se il vostro database è di 500MB e il buffer pool è di 1GB, la maggior parte delle query viene servita dalla memoria. Attivate lo slow query log e controllalo settimanalmente — le query che richiedono più di 1 secondo sono problemi in attesa di manifestarsi durante i picchi di traffico.

Hosting: Shared vs VPS vs Dedicato

• Hosting condiviso ($5-15/mese): Condividete CPU e RAM con centinaia di siti. Accettabile solo per negozi molto piccoli con meno di 500 prodotti.
• VPS ($20-60/mese): Risorse dedicate. La scelta ideale per la maggior parte dei negozi. Procuratevi almeno 4GB di RAM, 2 core CPU, storage SSD.
• Dedicato ($80-300/mese): Per negozi ad alto traffico (1000+ ordini giornalieri) o cataloghi con oltre 100.000 prodotti.

Se siete su hosting condiviso e il vostro negozio è lento, passare a un VPS vi darà un miglioramento di velocità superiore a tutte le altre ottimizzazioni messe insieme.

PHP-FPM e Redis

Utilizzate PHP-FPM al posto di mod_php — esegue PHP come servizio separato, riducendo il consumo di memoria e migliorando la gestione dei processi. Utilizzate Redis per la memorizzazione di sessioni e cache al posto del filesystem. Configurate in app/config/parameters.php:

'ps_cache_enable' => true,
'ps_caching' => 'CacheRedis',

Ottimizzazioni integrate di PrestaShop

CCC (Combine, Compress, Cache)

Presente in Parametri Avanzati → Prestazioni, CCC combina i file CSS/JS in file singoli e li minifica. Attivatelo sempre in produzione. Fate attenzione alle insidie:

• I file con attributi defer o async restano separati (per design)
• I file esterni (Google Fonts, Stripe.js) non vengono mai combinati
• Moduli scritti male possono rompersi quando CCC riordina le risorse — se attivare CCC rompe il vostro checkout, disattivatelo e identificate il modulo problematico
• Svuotate sempre la cache e testate accuratamente dopo l’attivazione

Impostazioni dei template Smarty

Impostate la compilazione dei template su “Ricompila i template se i file sono stati aggiornati” in produzione. Non usate mai “Forza compilazione” — ricompila ogni template ad ogni caricamento di pagina.

Modalità Debug — Controllate questo per primo

La modalità debug disabilita tutta la cache, forza la ricompilazione dei template e registra tutto. Verificate che sia disattivata:

// In app/config/defines.inc.php — MUST be false on production
define('_PS_MODE_DEV_', false);

Abbiamo visto negozi con la modalità debug attiva per mesi. Il loro problema di “negozio lento” è svanito quando questa singola impostazione è stata corretta.

Disabilitate i moduli non necessari

Ogni modulo abilitato si aggancia al sistema di eventi di PrestaShop. Un’installazione pulita include più di 80 moduli. Ognuno carica classi PHP, può registrare CSS/JS su ogni pagina, esegue callback degli hook e può lanciare query al database — anche quando restituisce contenuto vuoto.

Andate in Moduli → Gestione Moduli e disinstallate tutto ciò che non utilizzate attivamente. Se avete tre moduli di analisi che fanno la stessa cosa, tenetene uno.

Ottimizzazione delle immagini

Le immagini rappresentano tipicamente il 60-80% del peso totale di una pagina. È qui che la maggior parte dei negozi ha il margine di miglioramento più ampio.

WebP e dimensioni corrette

Le immagini WebP sono il 25-35% più piccole delle JPEG senza perdita di qualità visibile. PrestaShop 8.x supporta WebP nativamente. Per le versioni precedenti, utilizzate la conversione lato server o un modulo.

Lo spreco più comune: servire immagini da 2000x2000px in miniature da 300px. Configurate i tipi di immagine in Design → Impostazioni Immagini in modo che corrispondano alle dimensioni di visualizzazione reali del vostro tema. Non caricate immagini sorgente da 4000px “per sicurezza” — 1200px sono sufficienti per lo zoom della pagina prodotto su display retina.

Caricamento lazy

Posticipate il caricamento delle immagini sotto la piega fino a quando l’utente non scorre fino a esse:

<img src="product.jpg" loading="lazy" width="300" height="300" alt="Product Name">

NON applicate il lazy loading alle immagini sopra la piega (logo, banner hero, prima riga di prodotti) — queste influiscono sull’LCP e devono caricarsi immediatamente.

Rigenerazione delle immagini

Dopo aver modificato le dimensioni delle immagini, rigenerate le immagini esistenti tramite Design → Impostazioni Immagini o CLI:

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

Ottimizzazione frontend

Minimizzate le richieste HTTP

Controllate il vostro grafico a cascata in GTmetrix. Oltre 100 richieste significa problemi. Colpevoli comuni: moduli che caricano i propri file CSS/JS, Google Fonts con pesi multipli, widget dei social media e strumenti di analisi multipli.

Critical CSS

I browser interrompono il rendering finché tutto il CSS nel <head> non è stato scaricato. Il Critical CSS estrae solo gli stili necessari per il viewport iniziale e li inserisce inline. Il foglio di stile completo si carica in modo asincrono. Questo può ridurre il tempo di caricamento percepito di 1-3 secondi su mobile, ma richiede la rigenerazione ogni volta che il CSS del tema cambia.

JavaScript: Defer e Async

Utilizzate defer per la maggior parte degli script dei moduli (scarica in parallelo, esegue dopo il parsing dell’HTML). Utilizzate async solo per script indipendenti come l’analisi. In PrestaShop 1.7+:

$this->context->controller->registerJavascript(
    'module-my-script',
    'modules/mymodule/views/js/front.js',
    ['position' => 'bottom', 'priority' => 200, 'attribute' => 'defer']
);

Ottimizzazione dei font

I font personalizzati aggiungono silenziosamente 200-400KB di download. Buone pratiche:

• Ospitate i font localmente invece di usare Google Fonts (elimina una ricerca DNS aggiuntiva)
• Sottoinsieme limitato ai soli caratteri necessari (i sottoinsiemi solo latini sono il 60-80% più piccoli)
• Utilizzate font-display: swap così il testo è visibile immediatamente con un font di fallback
• Limitatevi a 2 pesi — regular (400) e bold (700) coprono la maggior parte delle esigenze
• Utilizzate il formato WOFF2 — miglior compressione, supporto universale dei browser

@font-face {
    font-family: 'YourFont';
    src: url('/themes/your-theme/assets/fonts/yourfont.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

Nozioni base sulla CDN

Una CDN serve i file statici da server vicini ai vostri visitatori. Cloudflare è l’opzione gratuita più diffusa. Configurate un dominio CDN in Parametri Avanzati → Prestazioni → Media Server per immagini, CSS e JS.

Ottimizzazione del database

I database PrestaShop crescono silenziosamente. Tabelle che andavano bene al lancio diventano problematiche dopo due anni di dati accumulati.

Pulite i carrelli vecchi

ps_cart e ps_cart_product crescono con ogni visitatore — inclusi bot e sessioni abbandonate. Dopo un anno, queste tabelle possono avere milioni di righe.

-- Delete cart products for old abandoned carts (not linked to orders)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Delete the empty carts
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
LEFT JOIN ps_cart_product cp ON c.id_cart = cp.id_cart
WHERE o.id_order IS NULL AND cp.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Fate sempre un backup del database prima di eseguire query DELETE. Testate sempre prima sull’ambiente di staging. Il pattern LEFT JOIN + IS NULL assicura che i carrelli collegati a ordini non vengano mai eliminati.

Pulite log e connessioni

-- Application logs
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Visitor tracking
DELETE FROM ps_connections_page WHERE id_connections IN (
    SELECT id_connections FROM ps_connections
    WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Orphaned guest records
DELETE g FROM ps_guest g
LEFT JOIN ps_connections c ON g.id_guest = c.id_guest
WHERE c.id_guest IS NULL;

-- Search stats, 404 logs, email logs
DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Pulite l’indice di ricerca

Se utilizzate una soluzione di ricerca esterna (Elasticsearch, Algolia), queste tabelle sono peso morto:

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Ottimizzate tabelle e indici

Dopo eliminazioni consistenti, recuperate spazio su disco:

OPTIMIZE TABLE ps_cart, ps_cart_product, ps_connections,
    ps_connections_page, ps_guest, ps_log;

Aggiungete indici mancanti per le query più comuni:

-- Check existing indexes first: SHOW INDEX FROM ps_cart;
ALTER TABLE ps_cart ADD INDEX idx_cart_date (date_add);
ALTER TABLE ps_connections ADD INDEX idx_conn_date (date_add);
ALTER TABLE ps_orders ADD INDEX idx_orders_ref (reference);
ALTER TABLE ps_product ADD INDEX idx_product_ref (reference);

Utilizzate EXPLAIN sulle query lente per verificare che gli indici siano utilizzati — se la colonna “type” mostra “ALL”, significa che viene eseguita una scansione completa della tabella.

Strategie di caching

Cache a pagina intera

Il miglioramento più significativo disponibile. Senza di essa, ogni richiesta esegue centinaia di file PHP e più di 100 query (200-500ms). Con la cache a pagina intera, la stessa pagina viene servita in 5-20ms.

Varnish è lo standard del settore. nginx FastCGI cache è più semplice se utilizzate già nginx:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PS:100m inactive=60m;

set $skip_cache 0;
if ($http_cookie ~* "PrestaShop-") { set $skip_cache 1; }
if ($request_uri ~* "/cart|/order|/my-account|/admin") { set $skip_cache 1; }

location ~ \.php$ {
    fastcgi_cache PS;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

La sfida è l’invalidazione della cache — svuotare le pagine memorizzate quando prodotti, prezzi o giacenze cambiano. Questa complessità è il motivo per cui molti negozi rinunciano alla cache a pagina intera.

Object caching e browser caching

Object caching (tramite Redis) memorizza i risultati delle query più costose in memoria. Meno impattante della cache a pagina intera (riduzione del 30-50% del tempo delle query) ma molto più semplice — PrestaShop gestisce l’invalidazione automaticamente.

Browser caching — gli header indicano ai browser dei visitatori di memorizzare i file statici localmente:

# Apache (.htaccess)
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Problemi di prestazioni più comuni

• Troppi moduli (50+): Ognuno aggiunge overhead all’autoloader, callback degli hook, CSS/JS e query. Un negozio con 30 moduli supera sempre in prestazioni uno con 80. Non esiste un modulo a costo zero.
• Moduli che caricano risorse ovunque: Un modulo popup che si attiva solo sulla homepage ma carica 150KB di JavaScript su ogni pagina è puro spreco. Controllate il vostro grafico a cascata alla ricerca di risorse irrilevanti dei moduli.
• Slider pesanti in homepage: 3-5 immagini ad alta risoluzione più una libreria JS = 1-5MB per un componente con cui meno dell’1% degli utenti interagisce oltre la prima slide. Utilizzate invece una singola immagine hero statica.
• Temi personalizzati non ottimizzati: Bootstrap completo caricato per 3 componenti, CSS/JS non minificati, dimensioni delle immagini assenti, script sincroni. Richiedete audit delle prestazioni agli sviluppatori dei temi.
• Indici di database mancanti: Una query con un indice appropriato richiede 10ms. Senza, richiede 5 secondi — e non ve ne accorgerete fino ai picchi di traffico.

Checklist di monitoraggio delle prestazioni

Controlli rapidi (5 minuti)

• Eseguite PageSpeed Insights su homepage, pagina di categoria, pagina prodotto
• Verificate che _PS_MODE_DEV_ sia false
• Confermate che Smarty NON sia impostato su “Forza compilazione”
• Controllate che CCC sia attivato
• Verificate che OPcache sia attivo tramite phpinfo()

Manutenzione mensile (30 minuti)

• Pulite i carrelli abbandonati in ps_cart / ps_cart_product (più vecchi di 3 mesi)
• Pulite ps_log, ps_connections, ps_connections_page, ps_guest
• Eseguite OPTIMIZE TABLE sulle tabelle pulite
• Controllate lo slow query log
• Disinstallate i moduli non utilizzati

Revisione trimestrale (2 ore)

• Test completo GTmetrix da più località — confrontate con il trimestre precedente
• Controllate i Core Web Vitals in Google Search Console
• Effettuate un audit delle risorse dei moduli alla ricerca di CSS/JS non necessari
• Verificate le dimensioni delle immagini — assicuratevi che non ci siano upload sovradimensionati
• Controllate l’utilizzo delle risorse del server (CPU, RAM, I/O disco)
• Testate su un dispositivo mobile reale, non solo con l’emulazione
• Verificate gli header di browser caching
• Controllate i log degli errori PHP (gli errori consumano risorse)

Dopo ogni deployment

• Svuotate la cache di PrestaShop
• Resettate OPcache se validate_timestamps=0
• Eseguite un test rapido PageSpeed per verificare eventuali regressioni
• Controllate la console del browser per errori JavaScript
• Testate il flusso di checkout dall’inizio alla fine

Da dove iniziare

L’ottimizzazione delle prestazioni è un processo, non una destinazione. Iniziate con i quattro elementi a maggior impatto: correggete la configurazione del server, ottimizzate le immagini, disabilitate i moduli non necessari e pulite il database. Questi da soli risolvono l’80% dei problemi di prestazioni nella maggior parte dei negozi PrestaShop.

Misurate prima e dopo ogni modifica. Tenete un registro. La migliore ottimizzazione è quella che i vostri clienti notano — un caricamento delle immagini più veloce e un checkout reattivo si traducono direttamente in fiducia, soddisfazione e conversioni.