Guide Guida

Ottimizzazione prestazioni PrestaShop: Velocizza il tuo negozio

Guida completa alle prestazioni: OPcache, tuning MySQL, configurazione CCC, ottimizzazione immagini, strategie di caching e Core Web Vitals.

La velocità è un problema di conversione, non una metrica di vanità

Sviluppiamo Performance Revolution, il nostro modulo di caching, Critters e PurgeCSS, e lo usiamo sui negozi ad alto traffico che gestiamo in prima persona. Lo schema è desolatamente costante: la maggior parte dei negozi PrestaShop è lenta per le stesse cinque ragioni, e quattro di esse si risolvono in un pomeriggio.

La velocità ripaga su tre fronti:

  • Conversioni. Sui negozi Hummingbird che gestiamo, far scendere l'LCP mediano da 4s a 2s di solito aumenta la conversione su mobile del 30–60%.
  • SEO. Google utilizza i Core Web Vitals come segnale di ranking dal 2021. I negozi lenti guadagnano meno traffico organico e pagano di più per il traffico a pagamento che serve a compensare.
  • Mobile. Il 70% del traffico e-commerce è da mobile. Una pagina che sembra accettabile su un MacBook può tradursi in 6 secondi di schermo bianco su un Android di fascia media.
La velocità è una disciplina di manutenzione, non un progetto che si conclude. Ogni modulo, ogni ritocco al tema, ogni immagine la sposta in su o in giù. Manteniamo una baseline dell'LCP per ogni negozio cliente e la controlliamo dopo ogni deploy. Consulta le nostre note sull'ottimizzazione delle prestazioni per il lavoro su database, cache e misurazione che sta dietro a questi risultati.

Misuri prima di toccare qualsiasi cosa

Il modo più rapido per sprecare una giornata è iniziare a "ottimizzare" senza numeri. Ogni negozio che analizziamo riceve prima la stessa misurazione su tre pagine (home page, categoria, prodotto) perché ognuna sollecita una parte diversa dello stack.

Gli strumenti che usiamo davvero

  • Google PageSpeed Insights: Gratuito, usa dati reali di utenti Chrome (CrUX). Eseguilo su tutti e tre i tipi di pagina. È sulle pagine di categoria e di prodotto che la maggior parte dei negozi crolla.
  • GTmetrix: Il grafico a cascata ti dice quale richiesta blocca il rendering, quale modulo spedisce 600KB di CSS inutilizzato e quale script di terze parti aggiunge 800ms prima del TTFB.
  • WebPageTest: La vista a fotogrammi da continenti e profili di connessione diversi. Usala quando GTmetrix e PSI sono in disaccordo.

Core Web Vitals: cosa Le dice ciascuno

  • LCP (Largest Contentful Paint): Il momento in cui l'elemento visibile più grande finisce di disegnarsi. Obiettivo sotto i 2,5s. Sulla maggior parte dei negozi PrestaShop è l'immagine hero o il banner di categoria, e il responsabile è il CSS che blocca il rendering più un'immagine non ottimizzata e senza preload.
  • INP (Interaction to Next Paint): Quanto velocemente la pagina reagisce a un tocco o a un clic. Ha sostituito il FID a marzo 2024. Obiettivo sotto i 200ms. I soliti sospetti: moduli appesantiti da jQuery, tag manager e gestori di clic che fanno troppo in modo sincrono.
  • CLS (Cumulative Layout Shift): Quanto la pagina sobbalza durante il caricamento. Obiettivo sotto 0,1. Causato da immagini senza width/height, banner caricati in ritardo e cambi di font senza un fallback abbinato.

Obiettivi realistici

La logica del carrello, la ricerca, i moduli e il tracciamento possono rendere più difficile raggiungere un punteggio di 100 in un vero negozio PrestaShop. I nostri obiettivi: mobile 60–80, desktop 85–95, LCP sotto i 2,5s su mobile / 1,8s su desktop, peso totale sotto i 2MB, meno di 80 richieste al primo paint.

Non inseguire un 98 togliendo ciò che ti fa guadagnare. Un 65 con una conversione sana batte un 98 su una pagina da cui non compra nessuno.

