Come rendere più veloce Magento 2: guida pratica

Per rendere più veloce Magento 2 non basta installare una singola estensione di cache. Se vuoi capire come rendere più veloce Magento, devi controllare insieme modalità production, cache, cron, indicizzatori, PHP, database, tema e risorse del server. LiteMage può ridurre sensibilmente il lavoro necessario per servire le pagine memorizzabili, ma non corregge query lente, estensioni inefficienti, cron bloccati o risorse insufficienti.

Risposta rapida: crea un backup e una copia di staging, misura il sito prima delle modifiche, verifica che Magento usi la modalità production, controlla cache, indexer e cron, quindi analizza PHP, database e frontend. Attiva LiteMage soltanto se l’ambiente usa LiteSpeed Enterprise con il modulo previsto e se versione di Magento, estensione e licenza sono compatibili. Ripeti le stesse misurazioni dopo ogni intervento.

Importante: questa guida riguarda Magento Open Source e Adobe Commerce 2. Esegui i comandi CLI come proprietario dei file dell’installazione, non come visitatore web e non alla cieca sul negozio in produzione. Le operazioni di deployment, cambio modalità, installazione di moduli e modifica degli indexer possono richiedere manutenzione programmata.

Perché Magento 2 può diventare lento

Magento genera catalogo, prezzi, regole, sessioni, contenuti personalizzati e numerosi asset. Una pagina può coinvolgere PHP, database, cache applicativa, full-page cache, filesystem, servizi esterni e codice JavaScript. Per questo due negozi sullo stesso server possono avere prestazioni molto diverse.

I rallentamenti più comuni dipendono da una o più di queste cause:

  • modalità default o developer usata sul sito pubblico;
  • cache Magento disabilitate o invalidate continuamente;
  • cron non configurato, in ritardo oppure in errore;
  • indexer non aggiornati o impostati in modo inadatto al carico;
  • estensioni che eseguono query o richieste esterne a ogni pagina;
  • tema pesante, immagini grandi e troppo JavaScript;
  • versione PHP non supportata dalla release Magento installata;
  • OPcache assente o configurata con risorse insufficienti;
  • database sovraccarico, query lente o storage con latenza elevata;
  • CPU, RAM, processi o I/O non adeguati a catalogo e traffico;
  • cache full-page con basso rapporto di hit o invalidazioni eccessive;
  • servizi esterni lenti durante ricerca, pagamento, spedizione o tracking.

Non aumentare contemporaneamente tutti i parametri e non installare più sistemi di full-page cache sovrapposti. Un cambiamento alla volta rende possibile capire cosa ha davvero migliorato il sito e cosa ha introdotto un problema.

1. Misura Magento prima di ottimizzarlo

Una promessa generica come “30% più veloce” non è attendibile senza conoscere pagina, carico, stato della cache e infrastruttura. Registra un punto di partenza e usa sempre le stesse URL, località di test, dispositivo e condizioni.

MisuraChe cosa indicaCome interpretarla
TTFBTempo prima dell’inizio della rispostaUn valore alto può indicare PHP, database, servizi esterni o cache non efficace.
Pagina freddaPrima richiesta dopo invalidazione o scadenzaMostra il costo reale di generazione e riempimento della cache.
Pagina in cacheRichiesta ripetuta dello stesso contenuto pubblicoAiuta a verificare il beneficio e il corretto hit della full-page cache.
Carrello e checkoutPercorso dinamico con sessioneNon deve essere valutato come una pagina pubblica completamente memorizzabile.
Core Web VitalsEsperienza di caricamento e interazione nel browserPuò restare scarsa anche con TTFB rapido se immagini, CSS o JavaScript sono pesanti.
Errori e saturazioneLog, CPU, memoria, processi, I/O e databaseIndicano se il problema è un limite di risorse o un malfunzionamento.

Prova almeno homepage, categoria, prodotto, ricerca, carrello e checkout. Se il problema compare solo a utenti autenticati o soltanto nell’area amministrativa, una full-page cache pubblica non è la prima risposta. Annota anche data, ora, traffico e operazione: sono dati utili per correlare il rallentamento ai log.

2. Controlla modalità di esecuzione e deployment

La documentazione ufficiale sulle modalità di Magento spiega che la modalità default non è ottimizzata per la produzione. Sul negozio pubblico deve essere valutata la modalità production, che evita la generazione dinamica tipica degli ambienti di sviluppo.

Dalla directory principale di Magento puoi eseguire il controllo non distruttivo:

php bin/magento deploy:mode:show

