Magento 2 lento: 15 controlli da fare prima di cambiare server
Un Magento 2 lento non significa necessariamente che il server sia sottodimensionato.
Quando un ecommerce impiega diversi secondi per generare una pagina, il primo impulso è spesso aumentare CPU e RAM, passare a un server più potente o cambiare provider.
In alcuni casi è necessario. In molti altri significa semplicemente spostare il problema su un’infrastruttura più costosa.
Le performance di Magento 2 dipendono da numerosi componenti: PHP, database, cache, Redis, Varnish, OpenSearch, cron, indexer, moduli di terze parti, codice custom, frontend e servizi esterni.
Prima di cambiare server conviene quindi individuare il vero collo di bottiglia.
Ecco 15 controlli da effettuare quando Magento 2 è lento.
Perché Magento 2 può diventare lento?
Magento è una piattaforma ecommerce complessa.
Una singola richiesta può coinvolgere:
- PHP;
- database MySQL/MariaDB;
- cache;
- Redis;
- Varnish;
- OpenSearch;
- filesystem;
- sessioni;
- moduli custom;
- estensioni di terze parti;
- API esterne;
- frontend JavaScript;
- immagini e contenuti statici.
Per questo una diagnosi basata semplicemente sull’utilizzo della CPU è spesso insufficiente.
Bisogna innanzitutto distinguere tra due problemi molto diversi:
backend lento: Magento impiega troppo tempo a generare la risposta;
frontend lento: il server risponde velocemente, ma il browser impiega troppo tempo a visualizzare la pagina.
Questa distinzione restringe immediatamente il campo di ricerca.
1. Misurare il TTFB
Il primo parametro da controllare è il Time to First Byte (TTFB).
Indica quanto tempo trascorre prima che il browser inizi a ricevere la risposta dal server.
Un TTFB elevato può indicare problemi relativi a:
- PHP;
- database;
- cache;
- chiamate esterne;
- codice applicativo;
- infrastruttura.
Se invece il TTFB è buono ma la pagina appare lentamente, il problema potrebbe essere principalmente frontend.
Prima di ottimizzare bisogna quindi misurare dove viene perso il tempo.
2. Verificare che Magento sia in Production Mode
Sembra banale, ma è uno dei primi controlli da effettuare.
Magento dovrebbe essere eseguito in modalità:
bin/magento deploy:mode:show
In produzione il risultato dovrebbe essere:
Current application mode: production
Utilizzare Developer Mode su un ambiente pubblico può peggiorare sensibilmente le performance.
3. Controllare la Full Page Cache
La Full Page Cache (FPC) è fondamentale per le performance di Magento.
È possibile controllarne lo stato con:
bin/magento cache:status
La cache deve essere attiva e correttamente configurata.
Se una pagina teoricamente cacheabile viene continuamente rigenerata da PHP, il carico applicativo aumenta enormemente.
Un problema particolarmente insidioso è rappresentato dai moduli custom che rendono accidentalmente non cacheabili intere pagine.
4. Verificare Varnish
Su installazioni con traffico significativo, Varnish può ridurre drasticamente il numero di richieste che raggiungono PHP.
Ma non basta installarlo.
Bisogna verificare che stia realmente servendo le pagine dalla cache.
È utile controllare:
- HIT/MISS;
- TTL;
- header HTTP;
- invalidazioni;
- configurazione VCL;
- pagine escluse dalla cache.
Una configurazione Varnish formalmente attiva ma con una percentuale elevata di MISS offre benefici molto inferiori alle aspettative.
5. Controllare Redis
Magento può utilizzare Redis per diversi tipi di dati, tra cui cache e sessioni.
Occorre verificare:
- configurazione;
- memoria disponibile;
- eviction;
- latency;
- connessioni;
- utilizzo effettivo da parte di Magento.
Redis non rende automaticamente veloce Magento.
Un Redis saturo, mal configurato o collocato su un’infrastruttura con elevata latenza può diventare esso stesso un collo di bottiglia.
6. Analizzare le query SQL lente
Il database è uno dei primi componenti da analizzare quando Magento rallenta.
È importante identificare:
- slow query;
- query ripetitive;
- query prive di indici adeguati;
- lock;
- tabelle molto grandi;
- operazioni custom particolarmente costose.
Il problema può provenire dal core, ma molto frequentemente deriva da:
- estensioni;
- personalizzazioni;
- integrazioni;
- collection Magento utilizzate male.
Una singola funzionalità custom può generare centinaia di query inutili durante la costruzione di una pagina.
7. Controllare dimensione e stato delle tabelle
Un database Magento utilizzato per anni può accumulare grandi quantità di dati.
È opportuno controllare la crescita di tabelle relative a:
- log;
- quote;
- sessioni;
- cron;
- report;
- integrazioni;
- moduli custom.
Il problema non è semplicemente avere un database grande.
Bisogna individuare quali tabelle stanno crescendo, perché stanno crescendo e come vengono interrogate.
Aggiungere RAM al database senza analizzare questi aspetti può soltanto rimandare il problema.
8. Verificare indexer e cron
Magento utilizza intensivamente processi asincroni.
Controlliamo gli indexer:
bin/magento indexer:status
e il cron:
bin/magento cron:run
Index non aggiornati, cron bloccati o job estremamente lunghi possono avere effetti sull’intero sistema.
È importante analizzare:
- durata dei job;
- frequenza;
- sovrapposizioni;
- errori;
- processi rimasti bloccati;
- consumo di CPU e memoria.
Un cron apparentemente secondario può saturare periodicamente il server e provocare rallentamenti difficili da diagnosticare.
9. Controllare OpenSearch
Nei cataloghi grandi, anche il motore di ricerca può influenzare significativamente le performance.
Occorre monitorare:
- stato del cluster;
- memoria;
- heap;
- shard;
- indici;
- tempi delle query;
- CPU;
- operazioni di indexing.
Problemi di OpenSearch possono manifestarsi soprattutto su:
- ricerca;
- categorie;
- navigazione;
- filtri;
- reindex.
Aumentare le risorse del web server non risolve un collo di bottiglia nel cluster OpenSearch.
10. Analizzare moduli di terze parti e codice custom
Questo è uno dei controlli più importanti.
Magento può essere configurato perfettamente e continuare a essere lento a causa di una singola estensione.
I problemi tipici comprendono:
- plugin eseguiti troppo frequentemente;
- observer pesanti;
- query ripetitive;
- caricamento completo di collection;
- chiamate HTTP sincrone;
- elaborazioni effettuate durante la request;
- uso scorretto del repository pattern;
- blocchi non cacheabili;
- logica complessa inserita nel rendering.
Non bisogna quindi chiedersi soltanto:
“Magento è lento?”
La domanda più utile è:
“Quale componente sta consumando il tempo della richiesta?”
11. Cercare chiamate verso API esterne
Un ecommerce moderno comunica spesso con molti sistemi:
- ERP;
- CRM;
- sistemi di pagamento;
- servizi logistici;
- marketplace;
- sistemi marketing;
- motori di raccomandazione;
- servizi antifrode.
Una chiamata HTTP sincrona durante il caricamento della pagina può rallentare l’intera esperienza.
Immaginiamo:
Magento: 250 ms
API esterna: 1.800 ms
Totale: 2.050 ms
Il server Magento non è il problema.
Quando possibile, operazioni non strettamente necessarie alla risposta dovrebbero essere spostate verso processi asincroni, queue o background job.
12. Controllare PHP-FPM e OPcache
Una configurazione PHP non adeguata può limitare le performance anche su server potenti.
Tra i parametri da analizzare troviamo:
- numero di worker PHP-FPM;
- memoria disponibile;
memory_limit;- process manager;
- processi saturati;
- timeout;
- OPcache.
Un server con molta RAM ma pochi worker disponibili può creare code di richieste durante i picchi.
Al contrario, configurare troppi worker rispetto alla memoria disponibile può provocare swapping e peggiorare drasticamente le performance.
Il dimensionamento deve essere basato su misurazioni reali del consumo per processo.
13. Controllare immagini e frontend
Non tutti i problemi attribuiti a Magento sono realmente problemi backend.
Una pagina può essere generata velocemente dal server ma risultare comunque lenta a causa di:
- immagini troppo pesanti;
- JavaScript;
- CSS;
- font;
- script di tracking;
- tag manager;
- widget esterni;
- slider;
- video;
- chat;
- script marketing.
Occorre quindi analizzare anche metriche frontend e Core Web Vitals.
Questo aspetto è particolarmente importante quando si utilizzano frontend complessi o temi pesantemente personalizzati.
Soluzioni moderne come Hyvä possono ridurre significativamente la complessità frontend rispetto ad alcune implementazioni tradizionali, ma anche in questo caso la qualità dell’implementazione rimane determinante.
14. Analizzare log ed errori
I log possono rivelare problemi che non emergono immediatamente durante la navigazione.
Tra i file e le sorgenti da controllare troviamo:
var/log/system.log
var/log/exception.log
var/log/debug.log
oltre ai log di:
- PHP-FPM;
- Nginx/Apache;
- MySQL;
- Redis;
- Varnish;
- OpenSearch;
- sistema operativo.
Un numero elevato di exception intercettate, warning o retry può consumare risorse senza produrre un errore evidente all’utente.
È importante anche verificare che applicazioni o moduli custom non stiano generando quantità anomale di log.
15. Utilizzare un profiler/APM prima di aumentare il server
Questo è probabilmente il controllo più importante.
Prima di investire nell’infrastruttura è opportuno profilare l’applicazione.
Strumenti APM e profiler permettono di visualizzare dove viene realmente trascorso il tempo.
Una request da 3 secondi potrebbe, per esempio, essere composta da:
Magento/PHP 320 ms
Database 410 ms
Modulo custom 180 ms
API ERP 1.750 ms
Altro 340 ms
--------------------------------
Totale 3.000 ms
Senza profiling potremmo concludere:
“Magento ha bisogno di un server più potente.”
Con il profiling scopriamo invece che quasi il 60% del tempo dipende da una chiamata esterna.
Sono due problemi completamente diversi.
Quando serve davvero cambiare server?
Dopo aver effettuato questi controlli potrebbe emergere che l’infrastruttura è effettivamente sottodimensionata.
È possibile osservare, per esempio:
- CPU costantemente elevata;
- memoria insufficiente;
- swapping;
- PHP-FPM saturo;
- I/O elevato;
- database senza risorse;
- Redis senza memoria;
- OpenSearch sottodimensionato.
In questo caso aumentare le risorse è perfettamente ragionevole.
La differenza è che la decisione viene presa sulla base dei dati, non per tentativi.
Magento lento: perché cambiare server può non risolvere il problema
Supponiamo che una pagina impieghi 4 secondi.
Cambiamo server e raddoppiamo CPU e RAM.
La pagina passa a 3,5 secondi.
Abbiamo ottenuto un miglioramento marginale aumentando permanentemente il costo dell’infrastruttura.
Se invece scopriamo che 2,5 secondi dipendono da una query SQL custom o da una API esterna, possiamo intervenire direttamente sul problema.
È per questo che una corretta analisi delle performance Magento 2 deve precedere il dimensionamento dell’infrastruttura.
Checklist: Magento 2 lento
Prima di cambiare server verifica questi 15 punti:
- TTFB e tempi reali di risposta
- Production Mode
- Full Page Cache
- Varnish
- Redis
- Slow query SQL
- Dimensione e stato delle tabelle
- Indexer e cron
- OpenSearch
- Moduli e codice custom
- API e servizi esterni
- PHP-FPM e OPcache
- Frontend, immagini e JavaScript
- Log ed errori
- Profiling/APM
Soltanto dopo questa analisi ha senso chiedersi se servono più CPU, RAM o una diversa infrastruttura.
Un approccio corretto alla performance analysis di Magento 2
Una performance audit efficace dovrebbe seguire un processo ripetibile:
Misurare → identificare → profilare → correggere → misurare nuovamente.
Non:
Magento è lento → aumentare il server → sperare.
Questo approccio consente anche di quantificare il risultato.
Per esempio:
PRIMA
Homepage TTFB: 1.850 ms
Categoria TTFB: 2.430 ms
Prodotto TTFB: 1.720 ms
DOPO
Homepage TTFB: 280 ms
Categoria TTFB: 410 ms
Prodotto TTFB: 320 ms
Numeri di questo tipo permettono di capire esattamente se l’intervento ha prodotto un miglioramento e dove.
Magento 2 lento? Parti da una diagnosi, non dal server
Le performance di Magento 2 sono il risultato dell’interazione tra applicazione, database, cache, ricerca, frontend, integrazioni e infrastruttura.
Per questo cambiare server dovrebbe essere una conseguenza della diagnosi, non il primo tentativo di soluzione.
Un’analisi tecnica può identificare query lente, problemi di cache, moduli inefficienti, chiamate esterne, cron problematici o configurazioni non ottimali che altrimenti continuerebbero a consumare risorse anche su un’infrastruttura più potente.
Prima di aumentare i costi del server, conviene quindi capire esattamente dove Magento sta perdendo tempo.
FAQ
Perché Magento 2 è lento?
Le cause possono essere numerose: cache non configurata correttamente, query SQL inefficienti, moduli di terze parti, codice custom, Redis, Varnish, OpenSearch, cron, API esterne o risorse server insufficienti. È necessario profilare l’applicazione per identificare il collo di bottiglia.
Come velocizzare Magento 2?
Bisogna prima misurare le performance e identificare il componente responsabile. Gli interventi possono riguardare Full Page Cache, Varnish, Redis, database, PHP-FPM, OpenSearch, codice custom, frontend e infrastruttura.
Magento 2 ha bisogno di Varnish?
Varnish è raccomandato per ottenere performance elevate nella gestione delle pagine cacheabili. La semplice installazione non è però sufficiente: occorre verificare hit rate, invalidazioni e corretta configurazione della cache.
Redis velocizza Magento 2?
Redis può migliorare la gestione di cache e sessioni, ma deve essere dimensionato e configurato correttamente. Un’istanza Redis satura o con elevata latenza può diventare un collo di bottiglia.
Come capire se Magento è lento per colpa del server?
È necessario monitorare CPU, memoria, I/O, PHP-FPM, database e altri servizi durante il carico reale. Se le risorse non sono sature, il problema potrebbe trovarsi nell’applicazione o nelle integrazioni.
Come trovare le query lente in Magento 2?
È possibile utilizzare gli strumenti del database, slow query log e sistemi APM/profiling per individuare query particolarmente costose o ripetute.
Perché Magento diventa lento con molti prodotti?
Cataloghi grandi aumentano il lavoro necessario per indexing, ricerca, categorie, attributi e operazioni sul database. La dimensione del catalogo, però, non è sufficiente da sola a spiegare le performance: architettura e configurazione rimangono determinanti.
Hyvä rende Magento più veloce?
Hyvä riduce notevolmente la complessità del frontend rispetto ad alcune implementazioni Magento tradizionali. Non risolve però automaticamente problemi backend relativi a database, PHP, cache, OpenSearch o integrazioni.
Aumentare CPU e RAM velocizza Magento?
Può farlo quando CPU o memoria rappresentano realmente il collo di bottiglia. Se il problema deriva da una query lenta, una chiamata API o codice inefficiente, aumentare le risorse può produrre benefici limitati.
Quando conviene fare una performance audit Magento?
Quando il sito presenta TTFB elevati, rallentamenti durante i picchi, categorie o checkout lenti, timeout, aumento progressivo delle risorse necessarie o performance peggiori dopo l’installazione di nuovi moduli o personalizzazioni.