Prestazioni PrestaShop: misura, diagnostica e migliora il negozio

Cosa faremmo per prima cosa

La correzione giusta dipende dal negozio esistente: tema, moduli, integrazioni, dati del catalogo, hosting e traffico. Due negozi con lo stesso punteggio di velocità possono richiedere modifiche opposte. Riprodurremmo la pagina lenta, separeremmo il tempo del server dal lavoro del browser e individueremmo le query, le chiamate dei moduli o gli script che consumano quel tempo. Se prevale l'SQL, prova in staging una modifica mirata alla query o a un indice prima di cambiare le impostazioni del server. Se il database attende lo storage o compete per la memoria, valuta prima il carico dell'hosting. Se il documento arriva presto ma la pagina resta lenta da usare, lavora su immagini, CSS e JavaScript.

Il percorso pratico è lo stesso per la maggior parte delle correzioni: riproduci il problema su una copia di staging isolata con dati realistici, prova lì la modifica con un modo testato per tornare indietro, rilasciala come modifica pianificata e ripeti le stesse misurazioni sul negozio live. Confronta richieste equivalenti prima e dopo ogni modifica, così ogni risultato può essere attribuito a quella modifica.

Scegli il primo test in base al sintomo

Chiedi allo sviluppatore una traccia della richiesta che indichi il lavoro costoso, il responsabile, una modifica proposta e il confronto prima e dopo. Una schermata delle dimensioni del database o un singolo punteggio di velocità non sono queste prove.

Se vuoi che questa attribuzione venga fatta per il tuo negozio, il PrestaShop Speed & Core Web Vitals Audit segue le richieste live attraverso server, database e browser e restituisce un piano di correzioni in ordine di priorità; modifiche al codice, configurazione del server e acquisti di hosting sono esclusi dal suo ambito e vengono definiti separatamente.

Stabilisci una base di riferimento e leggi le metriche corrette

Prova la homepage, una categoria molto visitata, un prodotto, il carrello e il checkout, oltre a qualsiasi schermata lenta del back office. Includi ricerca e filtri quando sono importanti per il tuo negozio. Registra URL, versione del core e di PHP, tema, moduli abilitati, dispositivo, località, profilo di connessione, stato del cliente, lingua, valuta, stato del consenso, stato della cache e condizioni di traffico.

Usa una copia di staging con dati di catalogo realistici per modifiche controllate e profiling. Esegui diversi test confrontabili e conserva la mediana e la dispersione. Confronta separatamente un nuovo visitatore, un browser di ritorno e un cliente che ha effettuato l'accesso, e includi richieste senza cache: un hit veloce della cache pubblica non dimostra che carrello o checkout siano veloci. Un accesso al back office non abilita automaticamente il profiling né rende più veloci le richieste al front office.

Gli attuali obiettivi Core Web Vitals sono LCP non oltre 2,5 secondi, INP non oltre 200 millisecondi e CLS non oltre 0,1, valutati al 75° percentile separatamente per mobile e desktop. INP ha sostituito FID a marzo 2024.

LCP riguarda il maggiore contenuto visibile idoneo, spesso un'immagine o un blocco di testo. INP riguarda la reattività alle interazioni. CLS riguarda spostamenti inattesi del layout. Diagnostica l'elemento, l'evento o lo spostamento effettivo senza supporre una causa dalla sola metrica.

Il punteggio Performance di Lighthouse è un indice composito di laboratorio, non il tuo tasso di conversione o una previsione di posizionamento. La verifica di caricamento include Total Blocking Time; un normale test di caricamento non assegna direttamente un punteggio all'INP sul campo. Accessibility, Best Practices e SEO sono categorie di verifica distinte, non certificazioni complete di questi aspetti. Leggi la spiegazione del punteggio e i singoli risultati.

L'installazione standard di GA4 non raccoglie automaticamente i Core Web Vitals né fornisce i vecchi report di velocità del sito di Universal Analytics. Aggiungi strumentazione web-vitals o RUM esplicita e gli eventi e report necessari. Segmenta per tipo di pagina, dispositivo e mercato, con controlli di privacy appropriati.

Affianca misure commerciali a quelle di velocità. Il report sul commercio al dettaglio del 2017 di Akamai associava nel suo studio un ritardo di 100 millisecondi a una riduzione delle conversioni del 7%. Quel risultato storico non è una formula per prevedere il guadagno del tuo negozio.

Isola la copia di staging e prepara un modo per tornare indietro

Isola la copia di staging prima che vengano eseguiti l'applicazione ripristinata, i worker o le attività pianificate. Assegnale un database separato, destinazioni sandbox per pagamenti e integrazioni, una casella di posta di test e un accesso esterno controllato. Limita l'accesso ai dati dei clienti copiati, così i test di prestazioni e cache non possono generare messaggi a clienti reali o operazioni commerciali.

Prima di eliminare record, aggiungere indici, ricostruire tabelle o cambiare motore o configurazione del database, esegui backup corrispondenti di file e database, prova un ripristino in staging e documenta come tornare indietro. Prova anche la modifica stessa, tenendo conto di blocchi, requisiti di spazio e interruzioni del servizio, così il rilascio live segue una procedura nota in un momento pianificato. Chiedi all'host di gestire la configurazione dove non controlli il server.

Mantieni la copia vicina alla produzione: stesse versioni di PrestaShop, PHP e database, stesso tema e stessi moduli, con dati rappresentativi. L'hardware di staging raramente corrisponde al server live, quindi usalo per confrontare il prima e il dopo, poi conferma il miglioramento sul negozio live con le stesse richieste di riferimento.

Separa tempi di connessione, lavoro del server e del browser

Il TTFB osservato dal client include attività precedenti all'arrivo del documento, come DNS, creazione della connessione, TLS, reindirizzamenti e percorso richiesta/risposta. Non è un cronometro diretto dell'esecuzione PHP. Waiting in DevTools misura un intervallo diverso. Usa la scomposizione dei tempi TTFB per interpretare lo strumento che utilizzi.

Questo esempio shell recupera una pagina e stampa i tempi cumulativi di curl. Sostituisci l'URL di esempio con un URL reale del negozio:

url='https://example.com/'
curl --silent --show-error --output /dev/null   --write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'   "$url"

Questi valori sono misurati dall'inizio del trasferimento, non sono durate indipendenti da sommare. Controlla i reindirizzamenti separatamente o registrali esplicitamente. Ripeti con stati della cache e località geografiche controllati.

Uno script browser recuperato dopo il primo byte del documento non può ritardare quel primo byte. Può ritardare rendering, interazioni o richieste successive. Un modulo PHP che effettua una richiesta API remota prima di inviare HTML può ritardare la risposta del server. Il solo waterfall del browser non può identificare quel modulo PHP.

Usa il profiler appropriato

Per il profiling legacy di PrestaShop, abilita _PS_DEBUG_PROFILING_ in config/defines.inc.php su una copia di staging ad accesso limitato:

define('_PS_DEBUG_PROFILING_', true);

Carica i tipi di pagina pertinenti ed esamina tempi SQL, chiamate ripetute, hook e memoria entro la copertura del report. Poi riporta il flag a false. _PS_MODE_DEV_ è un interruttore separato per sviluppo/segnalazione errori. Non è l'interruttore del profiling legacy né la politica di compilazione Smarty.

La toolbar Symfony copre le richieste gestite dal kernel Symfony. Il pannello Doctrine non prova la copertura completa dell'SQL legacy Db. Conferma i percorsi di database e hook strumentati prima di attribuire tutto il lavoro a un modulo.

Un controllo di URL pubblico può valutare raggiungibilità e tempi del browser. Conteggi interni delle query, rapporti di hit della cache e tempi dei moduli richiedono accesso autorizzato o strumentazione. Anche normali recuperi di pagine possono creare log, dati di analisi o voci di cache, quindi concorda ambito dei test e volume delle richieste.

Verifica le impostazioni di produzione senza confonderle

In Parametri Avanzati → Prestazioni, esamina ogni impostazione separatamente e provane l'effetto. Mantieni modalità sviluppo e profiling disattivati sul negozio pubblico in produzione.

JavaScript differito/asincrono e risorse remote possono rimanere fuori dalla normale combinazione CCC. I tag grezzi emessi da un hook possono aggirare la gestione delle risorse. Quando una modifica CCC compromette il comportamento, isola il bundle o la dipendenza interessata in staging e correggine la registrazione; non lasciare attivo un checkout guasto.

Disabilita i moduli sospetti in staging e confronta le misurazioni. I normali hook dei moduli disabilitati sono esclusi dai controlli di esecuzione del core. Disinstalla soltanto moduli realmente indesiderati dopo averne esaminato il comportamento di disinstallazione e conservato impostazioni o dati necessari.

Scegli un PHP compatibile e controlla OPcache e hosting

Usa un ramo PHP mantenuto e supportato dalla tua esatta versione di PrestaShop, dal tema e dai moduli. L'attuale matrice PrestaShop 9 consiglia PHP 8.4 per 9.0 e PHP 8.5 per 9.1. Controlla anche le date di manutenzione di PHP. Il supporto upstream di PHP 8.1 è terminato il 31 dicembre 2025. Non spostare PrestaShop 1.7.8 su PHP 8 come generica soluzione di velocità.

Conferma che OPcache sia attivo per PHP web, non soltanto per il binario da riga di comando. Memorizza bytecode compilato così le richieste ripetute evitano di analizzare nuovamente i file PHP. JIT è un'opzione separata; non supporre che spieghi le prestazioni del negozio o debba essere abilitato.

1. Esamina memoria usata/libera, stringhe internate, script e chiavi in cache con un carico rappresentativo.
2. Controlla cache_full, memoria sprecata e contatori di riavvio per memoria esaurita, hash e riavvii manuali tramite opcache_get_status() dove l'host lo permette.
3. Dimensiona memoria e capacità degli script in base a queste letture. Una cache piena può smettere di accettare script e pianificare un riavvio; non funziona come una cache semplice che elimina continuamente singole voci.
4. Documenta il comportamento al rilascio. Con opcache.validate_timestamps=1, il controllo dei timestamp segue la sua configurazione, incluso opcache.revalidate_freq. Con la convalida disattivata, i file modificati richiedono invalidazione esplicita o reset/riavvio della cache PHP web pertinente.

Un reset dalla CLI normalmente non svuota OPcache del server web. Attendere sessanta secondi non è una procedura di reset universale. Usa le impostazioni OPcache e i campi di stato per definire una politica controllata e mantieni privati gli endpoint diagnostici.

Per PHP-FPM, esamina worker occupati, code, pm.max_children, memoria dei worker e log dei timeout. Più worker possono peggiorare la pressione sulla memoria o la contesa del database. Controlla carico e steal della CPU, swapping, attesa I/O del disco e latenza del database nei periodi intensi. Strumenti come free -m, vmstat 1 5 e iostat -xz 1 5 possono aiutare l'amministratore a correlare i sintomi.

Non dimensionare l'hosting solo in base agli ordini giornalieri. Contano navigazione simultanea del catalogo, filtri, importazioni, cron, combinazioni e lavoro del checkout. Confronta uso delle risorse e tempi di risposta al picco previsto prima di cambiare host o aggiungere capacità. Consulta l'hosting PrestaShop.

Quando le prove indicano limiti di capacità o di recupero, il PrestaShop Hosting & Infrastructure Audit esamina il carico di lavoro e fornisce un parere scritto sul miglioramento dell'host attuale o sulla migrazione; gli interventi sul server e la migrazione stessa sono separati. Scegli il percorso di migrazione in base a moduli, integrazioni, tema e dati esistenti. Per un cambio di host che conserva la configurazione attuale, prova una copia isolata sul nuovo host. Se la valutazione richiede di ricostruire il negozio, il percorso sicuro abituale è un'installazione di destinazione pulita in staging, con componenti compatibili e una migrazione dei dati già provata. Pianifica la sincronizzazione finale dei dati e il passaggio definitivo, e documenta come un eventuale ripristino conserverebbe gli ordini ricevuti dopo il lancio.

Trova le query SQL lente e leggi correttamente EXPLAIN