Non passare direttamente a production durante l’orario di punta. Il cambio modalità può avviare compilazione, deployment degli asset statici e pulizia della cache. Prima verifica compatibilità di tema ed estensioni, crea un backup, prova in staging e pianifica la manutenzione. Usa la versione PHP CLI supportata e coerente con quella del sito.

Dopo un aggiornamento applicativo, il processo di deployment può includere compilazione della dependency injection e generazione degli asset statici per le sole lingue utilizzate. Queste operazioni appartengono a una procedura di rilascio verificata; non devono diventare comandi periodici eseguiti senza motivo.

3. Verifica tutte le cache Magento

La guida ufficiale alla cache di Magento indica che disabilitare le cache penalizza le prestazioni. Controlla lo stato con:

php bin/magento cache:status

In produzione i tipi di cache necessari devono risultare attivi. Se una cache torna continuamente invalida, individua l’evento o l’estensione che la invalida invece di programmare un flush globale. La pulizia della cache Magento rimuove i dati gestiti dall’applicazione; il flush dello storage può coinvolgere anche altri processi che condividono lo stesso backend. Usa quindi l’operazione più limitata possibile.

Una full-page cache accelera soprattutto contenuti pubblici riutilizzabili. Prezzi personalizzati, sessioni, carrello, checkout e blocchi privati richiedono un trattamento differente. Verifica sempre che cookie, query string, variazioni di store e personalizzazioni non riducano inutilmente il rapporto tra hit e miss.

4. Controlla indexer e cron

Gli indici trasformano dati complessi del catalogo in strutture più efficienti da leggere. Usa questi controlli:

php bin/magento indexer:status
php bin/magento indexer:show-mode

La documentazione ufficiale degli indexer distingue aggiornamento in tempo reale e aggiornamento pianificato. Per cataloghi o flussi di modifica intensi, la modalità “Update by Schedule” può distribuire meglio il lavoro; non va però impostata senza cron funzionante. Prima di cambiare modalità, Adobe raccomanda manutenzione e sospensione controllata dei cron per evitare lock del database.

Magento dipende dai cron per reindicizzazione, regole prezzi, email, sitemap e altre attività. La guida ufficiale ai cron Magento richiede che siano eseguiti dal proprietario del filesystem. Verifica il crontab e i log, in particolare:

  • job con stato error o missed;
  • coda che cresce più velocemente di quanto venga elaborata;
  • processi cron sovrapposti e troppo lunghi;
  • PHP CLI diverso da quello supportato dal sito;
  • estensioni che pianificano migliaia di attività o restano bloccate;
  • reindicizzazioni complete troppo frequenti.

Non eliminare manualmente tabelle o righe di cron_schedule senza una procedura compatibile con la versione installata. La pulizia dei dati storici non risolve un job che continua a fallire.

5. Valuta Redis per cache e sessioni

Redis può ridurre accessi al filesystem e rendere più efficiente la gestione di cache e sessioni, ma deve essere disponibile e dimensionato correttamente. La configurazione Redis ufficiale per Magento raccomanda database distinti quando lo stesso servizio gestisce più funzioni: tipicamente 0 per cache predefinita, 1 per full-page cache e 2 per sessioni.

Prima di configurarlo verifica:

  • disponibilità di Redis nel piano o nel server;
  • memoria sufficiente e politica di eliminazione compatibile;
  • latenza tra Magento e il servizio Redis;
  • autenticazione, rete privata e assenza di esposizione pubblica;
  • database separati per cache, full-page cache e sessioni;
  • monitoraggio di memoria, connessioni, errori ed evictions;
  • procedura di rollback del file app/etc/env.php.

Usa i comandi di configurazione della tua versione Magento, perché validano i parametri e aggiornano l’ambiente. Non copiare alla cieca un file env.php da un altro negozio e non inserire password reali in guide, ticket pubblici o screenshot.

6. Ottimizza PHP, OPcache e dipendenze

La versione PHP deve essere supportata dalla release esatta di Magento e da tutte le estensioni installate. Una versione più nuova non è automaticamente compatibile. Prima dell’upgrade consulta i requisiti della tua release, prova checkout, pagamenti, cron, indicizzazione e area amministrativa in staging.

OPcache evita di ricompilare gli script PHP a ogni richiesta. Controlla che sia attiva per il gestore PHP usato dal sito e che memoria, numero massimo di file e strategia di validazione siano adeguati alla quantità di codice. La configurazione della CLI può essere diversa da quella di LiteSpeed o PHP-FPM: il controllo deve avvenire nel contesto corretto.