Server: dove si nasconde la maggior parte della latenza

Nessun trucco lato front-end ti salverà da un backend lento. Se PrestaShop impiega 800ms a generare l'HTML prima che parta una singola richiesta di asset, quello è il tuo limite minimo di attesa.

PHP OPcache: non negoziabile

OPcache tiene in memoria il bytecode PHP compilato così che l'interprete non debba rianalizzare gli stessi file a ogni richiesta. PrestaShop carica centinaia di file PHP per pagina. Senza OPcache, paghi quel costo di parsing ogni volta.

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 sbagliati per PrestaShop. Impostare max_accelerated_files a 20.000 ti lascia un margine. Una tipica installazione PS ha 10–15k file PHP; il valore predefinito è 10.000, arrotondato internamente per eccesso a 16.229 chiavi. memory_consumption dovrebbe essere 128–256MB. Se la cache si riempie, OPcache espelle le voci e tu perdi silenziosamente il vantaggio.

Sugli host cPanel con validate_timestamps=0, OPcache non rileggerà mai i file PHP dal disco di propria iniziativa. Devi resettarlo tramite una richiesta web dopo ogni deploy, un reset da CLI svuota solo il pool CLI, non quello web. Abbiamo debuggato ticket "la mia correzione non viene applicata" che si sono rivelati esattamente questo.

MySQL / MariaDB: l'unica impostazione che conta

Una pagina prodotto PrestaShop esegue tipicamente 80–200 query SQL. Una pagina di categoria con filtri può superare di slancio le 400. La variabile in assoluto più importante è innodb_buffer_pool_size:

[mysqld]
# Impostare al 50-70% della RAM disponibile su un server DB dedicato
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# Solo MySQL 5.7 / MariaDB (rimossa in MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Individuare le query problematiche
slow_query_log = 1
long_query_time = 1

# Impostazioni delle connessioni
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Se il tuo database è di 500MB e il buffer pool è di 1GB, la maggior parte delle query viene servita dalla RAM. Attiva lo slow query log e leggilo ogni settimana, una query che a riposo impiega 1,2s sotto traffico ne impiega 12, ed è così che il Black Friday va a rotoli. La maggior parte delle query lente che troviamo arriva dal controller di ricerca, dai filtri della navigazione a livelli sulle pagine di categoria e da moduli di statistiche che andavano disattivati anni fa.

Livelli di hosting: sia onesto con sé stesso

  • Condiviso ($5–15/mese): Condividi CPU e RAM con centinaia di vicini. Va bene per un negozio di prova da 200 prodotti, non per un'attività reale.
  • VPS ($20–60/mese): Dove si trova quasi ogni negozio che gestiamo. 4GB di RAM minimo, 2 core, SSD NVMe. Il punto ideale fino a qualche centinaio di ordini al giorno.
  • Dedicato ($80–300/mese): 1.000+ ordini giornalieri o cataloghi oltre i 100k prodotti. Anche per chiunque gestisca il proprio stack Varnish / Redis.
Se sei su hosting condiviso ed è lento, passare a un VPS decente ti compra più velocità di tutti gli altri consigli di questa pagina messi insieme. Abbiamo visto l'LCP scendere da 6s a 2,2s con il solo cambio di host, senza toccare null'altro.

PHP-FPM e Redis

Usa PHP-FPM anziché mod_php, pool di processi separato, migliore comportamento della memoria, più facile da regolare per i picchi di traffico. Usa Redis per l'archiviazione di sessioni e cache invece del filesystem. Configurazione in app/config/parameters.php:

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

Gli interruttori integrati di PrestaShop

La pagina Prestazioni nel Back Office di PrestaShop 8.

È qui che vivono la cache di Smarty, la modalità di debug, il CCC e il motore di caching. La maggior parte dell'ottimizzazione delle prestazioni parte da qui.

Pagina Prestazioni del Back Office di PrestaShop 8 con le impostazioni di Smarty, modalità di debug, CCC e cache

CCC (Combinare, comprimere, memorizzare nella cache)