Chiedi prima all'amministratore del database di registrare motore e versione esatti: le impostazioni di MySQL e MariaDB non sono intercambiabili. Usa il monitoraggio delle query esistente dove disponibile. Altrimenti abilita il log delle query lente del database con una soglia scelta in base ai tempi delle richieste e al carico. Per esempio, una breve finestra diagnostica potrebbe iniziare con:

[mysqld]
slow_query_log = 1
long_query_time = 0.5

Fai configurare all'amministratore del database una destinazione consentita per il log, un limite di spazio, la rotazione, il controllo degli accessi e una data di rimozione. Il testo delle query può contenere dati personali. Raccogli traffico rappresentativo e attività pianificate per il periodo di carico pertinente, invece di una durata fissa uguale per ogni negozio, poi interrompi o regola il logging dettagliato secondo necessità. Registrare le query senza indici e usare filtri sul numero minimo di righe esaminate può aiutare, ma può creare rumore e lavoro aggiuntivo oppure escludere piccole query rilevanti; la scansione di una piccola tabella non è automaticamente un errore. Controlla il comportamento del log del database per la tua versione.

Riepiloga un log con mysqldumpslow o pt-query-digest, se gli strumenti sono installati e supportano il formato del tuo log. Sostituisci il percorso con il file reale e conserva i report in una posizione ad accesso limitato:

mysqldumpslow -s t -t 20 /path/to/slow-query.log
pt-query-digest /path/to/slow-query.log

Ordina per tempo totale, numero di chiamate, righe esaminate e tempo di blocco, oltre che per la singola esecuzione più lenta: una query modesta ripetuta può costare di più, su una pagina o in un periodo di carico, di una singola query più lenta. Leggi il criterio di ordinamento del riepilogo prima di interpretarne la classifica, perché un elenco ordinato per durata media risponde a una domanda diversa da uno ordinato per tempo accumulato. Registra la query esatta, i parametri, il volume dei dati e il contesto del negozio prima dell'ottimizzazione, e oscura i dati sensibili nei report prima di condividerli.

Anche la soglia di registrazione nasconde lavoro: le query ripetute al di sotto della soglia possono mancare anche quando il loro costo complessivo è rilevante. Per esempio, ogni lettura delle recensioni potrebbe terminare sotto la soglia ma ripetersi per ogni scheda prodotto, mentre un'esportazione pianificata contribuisce con una sola query lenta isolata, estranea a quella pagina. Metti in relazione la richiesta lenta con il profiling dell'applicazione, usando una registrazione limitata invece di un logging senza restrizioni, e attribuisci entrambi i modelli ai rispettivi chiamanti prima di decidere quale modifica migliorerà la richiesta del cliente.

Usa la query reale della richiesta lenta, con il suo contesto di negozio, lingua e cliente, ed esaminane il piano su una copia di staging con dati rappresentativi. Questo esempio di categoria in sola lettura usa il prefisso predefinito, il negozio 1, la lingua 1 e la categoria 42. Mostra la forma, non la query generata dal modulo di elenco o di filtri installato. Legge prezzo e stato specifici del negozio da product_shop e limita i dati tradotti allo stesso negozio:

EXPLAIN SELECT p.id_product, pl.name, ps.price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
JOIN ps_product_lang pl ON pl.id_product = p.id_product
  AND pl.id_shop = ps.id_shop
JOIN ps_category_product cp ON cp.id_product = p.id_product
WHERE ps.id_shop = 1 AND pl.id_lang = 1
  AND cp.id_category = 42 AND ps.active = 1
ORDER BY ps.date_add DESC;

Il normale EXPLAIN stima un piano senza eseguire la query. I comandi di analisi basati sull'esecuzione possono eseguirla; verifica il comportamento del comando per il tuo motore e la tua versione prima di usarlo.

Esamina gli indici esistenti prima di aggiungerne uno. Scegli l'ordine delle colonne di un indice composito in base a predicati di uguaglianza, intervalli, ordinamento e riutilizzo del prefisso più a sinistra. Mettere prima la colonna più selettiva non è una regola universale. Gli indici aggiunti occupano spazio e aumentano il lavoro di scrittura, quindi misura il beneficio in lettura rispetto al costo in scrittura. Esegui benchmark delle modifiche allo schema in staging, prova sia l'installazione sia l'annullamento e pianifica blocchi e spazio temporaneo.

Una tabella delle recensioni interrogata per prodotto, stato di approvazione e ordine di visualizzazione mostra perché la progettazione degli indici richiede l'intero modello di accesso. Un indice adatto a quella ricerca nel front office può non essere adatto a un elenco amministrativo filtrato per negozio. Chiedi piani misurati per entrambi, e l'effetto sulle importazioni delle recensioni e sulle scritture di moderazione, prima di approvare l'indice.

Indagine guidata: una categoria filtrata lenta

1. Salva filtri selezionati, ordinamento, negozio, lingua, valuta e stato del cliente. Riproduci la richiesta senza cache su dati di staging rappresentativi.
2. Identifica le query dietro selezione dei prodotti, conteggi dei filtri a faccette, calcolo dei prezzi e aggiunte dei moduli. Separa le chiamate ripetute dalle query costose singolarmente.
3. Esamina join, restrizioni, indici esistenti e piano effettivi del modello costoso. L'esempio di categoria qui sopra mostra solo la sintassi; in questo caso decidono le query del modulo di filtri stesso.
4. Proponi una modifica alla query, un indice candidato o un intervento sul lavoro ripetuto del modulo responsabile. Provala con il backup corrispondente e il piano di ripristino già preparati.
5. Ripeti le stesse azioni di filtro e ordinamento. Confronta durata della richiesta, frequenza delle query e piani, poi verifica risultati dei prodotti, conteggi dei filtri a faccette e prezzi dei clienti.

Analizza prezzi, filtri e ricerche ripetute

Prezzi specifici e regole carrello