Evita valori arbitrariamente enormi. Più memoria assegnata a un singolo processo può ridurre il numero di richieste concorrenti sostenibili. Osserva consumo reale, errori di memoria, processi simultanei e limiti del piano. Disattiva in produzione profiler e debug non necessari, ma conserva log sufficienti per diagnosticare gli errori.

7. Individua estensioni e query lente

Un modulo può aggiungere observer, plugin, query o chiamate API in ogni richiesta. Confronta una pagina lenta con log applicativi, slow query log e tempi dei servizi esterni. Non disabilitare estensioni essenziali sul negozio pubblico durante gli acquisti: riproduci il problema in staging e modifica un componente alla volta.

Controlla in particolare:

  • ricerca e navigazione a faccette su cataloghi grandi;
  • regole prezzo e promozioni complesse;
  • integrazioni ERP, marketplace e spedizionieri;
  • moduli che chiamano servizi remoti prima di mostrare la pagina;
  • query senza indice o ripetute centinaia di volte;
  • tabelle di log, report o code cresciute senza manutenzione prevista;
  • importazioni che avviano reindicizzazioni complete troppo spesso;
  • backup o scansioni eseguiti negli stessi orari di picco.

L’ottimizzazione del database dipende da dimensione, schema, query e RAM disponibile. Non applicare configurazioni MySQL copiate da server diversi e non aggiungere indici senza verificare piani di esecuzione, scritture e compatibilità con gli aggiornamenti Magento.

8. Riduci il peso del frontend

Una risposta HTML rapida non garantisce una pagina veloce nel browser. Ottimizza immagini in dimensioni appropriate, lazy loading dove corretto, font, CSS e JavaScript. Rimuovi widget e script di terze parti non necessari, soprattutto se bloccano il thread principale o effettuano molte richieste prima dell’interazione.

Valuta separatamente:

  • Largest Contentful Paint dell’immagine principale;
  • layout shift causati da immagini e banner senza dimensioni;
  • JavaScript di chat, tracking, recensioni e marketing;
  • bundle duplicati introdotti da tema ed estensioni;
  • numero e peso delle immagini nelle categorie;
  • cache browser e compressione delle risorse statiche;
  • latenza geografica, CDN e corretto caching degli asset versionati.

Minificazione, unione dei file e caricamento differito devono essere provati con il tema reale. Un’opzione che riduce il numero di richieste può peggiorare caching, priorità o compatibilità. Dopo ogni modifica verifica menu, ricerca, varianti prodotto, carrello, checkout, consenso cookie e pagamenti.

9. Come funziona LiteMage con Magento 2

LiteMage Cache per Magento 2 è una soluzione full-page costruita su LSCache. L’estensione Magento comunica con LiteSpeed Web Server e può assemblare contenuti pubblici e privati usando ESI. Per utilizzarla servono LiteSpeed Enterprise con il modulo LiteMage, l’estensione compatibile e una configurazione coerente.

LiteMage non è la stessa cosa della sola presenza di LiteSpeed o della cache LSCache indicata genericamente in un piano. Prima dell’installazione verifica con il provider:

  • che il modulo LiteMage sia disponibile e autorizzato;
  • compatibilità con la versione esatta di Magento 2;
  • licenza e limiti applicabili al servizio;
  • metodo di installazione e procedura di aggiornamento;
  • strategia di full-page cache già attiva;
  • cookie, store view e variazioni che devono separare la cache;
  • blocchi privati, carrello e checkout da non trattare come pagine pubbliche;
  • purge e invalidazioni dopo modifiche a prodotti, prezzi e categorie.

Non usare contemporaneamente più applicazioni di full-page cache senza un’architettura esplicitamente supportata. Dopo l’attivazione controlla hit e miss, pagine escluse, contenuti personalizzati e correttezza del carrello. Un hit elevato sulle pagine pubbliche può ridurre il carico PHP, ma checkout, amministrazione, API e richieste non memorizzabili richiedono comunque risorse adeguate.

10. Scegli risorse adatte al negozio

Catalogo, visitatori simultanei, importazioni, API e numero di estensioni incidono più del solo traffico mensile. Un negozio piccolo può essere lento per un modulo difettoso; uno store ben ottimizzato può gestire più richieste con le stesse risorse. Osserva CPU, RAM, processi, I/O, spazio, inode, database e picchi reali.