In Parametri avanzati → Prestazioni. Il CCC concatena e minimizza i tuoi CSS e JS. Attivalo sempre in produzione. Cose con cui ci siamo scottati:

  • I file contrassegnati come defer o async restano separati, per scelta progettuale.
  • Le risorse esterne (Google Fonts, Stripe.js, script di Cloudflare) non vengono mai combinate.
  • I moduli che iniettano tag <link> grezzi tramite displayHeader invece di actionFrontControllerSetMedia bypassano del tutto il CCC. Ogni audit ne fa emergere almeno uno. La nostra pagina sugli hook spiega la correzione.
  • Se il CCC rompe il checkout o un widget, il modulo sta facendo qualcosa che dipende dall'ordine. Individualo, correggilo o sostituiscilo, non lasciare il CCC disattivato.

Impostazioni dei template Smarty

Imposta il caching dei template su "Ricompila i template se i file sono stati modificati" in produzione. Mai "Forza la compilazione", ricompila ogni template a ogni richiesta, la peggiore modalità Smarty possibile.

Modalità di debug: la controlli per prima cosa, ogni volta

La modalità di debug disabilita la maggior parte del caching, forza la ricompilazione e registra log in modo aggressivo. In produzione l'unico valore corretto è false:

// In app/config/defines.inc.php: DEVE essere false in produzione
define('_PS_MODE_DEV_', false);

Abbiamo ereditato negozi che giravano in debug per mesi. La "lentezza misteriosa" sparisce nell'istante in cui si capovolge il flag. Controllala sempre alla prima passata di audit.

Disabiliti i moduli che non usa

Ogni modulo attivo ti costa: voci nell'autoloader, callback degli hook, possibilmente CSS/JS su ogni pagina, possibilmente query al database anche quando non c'è nulla da mostrare. Un'installazione nuova arriva con un lungo elenco di moduli. Non ti serve la maggior parte di essi.

Scorri Moduli → Gestore moduli e disinstalla (non solo disabilitare) tutto ciò che non usi attivamente. Tre moduli di analytics che fanno lo stesso lavoro? Tienine uno. Se ti serve una passata di pulizia strutturata prima della regolazione, Cleanup Revolution aiuta a ripulire le scorie operative prima di iniziare a misurare.

Immagini: di solito il 60–80% del peso della pagina

Le vittorie sull'LCP più grandi e più facili stanno qui. Abbiamo visto l'LCP della home page scendere da 4,2s a 1,6s su un singolo negozio solo rigenerando le immagini alle dimensioni giuste e servendole in WebP.

WebP e dimensioni sensate

WebP è del 25–35% più leggero del JPEG senza perdita di qualità visibile. PrestaShop 8+ lo supporta nativamente; sulle versioni più vecchie usa una conversione lato server o un modulo.

Lo spreco più comune: file sorgente da 2000×2000px serviti in uno slot di miniatura da 300px. Configura i tipi di immagine in Design → Impostazioni delle immagini in base a ciò che il tuo tema renderizza davvero. Non caricare master da 4000px "per sicurezza". 1200Px bastano per lo zoom prodotto retina.

Caricamento lazy

Rimanda il caricamento di tutto ciò che si trova fuori dall'area inizialmente visibile:

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

Non applicare il caricamento lazy al logo dell'intestazione, al banner hero o alla prima riga di prodotti. Quelli sono candidati LCP, caricarli in lazy dice a Chrome di deprioritizzare proprio l'elemento su cui ti sta misurando. Abbiamo visto questo singolo errore costare a un negozio 1,5s di LCP. Per i cataloghi in cui i template del tema sono incoerenti, Automatic SEO Images Lazy Tags può applicare il caricamento differito fuori dall'area inizialmente visibile su larga scala.

Rigenerazione dopo una modifica

Dopo aver cambiato le dimensioni di un tipo di immagine, rigenera da Back Office o dalla CLI:

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

Ottimizzazioni front-end che spostano davvero l'ago

Riduca le richieste HTTP

Apri il tuo grafico a cascata. Oltre 100 richieste è un problema. I soliti colpevoli: ogni modulo che carica il proprio minuscolo file CSS/JS, Google Fonts con quattro pesi più il corsivo, widget di condivisione social che tirano giù i propri SDK, due tag manager che si fanno la guerra.