La selezione dei prezzi specifici dipende da prodotto, combinazione, negozio, valuta, paese, gruppo, cliente, carrello, quantità e date, con regole di priorità e ordinamento. Una fascia di quantità deve applicarsi alla quantità richiesta; from_quantity >= 1 non è un test di selezione corretto. Nell'SQL diagnostico racchiudi tra apici inversi le colonne data riservate, come `from` e `to`. Profila la chiamata nativa di calcolo dei prezzi invece di sostituirne la selezione con una ricerca incompleta, e non incollare in produzione una query o un indice sui prezzi preso da un altro negozio: un esempio incompleto può produrre un risultato commerciale sbagliato.

Rivedi le promozioni inattive o scadute secondo la tua politica commerciale. Le selezioni pertinenti delle regole carrello nel core filtrano già stato attivo e date, quindi non servono contemporaneamente disattivazione e data passata solo per escludere una regola. Conserva le regole ancora necessarie per ordini, report o campagne valide.

Misura la valutazione delle regole con carrelli rappresentativi. Prima di consolidare regole sovrapposte, fai confermare a chi gestisce le promozioni le combinazioni previste e il comportamento alla scadenza, poi prova di nuovo sconti e totali con carrelli idonei e non idonei.

Conteggi dei filtri e ricerca

Profila l'implementazione installata della ricerca a faccette e le sue query di conteggio reali. Non presumere una query per ogni possibile valore di filtro. Confronta i conteggi richiesti con i filtri che i clienti usano davvero e verifica se aiuta ridurre le faccette inutilizzate, correggere un indice o usare la cache propria dell'integrazione. Rimuovere un filtro utile solo per migliorare un benchmark cambia il percorso d'acquisto.

Usa l'operazione di indicizzazione supportata quando serve ricostruire. PrestaShop 9.1 ha aggiunto un comando di ricerca con opzioni di ricostruzione completa e ambito del negozio:

php bin/console prestashop:search:index --full --shop-id=1

Controlla la guida del comando installato prima di usarlo su un'altra versione. L'indicizzazione dal back office è l'alternativa per versioni prive del comando. Un motore di ricerca esterno può comunque avere utilizzatori nativi o fallback; non troncare le tabelle di ricerca native solo perché è installato un altro motore.

Lavoro N+1

Un hook di elenco che interroga le recensioni per ogni prodotto ripete il lavoro al crescere dei risultati. Quando la funzione lo consente, raccogli gli ID prodotto, recupera dati aggregati con un'unica query correttamente delimitata e riusali nel rendering. Includi titolarità del negozio e condizioni di visibilità, convalida gli ID e gestisci l'elenco vuoto. Confronta anche il risultato oltre al numero di query.

Chiedi una proposta di raggruppamento delle query che spieghi come vengono raccolti gli ID prodotto dell'elenco, come l'hook di visualizzazione riutilizza i risultati e perché questo riutilizzo non può mescolare negozi o valori specifici del cliente. Controlla l'hook esatto e i dati di prodotto disponibili per il modulo e la versione installati. Mantieni la correzione nel modulo responsabile o nei suoi punti di estensione supportati, così sopravvive agli aggiornamenti. Il numero di prodotti, regole o moduli installati non è un motivo automatico per eliminare o sostituire qualcosa.

Per il lavoro con API remote, confronta prima il tempo del database con le attese delle API esterne: una chiamata lenta a un fornitore o a un ERP richiede una correzione diversa da un indice mancante. Registra il comportamento in caso di timeout ed errore. Memorizza in cache e aggiorna i dati al di fuori della richiesta del visitatore quando i requisiti di aggiornamento lo consentono. Tariffe del checkout, disponibilità o controlli di pagamento possono richiedere dati attuali, quindi non rimuovere controlli in tempo reale necessari solo per migliorare un benchmark.

Regola memoria e durabilità del database in base alle misurazioni

Il buffer pool di InnoDB memorizza in cache le pagine di dati e di indici. Dimensionalo tenendo conto del sistema operativo, dei worker PHP, di Redis e dei buffer delle connessioni al database: un pool più grande può danneggiare il negozio se il resto del server inizia a usare lo swap. Un host dedicato al database e un host combinato web/database richiedono budget diversi, non una percentuale fissa della memoria installata. Le dimensioni del database da sole non dimostrano che l'insieme di dati attivo ci stia.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Prendi due campioni in un intervallo rappresentativo. Usa le variazioni tra i campioni per i contatori cumulativi di letture del buffer pool, query lente e tabelle temporanee. Leggi Threads_connected come numero attuale di connessioni e Max_used_connections come numero massimo di connessioni simultanee dall'avvio o dall'ultimo reset pertinente; le loro differenze non misurano il carico delle connessioni. Se la variazione delle richieste di lettura è diversa da zero, hit_ratio_percent = (1 - delta_reads / delta_read_requests) * 100, dove delta_reads è la variazione di Innodb_buffer_pool_reads e delta_read_requests la variazione di Innodb_buffer_pool_read_requests. Scarta gli intervalli che comprendono un riavvio del server o un reset dei contatori e confronta carichi equivalenti invece di totali raccolti da date di riavvio diverse. Un rapporto alto può coesistere con query costose e un rapporto più basso non giustifica automaticamente più RAM. Metti in relazione letture fisiche, latenza dello storage e pressione sulla memoria; una cache più grande può migliorare le letture ripetute senza risolvere una scrittura di lunga durata o un'attesa di blocco.

Mantieni innodb_flush_log_at_trx_commit=1 come normale impostazione durevole. Impostarlo a 2 può far perdere transazioni confermate di recente dopo un crash del sistema operativo o un'interruzione di corrente. Non scambiare la durabilità degli ordini con un guadagno di ottimizzazione non misurato; qualsiasi proposta di indebolire lo scaricamento dei commit richiede una decisione commerciale esplicita su perdita di dati e recupero.

Usa una configurazione specifica per la versione. MySQL 8 ha rimosso la query cache. MariaDB mantiene una propria implementazione, ma verifica contesa e beneficio sul carico prima di abilitarla, e non cambiare motore solo per la velocità. MariaDB 10.6 ha rimosso innodb_buffer_pool_instances. MySQL 8.0.30 ha introdotto innodb_redo_log_capacity al posto della vecchia prassi di dimensionamento del redo log; usa la documentazione attuale sul redo log e le variabili supportate dal tuo server.