I piani Hosting eCommerce Xlogic utilizzano LiteSpeed Enterprise, CloudLinux e storage SSD NVMe e includono servizi che variano secondo il piano indicato nella pagina ufficiale. La presenza di LiteSpeed non implica automaticamente che il modulo LiteMage sia già attivo per Magento: chiedi conferma per la configurazione specifica.

Quando servono configurazioni personalizzate, servizi dedicati o maggior controllo, valuta un VPS SSD Xlogic. La modalità Unmanaged richiede amministrazione completa da parte del cliente; nella modalità Full Managed il perimetro dipende dal servizio acquistato e le modifiche vanno concordate. Migrare su un VPS non sostituisce l’ottimizzazione dell’applicazione.

Ordine consigliato degli interventi

  1. crea backup verificato e ambiente di staging;
  2. aggiorna Magento e moduli secondo una procedura compatibile;
  3. misura pagine fredde, pagine in cache e percorsi dinamici;
  4. verifica modalità production e deployment degli asset;
  5. controlla cache Magento e strategia full-page cache;
  6. correggi cron e indexer prima di aggiungere altri sistemi;
  7. verifica versione PHP, OPcache, limiti e processi;
  8. analizza query, database, estensioni e servizi esterni;
  9. ottimizza immagini, CSS, JavaScript e script di terze parti;
  10. valuta Redis e LiteMage solo dopo aver confermato compatibilità;
  11. ripeti i test con le stesse condizioni e documenta il risultato;
  12. monitora errori e prestazioni dopo la pubblicazione.

Cosa comunicare all’assistenza Xlogic

Se il rallentamento non è riproducibile o non conosci i limiti del piano, apri un ticket Xlogic indicando:

  • dominio e servizio interessato;
  • versione Magento e versione PHP;
  • URL esatta lenta e percorso eseguito;
  • data, ora e durata approssimativa del problema;
  • differenza tra prima richiesta e richiesta ripetuta;
  • eventuale utente autenticato, store view o dispositivo;
  • modifiche, aggiornamenti o importazioni recenti;
  • messaggi nei log, senza password, token o dati dei clienti;
  • stato di cron, indexer e cache;
  • eventuale richiesta di verifica della disponibilità LiteMage.

Non inviare credenziali nel testo del ticket e non allegare dump completi non richiesti. Dati precisi permettono di distinguere più rapidamente un limite infrastrutturale da un problema applicativo.

Checklist per rendere più veloce Magento

  • ho un backup recente e testato;
  • provo le modifiche in staging;
  • Magento usa la modalità corretta per la produzione;
  • le cache necessarie sono attive;
  • cron e indexer non mostrano errori o ritardi;
  • PHP e moduli sono compatibili con la release Magento;
  • OPcache è attiva nel contesto web corretto;
  • Redis, se usato, è isolato e monitorato;
  • le estensioni e i servizi esterni sono stati profilati;
  • immagini e JavaScript non bloccano il frontend;
  • LiteMage è disponibile, compatibile e configurato correttamente;
  • confronto risultati prima e dopo nelle stesse condizioni.

Domande frequenti su Magento 2 e LiteMage

Qual è il primo intervento per rendere più veloce Magento 2?

Misura il sito e verifica modalità production, cache, cron e indexer. Sono controlli fondamentali e permettono di capire se il problema dipende dall’applicazione, dalla cache o dalle risorse prima di installare altre estensioni.

LiteMage da solo rende sempre veloce Magento?

No. LiteMage può accelerare le pagine memorizzabili e ridurre il lavoro di PHP, ma non corregge query lente, cron bloccati, estensioni inefficienti, frontend pesante o risorse insufficienti. I risultati vanno misurati sul negozio reale.

LiteMage funziona su qualsiasi hosting Magento?

No. Richiede LiteSpeed Enterprise con il modulo LiteMage, un’estensione Magento compatibile e la relativa disponibilità nel servizio. La sola presenza di LiteSpeed o di LSCache non garantisce che LiteMage sia incluso o già attivo.

Posso usare Redis e LiteMage insieme?

Sì, perché operano su livelli differenti, se la configurazione è supportata. Redis può gestire cache applicativa e sessioni, mentre LiteMage gestisce la full-page cache. Usa database Redis separati e verifica memoria, sicurezza e invalidazioni.

Perché il checkout resta lento anche con la full-page cache?

Carrello e checkout contengono dati di sessione e operazioni dinamiche che non si comportano come una pagina pubblica interamente memorizzabile. Analizza PHP, database, moduli di pagamento e spedizione, chiamate esterne e risorse disponibili.

Come rendere più veloce Magento 2: guida pratica ultima modifica: 2017-12-18T15:43:41+01:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?