CSS critico

I browser bloccano il rendering finché ogni file CSS in <head> non è stato scaricato. Il CSS critico mette inline nell'HTML gli stili necessari al viewport iniziale, poi carica il foglio di stile completo in modo asincrono. Su mobile questo ci fa risparmiare regolarmente 1–2s di LCP. Performance Revolution genera il CSS critico automaticamente tramite Critters e lo mantiene sincronizzato quando il CSS del tema cambia. Farlo a mano a ogni ritocco del tema è una corvée che non si fa mai.

JavaScript: defer è Suo amico

Usa defer per quasi tutto, lo script viene scaricato in parallelo ma non viene eseguito finché l'HTML non è stato analizzato. Usa async solo per script genuinamente indipendenti come l'analytics. In PrestaShop 1.7+:

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

Font

I font personalizzati aggiungono in sordina 200–400KB. Cosa facciamo su ogni negozio:

  • Hosting autonomo invece di prelevarli da Google Fonts, risparmia una risoluzione DNS e un handshake TLS.
  • Sottoinsieme ai caratteri che servono. Solo-latino è del 60–80% più leggero dell'Unicode completo.
  • font-display: swap così il testo visibile non aspetta mai un font.
  • Due pesi al massimo. 400 e 700 coprono quasi ogni tema.
  • Solo WOFF2: migliore compressione, supporto moderno universale.
@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;
}

Le basi del CDN

Un CDN serve i file statici da server vicini ai tuoi visitatori. Cloudflare è l'ovvio punto di partenza gratuito. Indirizza immagini, CSS e JS verso il dominio del CDN tramite Parametri avanzati → Prestazioni → Server multimediali.

Ottimizzazione del database

I database PrestaShop si gonfiano in silenzio. Tabelle che al lancio andavano bene diventano macine dopo due anni di carrelli abbandonati, traffico bot e log di moduli che nessuno legge.

Pulisca i vecchi carrelli

ps_cart e ps_cart_product ricevono una riga per ogni visitatore. Incluso ogni bot che ha scansionato il catalogo. Dopo un anno queste tabelle arrivano regolarmente a milioni di righe, e ogni join contro di esse rallenta.

-- Eliminare i prodotti dei carrelli per i vecchi carrelli abbandonati (non collegati a ordini)
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);

-- Eliminare i carrelli vuoti
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);
Backup prima, staging prima. Lo schema LEFT JOIN + IS NULL è ciò che protegge i carrelli diventati ordini, se lo si sbaglia, si orfanizza la cronologia degli ordini.

Log e connessioni

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

-- Tracciamento visitatori
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);

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

-- Statistiche di ricerca, log 404, log email
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);

Indice di ricerca

Se usi Elasticsearch, Algolia o qualsiasi backend di ricerca esterno, le tabelle di ricerca integrate sono peso morto che PrestaShop continua a ricostruire:

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Ottimizzi le tabelle e aggiunga indici

Dopo grandi eliminazioni, recupera spazio:

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

Indici che abbiamo aggiunto su quasi ogni negozio che analizziamo:

-- Controllare prima gli indici esistenti: 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);

Esegui EXPLAIN sulle query del tuo slow log. Se type dice ALL, il database sta facendo una scansione completa. L'indice giusto trasforma tipicamente una query da 4 secondi in una da 12ms.

Strategie di caching

Cache a pagina intera

La singola leva più grande che hai a disposizione. Senza, ogni richiesta anonima esegue l'intero stack, centinaia di file PHP, 100+ query, 200–500ms di rendering. Con, la stessa pagina esce in 5–20ms. Sui negozi Hummingbird che gestiamo, attivare la FPC taglia tipicamente l'LCP su mobile di 1,2–1,8s sopra a tutto il resto.

Varnish è lo standard di settore. La cache FastCGI di nginx è più semplice se già usi 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 parte difficile non è attivarla, è l'invalidazione. Quando un prezzo cambia, lo stock cala o un amministratore modifica una categoria, le pagine giuste in cache devono cadere. È quella complessità il motivo per cui così tanti negozi non attivano mai la FPC. Ed è anche ciò che Performance Revolution gestisce per te su PrestaShop.