Non incollare in ogni server valori universali per thread di I/O, connessioni, sort buffer o tabelle temporanee. Le allocazioni per connessione e la concorrenza possono esaurire la memoria, e aumentare insieme buffer e limiti di connessione moltiplica questo rischio sotto carico. Mantieni disponibile Performance Schema per la diagnosi, salvo che vincoli misurati giustifichino una modifica; regola la strumentazione invece di disattivarla come regola generale in produzione. Usa le sue query di monitoraggio solo quando la strumentazione necessaria è disponibile. Esamina Table_locks_waited insieme alla diagnostica dei blocchi specifica del motore; non è una misura completa delle attese di blocco di riga di InnoDB.

Per ogni modifica proposta, chiedi all'host l'impostazione attuale, il vincolo misurato, il valore proposto, il beneficio atteso e la procedura per annullarla. Su un server condiviso con PHP, un aumento del buffer pool deve lasciare spazio ai worker PHP occupati e alle importazioni. Su un host dedicato al database contano comunque latenza dello storage, connessioni simultanee e attività di backup.

Pulisci le tabelle solo secondo una politica di conservazione concordata

Misura la crescita delle tabelle e la conservazione separatamente dall'ottimizzazione delle query, ed esamina la crescita insieme ai costi reali delle query e alle dimensioni dei backup. L'attività dei visitatori e la creazione di carrelli dipendono dalle funzioni abilitate e dal comportamento. Esistono già alcuni percorsi di pulizia specifici, tra cui la pulizia delle pagine di connessione. Usa la guida alla manutenzione del database per una conservazione di carrelli, ospiti e log che tenga conto delle dipendenze.

Vecchi dati delle visite, ricerche, log delle email, carrelli abbandonati e regole di prezzo scadute possono essere candidati, ma controlla prima le dipendenze di reportistica, assistenza, recupero dei carrelli e integrazioni, e concorda cosa conservare con le persone che usano quei record. Un vecchio carrello senza ordine non è automaticamente sicuro da eliminare. La conservazione è una decisione commerciale, non un numero universale di giorni.

Con backup, un'esecuzione testata in staging e un piano di ripristino pronti, Database Cleanup offre aree selezionabili, periodi di conservazione, un'anteprima delle righe e una simulazione prima della rimozione. Non tocca ordini, account dei clienti, prodotti attivi e carrelli collegati a ordini, e in multinegozio limita la pulizia ai negozi selezionati. Se il problema comprende anche immagini orfane e file inutilizzati, Cleanup Revolution aggiunge queste aree, pulizie con anteprima, impostazioni di conservazione e un limite di righe per esecuzione. Le immagini rimosse restano recuperabili in un cestino datato per un periodo a tua scelta, il che non è una promessa di recupero per ogni record eliminato, e gli account senza ordini richiedono una doppia conferma separata. Scegli lo strumento in base all'ambito della manutenzione invece di installarli entrambi per impostazione predefinita.

Visualizza in anteprima i candidati esatti, approva un primo lotto controllato, poi controlla il comportamento del front office, il numero di candidati e lo storico delle esecuzioni prima di pianificarne altre. Le aree protette di uno strumento di pulizia non sostituiscono il tuo backup. InnoDB può riutilizzare lo spazio liberato, ma eliminare righe non restituisce necessariamente spazio al sistema operativo, e ricostruire una tabella può richiedere spazio aggiuntivo e blocchi. Un OPTIMIZE TABLE di routine dopo ogni pulizia non è necessario e svuotare l'indice di ricerca non è manutenzione ordinaria; se la ricerca va ricostruita, usa l'operazione di indicizzazione supportata dalla tua versione.

Riduci il lavoro di immagini, fogli di stile e JavaScript

Esamina l'elemento LCP effettivo e la catena delle richieste. Adatta le dimensioni delle immagini generate alla dimensione visualizzata, alla densità del dispositivo e alle esigenze di zoom. Non esiste un limite universale per le immagini sorgente né un risparmio di formato garantito. Riserva le dimensioni delle immagini per ridurre gli spostamenti e carica tempestivamente quelle visibili prioritarie, differendo le immagini fuori schermo appropriate.

Rigenera le miniature interessate dopo aver cambiato i tipi di immagine. Prima esegui un backup delle immagini. In PrestaShop 9.1+, php bin/console prestashop:thumbnails:regenerate products --delete elimina le miniature prodotto esistenti prima di ricostruirle. Esegui le ricostruzioni consistenti fuori dai picchi. Per riprendere un'esecuzione interrotta, ometti --delete così i file esistenti vengono conservati e quelli mancanti generati. Le versioni precedenti richiedono il back office supportato o uno strumento fornito separatamente. Il salvataggio WebP è iniziato in 8.0; la generazione multiformato, incluso AVIF, è arrivata in 8.1 come funzione sperimentale. Conferma il supporto di server e tema ed esamina il formato consegnato al browser. Consulta l'ottimizzazione delle immagini.

Il CSS critico è l'insieme di stili necessari per il viewport iniziale. Generalo per pagine e stati responsive rappresentativi, incorpora il sottoinsieme convalidato e carica opportunamente il CSS restante. Conserva gli stili di ripiego e prova menu, banner di consenso, varianti linguistiche e contenuti inseriti dinamicamente. Un'estrazione incompleta può causare lampeggiamenti, spostamenti o controlli mancanti.

Riduci CSS e JavaScript inutilizzati con misurazioni su tutti gli stati necessari. La copertura di un solo viewport iniziale non prova che sia sicuro rimuovere un selettore. Confronta uno slider con un'immagine principale statica quando il comportamento dello slider aggiunge poco valore, poi prova il risultato reale.

Per gli script esterni classici, defer rimanda l'esecuzione al completamento del parsing conservando l'ordine degli script differiti; async serve per attività indipendenti il cui ordine di completamento può variare. Nessuno dei due elimina il costo di esecuzione. L'opzione di registrazione JavaScript di PrestaShop è al plurale:

['position' => 'bottom', 'priority' => 200, 'attributes' => 'defer']

Passa queste opzioni a registerJavascript() quando registri una risorsa di tua proprietà. Registrala soltanto sulle pagine che ne hanno bisogno. Prova dipendenze e tutte le interazioni interessate dopo aver cambiato ordine o tempi. Consolida i tracker duplicati e subordina correttamente al consenso i servizi non essenziali.

Controlla font, icone e tema

1. Filtra Network per Font con cache del browser disabilitata. Registra file, dimensioni trasferite e fogli di stile che avviano le richieste.
2. Esamina stili calcolati e Coverage tra tipi di pagina e interazioni per identificare famiglie, pesi, stili e icone usati.
3. Cerca nelle risorse registrate, negli import CSS e nei template del tema attivo. I temi basati su Classic normalmente usano templates/_partials/head.tpl; i temi personalizzati possono differire.
4. Rimuovi risorse superflue dal sorgente mantenuto del tema o da un tema child. Controlla tutte le lingue supportate, i simboli delle valute e i contenuti dinamici.

Classic e Hummingbird includono dichiarazioni del font Material Icons. Esamina il CSS consegnato prima di supporre che uno dei due temi abbia eliminato i font di icone. Esamina la versione esatta e le librerie aggiunte dai moduli. Un sottoinsieme o icone SVG selezionate possono ridurre le risorse inutilizzate, ma conserva i simboli necessari e le etichette accessibili.

Richiedi soltanto i pesi e i caratteri dei font che usi. WOFF2 e sottoinsiemi scelti con attenzione possono ridurre i trasferimenti; il risparmio dipende da font e lingue. Una sequenza di font di sistema evita download aggiuntivi di web font. Per esempio:

font-family: system-ui, -apple-system, "Segoe UI", sans-serif;

Per i font che mantieni, scegli una politica font-display appropriata. swap mostra il testo di ripiego durante il caricamento del font, ma le metriche possono cambiare e causare spostamenti. Allinea le metriche del font di ripiego dove possibile e prova il layout. Per Google Fonts, richiedi esplicitamente display=swap quando desiderato ed esamina il CSS restituito; non è universale su ogni URL API. Consulta le indicazioni della Fonts API.

Ospitare autonomamente file di font concessi in licenza evita la richiesta di font al fornitore remoto e può riutilizzare la connessione alla tua origine. Il caricamento remoto richiede comunque una valutazione appropriata della privacy. La causa Google Fonts di Monaco di gennaio 2022 ha assegnato EUR 100 di risarcimento civile, non una sanzione amministrativa, come spiega l'autorità della Bassa Sassonia.

Per confrontare temi, usa gli stessi dati e impostazioni di staging, un tema predefinito compatibile e stati della cache registrati. Cambiare tema modifica anche funzioni e presentazione dei moduli, quindi la differenza è un esperimento, non una contabilizzazione esatta di tutti i costi del tema. Disabilita singoli effetti, font o componenti per circoscrivere ulteriormente. Mantieni le modifiche in un tema child dove appropriato.

In una traccia Performance, esamina i task JavaScript lunghi e i relativi stack di chiamate. Usa gli eventi Layout/Recalculate Style e la diagnostica dei reflow forzati per il layout thrashing. Le sole marcature rosse non lo dimostrano. Usa il riferimento sulle prestazioni di DevTools per interpretare la traccia.

Controlla cosa eseguono e caricano realmente i moduli

Crea un inventario per pagina di CSS/JS dei moduli, dimensioni trasferite e decodificate, richieste, chiamate query, esecuzione server e widget che richiedono queste risorse. La sola registrazione degli hook o il numero di moduli non indica il costo.

In un contesto a negozio singolo, Design → Posizioni mostra le registrazioni degli hook. Abilita Mostra gli hook non posizionabili per includere hook di azione come actionFrontControllerSetMedia insieme agli hook di visualizzazione come displayHeader. Il core supporta eccezioni per controller nelle registrazioni degli hook e un modulo può registrare risorse in modo condizionale. Un hook senza HTML visibile può comunque eseguire un'inizializzazione necessaria.

Filtrare Network per /modules/ è un buon punto di partenza. Non rileva risorse combinate tramite CCC o tema, risorse remote e file generati dinamicamente. Risali agli iniziatori e ai contenuti dei bundle; disabilita temporaneamente CCC in staging per un test diagnostico quando necessario.

1. Trova le risorse e le chiamate server costose sulla pagina lenta.
2. Controlla dove compaiono le loro funzioni. Recensioni e pulsanti della lista desideri possono legittimamente richiedere risorse negli elenchi di categoria.
3. Blocca un URL di risorsa individuato con precisione per un esperimento nel browser, poi esamina i malfunzionamenti. Bloccare il dominio condiviso del negozio non isola un modulo.
4. Disabilita un modulo sospetto in staging e ripeti gli stessi test. Il blocco nel browser non rimuove il lavoro degli hook sul server; anche disabilitare un modulo cambia il comportamento della pagina.
5. Preferisci correggere la registrazione condizionale nel modulo. Usa eccezioni degli hook o logiche di deregistrazione/nuova registrazione solo dopo aver verificato dipendenze e inizializzazione.
6. Ricontrolla interazioni di prodotto, categoria, account, carrello, checkout, consenso e mobile.

Mantieni attive le funzioni utili riducendone il lavoro superfluo. Non esiste un budget universale di dieci millisecondi per modulo né una percentuale di risparmio garantita da una verifica.

Scegli il livello di cache e prova idoneità e invalidazione

Aggiungi la cache dove le misurazioni mostrano lavoro ripetuto che può essere riutilizzato in sicurezza. Una nuova cache cambia il carico di lavoro; non elimina la necessità di misurare e di mantenere sano il percorso senza cache.

Integrazione Redis

Installa un vero servizio Redis, il supporto PHP necessario e l'adattatore che collega il percorso di cache desiderato. L'impostazione ps_caching deve indicare un adattatore di cache applicativa installato; non configura l'archiviazione delle sessioni. Un adattatore personalizzato usato con Performance Revolution si chiama MPRCacheRedis; usa la procedura di installazione supportata dall'implementazione.

Configura separatamente l'archiviazione delle sessioni PHP o Symfony, inclusa la politica di blocco e gestione degli errori. Cookie dei clienti e sessioni PHP sono meccanismi diversi e passare a Redis non elimina intrinsecamente i blocchi.