Cache degli oggetti e caching del browser

La cache degli oggetti (Redis) tiene in memoria i risultati delle query tra una richiesta e l'altra. Guadagno più piccolo della FPC (tipicamente 30–50% in meno sul tempo delle query) ma l'invalidazione è automatica, quindi è il primo passo sicuro.

Gli header di caching del browser dicono ai browser dei visitatori di tenere 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>

Le cose che distruggono le prestazioni in sordina

  • Troppi moduli attivi. Ognuno ti costa, voci nell'autoloader, callback degli hook, spesso CSS/JS, spesso query. Un negozio snello batte quasi sempre uno gonfio a parità di hardware. Nessun modulo è gratis.
  • Moduli che caricano asset su ogni pagina. Un modulo di popup che si attiva solo sulla home page ma spedisce 150KB di JS su ogni pagina prodotto è puro spreco. Scansiona il tuo grafico a cascata in cerca di percorsi di asset di moduli dove non dovrebbero esserci.
  • Slider hero. 3–5 immagini ad alta risoluzione più una libreria JS per il carosello, spesso 1–5MB in totale, per un componente con cui meno dell'1% degli utenti interagisce oltre la prima slide. Li sostituiamo con un singolo hero statico in quasi ogni riprogettazione.
  • Temi consegnati senza revisione delle prestazioni. Bootstrap completo per tre componenti, bundle non minimizzati, nessuna dimensione delle immagini, script sincroni. Chiedi agli sviluppatori del tema un punteggio Lighthouse sulla demo prima di acquistare.
  • Indici mancanti. Una query con l'indice giusto gira in 10ms; senza, la stessa query nel picco di traffico gira per 5s e mette in coda ogni richiesta dietro di sé. Non te ne accorgerai fino al Black Friday.

Checklist di monitoraggio delle prestazioni

Controlli rapidi (5 minuti)

  • PageSpeed Insights su home page, categoria, prodotto
  • _PS_MODE_DEV_ è false
  • Smarty non su "Forza la compilazione"
  • CCC attivato
  • OPcache attivo secondo phpinfo()

Manutenzione mensile (30 minuti)

  • Pulisci i carrelli abbandonati più vecchi di 3 mesi
  • Pulisci ps_log, ps_connections, ps_connections_page, ps_guest
  • Esegui OPTIMIZE TABLE sulle tabelle ripulite
  • Rivedi lo slow query log
  • Disinstalla i moduli inutilizzati

Revisione trimestrale (2 ore)

  • Test GTmetrix completo da più località, confrontato con il trimestre precedente
  • Rivedi i Core Web Vitals in Google Search Console
  • Verifica gli asset dei moduli alla ricerca di CSS/JS superflui
  • Controlla le dimensioni delle immagini per i caricamenti sovradimensionati
  • Rivedi l'uso delle risorse server (CPU, RAM, I/O del disco)
  • Prova su un vero dispositivo mobile di fascia media, non sull'emulatore di Chrome
  • Verifica che gli header di caching del browser siano ancora a posto
  • Controlla i log degli errori PHP (le eccezioni bruciano risorse anche quando nessuno le vede)

Dopo ogni deploy

  • Svuota la cache di PrestaShop
  • Resetta il pool web di OPcache se validate_timestamps=0
  • Test rapido con PageSpeed per le regressioni
  • Controlla la console del browser per errori JS
  • Percorri il checkout dall'inizio alla fine

Da dove iniziare

Quattro cose, in ordine: sistema la configurazione del server (OPcache + buffer pool InnoDB + PHP-FPM), rigenera e servi le immagini alle dimensioni giuste in WebP, disinstalla i moduli che non usi, pulisci il database. Questo copre il grosso dei problemi di prestazioni che troviamo negli audit.

Misura prima e dopo ogni modifica. Tieni un breve changelog di ciò che hai fatto e di cosa hanno fatto i numeri. L'ottimizzazione che conta è quella che i tuoi clienti sentono: pagine prodotto più veloci, un checkout reattivo. Questo si traduce in fiducia, meno abbandoni e maggiore conversione.

Letture correlate

Domande correlate

Torna su