Le API di scrittura del database del core possono richiamare l'invalidazione dell'adattatore quando la cache è abilitata. SQL diretto, importazioni esterne e cache gestite dai moduli possono seguire altri percorsi. Prova gli aggiornamenti di prezzi, disponibilità, prodotti, categorie e configurazione attraverso ogni percorso di scrittura che usi. Redis di per sé non sa quali pagine o risultati di query di PrestaShop sono diventati obsoleti. Prova anche scadenza, richieste simultanee e comportamento quando il servizio Redis non funziona.

La pagina di aiuto di Redis Cache Manager & Monitor tratta i controlli di connessione, la gestione delle chiavi e gli interruttori separati per dati memorizzati, sessioni e pagine per gli ospiti. Serve un servizio Redis funzionante; prova in staging ogni integrazione abilitata, l'invalidazione e il comportamento in caso di errore.

Cache di pagina intera

Un nuovo visitatore con browser a cache fredda può ricevere un hit da una cache di pagina condivisa calda. Gli hit idonei possono evitare lavoro costoso del database e ridurre il TTFB anche se il percorso di query sottostante è lento. Miss e richieste escluse/private richiedono comunque un'applicazione sana.

Un modulo applicativo esegue comunque PHP sul proprio percorso di cache. Un reverse proxy esterno o una cache FastCGI correttamente configurati possono aggirare PHP per gli hit. Tratta i loro tempi come misurazioni diverse. Imposta una politica di idoneità esplicita che copra metodo della richiesta, controller risolto, parametri di query, host/negozio, lingua, valuta e ogni fattore che influisce sull'output pubblico.

Escludi risposte di carrello, checkout, account, login, back office, API, AJAX e personalizzate, salvo che un meccanismo di isolamento appositamente progettato le gestisca. Rispetta risposte private/no-store e comportamento di impostazione dei cookie. Una lista di frammenti URL inglesi da bloccare non rileva percorsi tradotti e controller nella query string.

Prova con due browser e diversi stati cliente. Verifica chiavi di cache, variazioni di consenso e che contenuti privati non passino mai tra visitatori. Prova l'invalidazione per modifiche prodotto, prezzi, disponibilità, categorie, inizio/fine promozioni e importazioni esterne. Un TTL è una tolleranza deliberata all'obsolescenza, non un'invalidazione completa.

Lo svuotamento basato su tag e i frammenti dinamici possono aiutare, se implementati. ESI, idratazione nel browser e sostituzione di segnaposto in PHP sono tecniche diverse. Per cache applicativa supportata, segnaposto lato server, obiettivi di CSS critico e copertura del profiling, consulta la pagina di aiuto di Performance Revolution. Il modulo misura anche la velocità reale delle pagine per i clienti e può servire le pagine pubbliche idonee tramite Cloudflare (opzionale), con copie pubbliche distinte per lingua, valuta, paese e dispositivo e rinnovo delle pagine interessate quando cambiano prezzi o disponibilità; carrelli, checkout, account e visite con accesso effettuato usano il negozio live. Verifica in staging la compatibilità con la tua cache esistente, il tema e le integrazioni personalizzate.

Checklist di accettazione della cache

• Preriscalda una pagina prodotto pubblica idonea, poi cambiane prezzo e disponibilità tramite i normali percorsi di aggiornamento del negozio, incluse le importazioni ERP o di massa dove usate. Controlla quando si aggiorna la copia pubblica.
• Cambia lingua, valuta e paese di destinazione. Prova prezzi per gruppi di clienti e visualizzazioni personalizzate dei prezzi; escludi una pagina o un contesto per cui non puoi dimostrare in sicurezza la corretta variazione.
• Aggiungi al carrello, accedi e apri pagine dell'account e del checkout. Verifica che i contenuti personali siano corretti per ogni visitatore e che le risposte private non vengano riutilizzate.
• Prova in staging la scadenza, i miss simultanei della cache e il guasto del servizio di cache. Verifica che il ripiego resti corretto e che il ripristino del servizio non sovraccarichi l'origine.
• Registra quale livello gestisce ogni risposta in cache e come invalidarla. Verifica che un altro proxy o CDN non possa conservare una copia dopo l'aggiornamento della cache applicativa.

Cache statica e preriscaldamento

Voci fresche nella cache del browser possono evitare un viaggio di rete. La convalida ETag normalmente effettua una richiesta condizionale. Usa scadenze lunghe solo con una strategia adatta di rilascio delle risorse versionate; uno svuotamento lato server non può cancellare la cache di tutti i browser dei visitatori. Una CDN può servire risorse pubbliche vicino ai visitatori, ma verifica TLS, CORS per i font, header di cache e invalidazione.

Svuota soltanto i livelli interessati tramite strumenti supportati. Preriscalda le pagine idonee importanti dopo un rilascio con concorrenza e carico limitati. Non supporre che abilitare la cache dei template renderizzati sposti i file PHP dei template compilati su Redis. Il preriscaldamento dell'origine e quello dei nodi CDN sono attività distinte e il riscaldamento può aggiungere carico. Confronta test intenzionalmente a freddo e a caldo senza nascondere la differenza.

La guida a cache di pagina intera, Redis e CDN approfondisce questi livelli.

Gestisci combinazioni e lentezza del back office

La capacità del catalogo dipende da combinazioni, associazioni, immagini, caratteristiche, filtri, prezzi e importazioni oltre che dal numero di prodotti. Non esiste un unico limite pratico al numero di prodotti per tutti i negozi. Esegui test di carico su una copia di staging con dati e traffico realistici.

Sei taglie, otto colori e cinque finiture producono 240 combinazioni se vengono generate tutte. Esamina gli insiemi maggiori con queste query in sola lettura, sostituendo il prefisso predefinito se necessario:

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
ORDER BY combinations DESC
LIMIT 20;

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC
LIMIT 20;

La query delle righe di disponibilità conta le righe memorizzate nei loro diversi ambiti; non è un totale di disponibilità isolato per negozio. Esamina titolarità del negozio/gruppo quando la interpreti.

Rimuovi varianti impossibili, riduci dimensioni superflue o suddividi un prodotto molto grande quando è adatto al comportamento d'acquisto. Opzioni che non richiedono disponibilità o prezzi indipendenti possono adattarsi meglio alla personalizzazione o a un configuratore. Ricontrolla conseguenze su URL, immagini, prezzi e disponibilità prima di cambiare modello.

Form di grandi dimensioni e importazioni possono raggiungere max_input_vars, post_max_size, limiti di memoria o timeout delle richieste. Suddividi sincronizzazioni delle disponibilità e importazioni in lotti e ricostruisci gli indici di ricerca/filtri interessati con strumenti supportati dopo modifiche sostanziali.

Analizza separatamente le schermate amministrative. Se è lenta solo la dashboard, prova statistiche, feed e widget opzionali. Se è lento Module Manager, esamina metadati e richieste ai servizi remoti. Le integrazioni Marketplace dipendono da versione e installazione; Marketplace non è incluso nel progetto open source dalla versione 8.

Se sono lenti sia front office sia back office, esamina le risorse condivise di PHP, database e hosting. Quel sintomo non prova che il database sia gonfio. Controlla directory di cache scrivibili, ricostruzioni ripetute, OPcache, code dei worker, latenza del database e hook dei moduli pertinenti prima di rimuovere dati.

Dimensiona le operazioni sul carico misurato

Monitora separatamente infrastruttura, precisione dell'inventario e carico di lavoro del personale. Il numero mensile di ordini non determina un livello di hosting né rende obbligatoria la cache di pagina intera. Rapporti traffico/ordini e picchi di concorrenza variano.

Cronometra le attività ricorrenti: gestione stati, prelievo, spedizione, messaggi clienti, resi ed esportazioni contabili. Come esempio di pianificazione, 100 ordini mensili che richiedono sei minuti ciascuno consumano dieci ore di lavoro al mese. Usa i tempi da te misurati e includi la gestione delle eccezioni prima di decidere cosa automatizzare.

Mantieni distinti lo stato nativo dell'ordine, le notifiche ai clienti e lo stato interno del flusso di lavoro di qualsiasi modulo. Advanced Order Fulfilment può collegare gli eventi ai propri passaggi di lavoro, team e promemoria; verifica separatamente le transizioni di stato native e le email di spedizione ai clienti.

Usa il flusso nativo del Servizio clienti per i messaggi che riceve effettivamente. Un modulo separato per i form può memorizzare i propri invii e le proprie notifiche, quindi verifica qualsiasi integrazione con l'helpdesk. Per l'instradamento specifico dei form, consulta la pagina di aiuto di Better Contact Form.

Riconcilia le disponibilità tra ordini, resi e altri canali di vendita. Esamina azioni di massa sugli ordini ed esportazioni filtrate, inclusi permessi ed effetto sulle notifiche. Assegna a imballatori, addetti all'assistenza e amministratori account individuali con accessi appropriati al ruolo.

Separa host database e web solo quando le misurazioni giustificano risorse indipendenti. Considera latenza di rete, connettività sicura, backup/ripristino, impostazioni di connessione e test del rilascio. Una sola modifica di configurazione non è un piano completo di migrazione. Includi personale, software, infrastruttura, commissioni e resi nel valutare il margine degli ordini aggiuntivi.

Mantieni una routine di monitoraggio e rilascio

• Registra test di laboratorio ripetibili e metriche di utenti reali per tipi di pagina rappresentativi, insieme al comportamento di hit/miss della cache.
• Monitora disponibilità, errori, code dei worker PHP, CPU, memoria, I/O, latenza query, connessioni e capacità delle cache. Imposta avvisi rispetto alla base di riferimento.
• Esamina riepiloghi delle query lente, crescita delle tabelle e conservazione. Usa strumenti come PMM o una dashboard del database quando adatti alle tue esigenze operative; anche i suggerimenti automatici richiedono prove sul carico.
• Dopo una modifica a moduli, tema o catalogo, un'importazione consistente o un cambiamento del traffico, confronta risorse, chiamate, carico delle query e interazioni con la base di riferimento. Conserva i report completi e un breve registro delle modifiche.
• Durante il rilascio, svuota i livelli PrestaShop interessati, applica la politica documentata di OPcache web, invalida le risorse modificate e preriscalda solo entro un budget controllato.
• Controlla dall'inizio alla fine errori del browser, visualizzazione delle immagini, navigazione, filtri, carrello, pagamento e conferma, e verifica che prezzi, disponibilità e integrazioni si comportino ancora come prima.
• Esamina le tendenze sul campo dopo aver raccolto dati sufficienti. Non giudicare un report su una finestra mobile di dati sul campo da un solo test di laboratorio o da pochi giorni.

Scegli la modifica successiva in base a costo misurato, rischio e impatto sul cliente. Ripeti il test dopo la modifica e conserva un percorso di ripristino. Un benchmark più veloce è utile solo quando catalogo, prezzi, scelte di privacy e checkout continuano a funzionare correttamente.

Domande dei titolari prima di investire nella velocità

Dobbiamo prima comprare più memoria o un piano più grande? Chiedi quale attesa misurata eliminerebbe e di cosa hanno bisogno gli altri servizi sul server. Più memoria non corregge una query lenta, una chiamata esterna o il lavoro del browser.

Una tabella grande ha bisogno di un altro indice? Solo se un modello di accesso reale ne trae un beneficio sufficiente a giustificare il costo in spazio e scrittura. Prova l'indice candidato sul carico reale in staging.

Dobbiamo pulire prima il database? Solo dove un costo misurato lo indica, come una tabella in crescita dentro una query lenta o una finestra di backup, e solo secondo una politica di conservazione concordata.

Possiamo iniziare dalla cache? Valutala quando l'opportunità misurata è il lavoro pubblico ripetuto. Mantieni corretti i percorsi privati, prova l'invalidazione e conserva un percorso senza cache accettabile; l'ordine delle modifiche segue le prove.

Quando dovremmo ripetere la verifica? Dopo modifiche rilevanti a moduli o catalogo, importazioni, cambiamenti del traffico o un peggioramento nei percorsi registrati. Mantieni un monitoraggio sufficiente per accorgerti di questi cambiamenti.