Come svuoto correttamente la cache di PrestaShop?

Per svuotare correttamente la cache di PrestaShop, parti dal back office: Advanced Parameters > Performance, poi clicca Clear cache. Questo basta per la maggior parte delle modifiche a template, traduzioni e configurazione.Pagina Performance - il pulsante Clear cache e i controlli della cache.Quando una modifica continua a non comparire, svuota gli strati più profondi nell'ordine giusto: prima i file PrestaShop, poi OPcache, poi eventuali CDN, Varnish o cache full-page davanti al negozio.# Run from the PrestaShop root. This deletes cache contents, not the cache directories themselves. find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Older PS 1.6-style installs may also use these Smarty paths: find cache/smarty/compile -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find cache/smarty/cache -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Reset web OPcache by reloading the PHP service: sudo systemctl reload php8.2-fpm # Apache/mod_php alternative: sudo systemctl reload apache2Non fare affidamento su un comando opcache_reset() eseguito solo da CLI, a meno che tu sappia che PHP CLI e PHP web condividono lo stesso pool OPcache. Su un normale hosting PHP-FPM, ricaricare PHP-FPM è il reset affidabile. Dopo una pulizia a livello server, assicurati che l'utente del web server possa scrivere di nuovo nelle directory cache; una proprietà sbagliata dopo una pulizia eseguita da root è una causa comune di nuovi errori 500.L'errore comune è svuotare solo la cache del back office e presumere che OPcache o un reverse proxy abbiano seguito la stessa operazione. Non succede. Se vuoi warming della cache e purge CDN automatico invece di farlo a mano, Performance Revolution include logica di cache warming e purge CDN, e Redis Cache Manager & Monitor aiuta a gestire un backend cache Redis.

Quanta RAM serve a PrestaShop?

Qui ci sono due numeri separati, e confonderli è l'errore più comune.PHP memory_limit (per richiesta). Questo è ciò che PrestaShop consuma davvero per ogni page load o azione admin. La documentazione ufficiale PrestaShop 9 raccomanda almeno 512 MB. PrestaShop 8 stava bene con 256 MB; l'aumento in PS 9 riflette lo stack Symfony più pesante nel back office. Import/export, installazione moduli, aggiornamenti massivi prodotto e migration assistant richiedono tutti questo limite più alto, impostalo più basso e avrai schermate bianche o fatal error Allowed memory size exhausted.RAM del server (host). È la memoria totale del VPS o server dedicato, condivisa tra worker PHP-FPM, MySQL/MariaDB, web server, Redis o Memcached, cron job e sistema operativo. Baseline pratiche:Sotto 1 000 SKU, traffico leggero: 2 GB è il pavimento realistico.Catalogo medio (1 000 a 20 000 SKU), caching attivo: 4 GB è comodo.Catalogo grande (50 000+ SKU) o multistore: 8 GB+ e una sessione di tuning MariaDB dedicata.Import massivi, rigenerazione immagini, grandi job di migrazione: aggiungi margine o sposta i task pesanti su CLI cron.Se lo shop sembra lento, la RAM raramente è la prima cosa da sistemare, inizia da full-page cache, Redis, OPcache e un tema più leggero. Vedi la nostra guida performance tuning PrestaShop per l'ordine reale delle operazioni.Un controllo di capacità utile non è semplicemente memory_limit x max_children, perché non tutti i worker raggiungono il limite contemporaneamente, ma la formula ti dice se l'host è impossibile sulla carta:PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroomPer esempio, dieci worker PHP occupati con limite 512 MB richiedono più di un VPS da 2 GB una volta incluso MariaDB, anche se la maggior parte delle richieste usa meno del limite. Mantieni alti i limiti CLI per rigenerazione immagini e import, ma evita di far girare troppi worker PHP-FPM su un server piccolo. Se il Linux OOM killer inizia a uccidere PHP o MariaDB, abbassare il conteggio worker e sistemare pressione cache/database è di solito meglio che aumentare soltanto memory_limit.

Quali dati di monitoraggio può salvare il modulo?

Performance Revolution salva dati tecnici di monitoraggio sul tuo shop, ma non tutte le tabelle di monitoraggio hanno lo stesso profilo privacy. Le righe RUM sono basate su tempi, URL, classe del dispositivo e contesto dello shop, non su campi del profilo cliente; il logging delle query lente è diverso perché salva testo SQL grezzo e contesto dello stack trace, quindi va trattato come dato diagnostico potenzialmente sensibile se le query contengono identificativi di clienti, carrelli o ordini.In concreto, il modulo mantiene queste tabelle:Performance metrics - misurazioni temporizzate con tipo di metrica, valore e contesto JSON, usate per mostrare come si comporta lo shop nel tempo.Aggregated metrics - valori aggregati per ora, giorno, settimana e mese, inclusi somma, media, minimo, massimo e conteggio, così le dashboard restano utilizzabili su intervalli più lunghi.Slow queries - hash della query, testo SQL, tempo di esecuzione, controller, stack trace, numero di occorrenze e timestamp di prima/ultima rilevazione. Lo schema può contenere placeholder extra, ma il percorso del profiler registra questi campi invece di righe esaminate o righe inviate.Real-user monitoring (RUM) - dati di timing browser da visite campionate: TTFB, FCP, LCP, CLS, FID e INP, più campi di timing DOM, riepilogo resource-timing, URL, tipo di dispositivo e shop.RUM aggregates - conteggi campione e medie orarie per URL e dispositivo per le metriche RUM. Lo schema aggregato include una colonna p75_lcp, ma l'attuale query di aggregazione non la popola.Errore comune: trattare tutti i dati di monitoraggio come ugualmente a basso rischio. RUM è diagnostica di timing/dispositivo, ma le righe delle query lente possono esporre ciò che era presente nella query SQL. Limita l'accesso a queste diagnostiche come limiteresti l'accesso ai log del database.I valori predefiniti sono volutamente conservativi. La fragment cache è attiva con TTL di 3600 secondi, la query cache è attiva, le metriche sono attive, la soglia delle query lente è 0.1 secondi, la conservazione delle metriche è 30 giorni, il profiling è disattivato di default e il campionamento RUM è 0.1, cioè circa il 10 percento delle page view idonee viene misurato. Su uno shop con poco traffico, quel tasso di campionamento può far apparire i grafici RUM scarni finché non sono stati misurati abbastanza visitatori.Lo script front raccoglie i timing del browser con le Performance APIs, poi li invia con sendBeacon quando disponibile e ripiega su XHR. Il controller RUM accetta dati JSON POST, verifica che esista un URL, salva campi di timing/resource sanificati e restituisce una risposta 204 con header no-store/noindex. Il controller rimuove anche gli header Set-Cookie, quindi l'endpoint beacon non crea cookie cliente.Per la pulizia, il query profiler registra SQL lento per hash e aggiorna conteggio occorrenze e ora di ultima rilevazione quando la stessa query ricorre. I dati RUM grezzi possono essere aggregati in riepiloghi orari e le righe grezze più vecchie vengono rimosse dopo l'aggregazione, mantenendo utilizzabili le dashboard a lungo termine senza salvare per sempre ogni singolo beacon. Il limite importante è che l'attuale aggregazione RUM salva medie e conteggi, non un 75° percentile LCP calcolato.

La cache di PrestaShop causa problemi. Dovrei disabilitarla?

In un negozio in produzione tenga la cache attiva. È uno dei principali motivi per cui PrestaShop resta veloce: spegnerla in modo permanente rallenta ogni pagina per ogni visitatore, senza correggere la causa del problema. Disattivare temporaneamente un livello di cache è invece un passo diagnostico legittimo. Spenga un livello per prova quando deve verificare se un sintomo dipende davvero dalla cache, casi tipici: modifiche al template o alla grafica che non compaiono sul front office; prezzi, disponibilità o blocchi non aggiornati che sopravvivono a un normale ricaricamento; un'impostazione di un modulo che dopo il salvataggio sembra non avere effetto. Proceda in modo controllato: un solo livello alla volta, preferibilmente su una copia di staging o in un momento tranquillo; annoti cosa ha spento e lo riattivi appena concluso il test. Se il sintomo sparisce a livello spento, ha trovato dove vivono i dati non aggiornati. La soluzione è svuotare o sistemare quel livello, oppure correggere il modulo o il template difettoso, non lasciare la cache spenta. Nella maggior parte dei casi si tratta solo di cache non aggiornata, e uno svuotamento corretto risolve. Segua i passaggi di Come svuoto correttamente la cache di PrestaShop? prima di valutare misure più drastiche.

Come gestisce il modulo la cache edge Cloudflare?

Performance Revolution consente a Cloudflare di mettere in cache le pagine HTML complete per i visitatori anonimi: una volta che una pagina è stata caricata nella cache edge, le richieste successive possono essere servite direttamente da Cloudflare. I cache miss, la prima richiesta, le voci scadute e tutto il traffico loggato o con carrello. Raggiungono comunque il Suo origin; è quindi uno strato edge davanti al PHP, non una garanzia che le richieste non lo tocchino mai. Lavora solo lato server, senza trucchi JavaScript.Cosa fa a ogni richiesta:Per un visitatore anonimo su una pagina cacheable (home, categoria, prodotto, CMS, ricerca e simili), invia gli header che dicono a Cloudflare di conservare l'HTML per il TTL impostato.I visitatori loggati e chiunque abbia un carrello ricevono header di bypass, così le pagine personalizzate arrivano sempre fresche dall'origin.Rimuove Set-Cookie dalle risposte anonime, perché un CDN rifiuta di mettere in cache una pagina che imposta un cookie.Allega header Cache-Tag / Surrogate-Key: quando modifica un prodotto o una categoria, può purgare solo le pagine interessate invece dell'intero sito.La purga si adatta automaticamente al Suo piano Cloudflare: le zone Business ed Enterprise purgano direttamente per tag con una sola chiamata, mentre le zone free e Pro (che supportano solo la purga per URL) hanno i tag risolti in URL esatte e purgati nei lotti da 30 URL richiesti da Cloudflare. C'è anche un controllo dello stato della zona che legge le Sue impostazioni Cloudflare, Rocket Loader, Brotli, HTTP/3, Always Online, modalità SSL, TTL della cache del browser, e segnala eventuali configurazioni errate.Due limiti onesti. Primo, deve fornire un zone ID e un token API Cloudflare perché la purga via API funzioni; senza, il modulo invia comunque gli header di cache ma non può purgare attivamente. Secondo, la cache edge è disattivata di default e riguarda solo il traffico anonimo. È voluto, per non servire mai il carrello di un cliente a un altro.

Qual è il numero massimo di prodotti che PrestaShop può gestire?

PrestaShop non prevede un limite ufficiale al numero di prodotti e non blocca il negozio a nessuna soglia fissa. Nella pratica la capacità dipende dai dati e dall'infrastruttura, molto più che dal numero di prodotti in sé. Combinazioni e volume dei dati: molti attributi, combinazioni e caratteristiche moltiplicano i record ben oltre il numero di prodotti, ed è questo volume che il database deve sostenere. Database e ricerca: navigazione a faccette, ordinamenti e indice di ricerca crescono con il catalogo; query lente e reindicizzazione sono di solito il primo collo di bottiglia. Import ed export: i feed di grandi dimensioni richiedono import pianificati e suddivisi in lotti; un import completo del catalogo pesa sul negozio più della navigazione quotidiana. Hosting e risorse: processore, memoria, velocità dei dischi e configurazione del database fissano il tetto; un catalogo grande su un hosting sottodimensionato resterà lento, a prescindere dal software. Cache, tema e moduli: una cache efficace assorbe quasi tutto l'effetto della dimensione del catalogo, ma un tema pesante o un modulo scritto male può vanificarla. La risposta onesta per il Suo negozio arriva dalla misurazione: esegua un test di carico su una copia di staging con catalogo e traffico reali. Per gli interventi concreti consulti la nostra guida alle prestazioni di PrestaShop.

Il debugging delle performance può essere limitato?

Sì. Quando attivi il profiler front-office in MPR Performance Revolution, decidi chi può vederlo: lascia il pannello completamente off, oppure mostralo ma limitalo ai dipendenti loggati così i clienti non vedono mai i tuoi timing.Il debug può essere ristretto dalla configurazione del modulo invece di attivare diagnostiche generiche.Uno dei consigli performance PrestaShop più utili è profilare lo store live, non una copia test pulita, traffico reale, moduli reali, dati reali. Il profiler aggiunge una piccola barra che mostra conteggio e tempo delle query SQL di ogni pagina, e lista le query più lente e gli hook modulo più lenti, così vedi esattamente dove la pagina spende tempo prima di cambiare qualcosa.L'errore comune è lasciare un profiler visibile al pubblico: espone dettagli interni e aggiunge overhead a ogni richiesta. Tienilo solo per dipendenti, spegnilo dopo aver trovato il collo di bottiglia e agisci su ciò che mostra, di solito un hook modulo pesante o una query senza indice. Il modulo gestisce anche Redis object caching, asset deferral e warm-up OPcache/Smarty, quindi le correzioni vivono nello stesso posto della diagnosi.Le impostazioni pertinenti sono due switch: profiler_panel_enabled attiva il pannello front-office, e profiler_employees_only lo mantiene dietro una sessione dipendente back-office attiva. L'impostazione employees-only è attiva di default, mentre il pannello stesso è off di default. Quando il profiling parte, il modulo inizializza l'instrumentation presto nella richiesta e poi inietta il pannello prima di solo se il collector è abilitato e il gate dipendente passa.Per attribuzione SQL e hook più profonda, il modulo include override opzionali che registrano ogni query database e il timing hook per modulo, e il query profiler registra query lente sopra la soglia configurata, che di default è 0.1 secondi. Installali solo quando ti serve quel livello di visibilità, perché aggiungono deliberatamente overhead di instrumentation. Un buon workflow è: abilita profiler employees-only, riproduci un URL lento, cattura totali query/hook, disabilitalo, poi fai il più piccolo cambio di cache, indice o modulo che risolve il collo di bottiglia misurato.

Quali backend cache sono disponibili in configurazione?

Nell'impostazione “Cache Backend” può scegliere Rilevamento automatico (consigliato), Redis, APCu o cache su file.Il rilevamento automatico sceglie la migliore opzione disponibile nell'ordine Redis → APCu → file: non deve sapere cosa supporta il suo server, se Redis e APCu non ci sono, subentra la cache su file, che funziona sempre. Scelga un backend specifico solo per forzarlo; se non è disponibile il modulo registra una nota e torna comunque al rilevamento automatico, così la cache non resta mai disattivata per errore.Con Redis ottiene i campi di connessione attesi: host, porta, password, numero del database e un prefisso delle chiavi (utile quando più negozi condividono un'istanza Redis). Li imposti in base al servizio Redis del suo hosting.Fa parte di Performance Revolution. Se non gestisce un proprio Redis ma vuole controllarlo dal back office, veda Redis Cache Manager & Monitor.

Quale database devo usare con PrestaShop, MySQL o MariaDB?

PrestaShop usa MySQL o MariaDB come motore database. Secondo gli attuali requisiti ufficiali di sistema di PrestaShop 8 e PrestaShop 9, entrambi indicano come supporto SQL minimo MySQL 5.7 o MariaDB 10.2, con una versione recente raccomandata.Per uno store di produzione nuovo o aggiornato, trattali come minimi, non come target ideali. MySQL 8.0 o una release MariaDB LTS attuale è una scelta migliore di un vecchio host MySQL 5.7, soprattutto per cataloghi più grandi, tabelle search, combinazioni, carrelli e storico ordini. Usa tabelle InnoDB, mantieni abbastanza memoria buffer pool disponibile e assicurati che backup e test di restore facciano parte del piano hosting.PrestaShop 9 ha anche aspettative piattaforma più alte delle installazioni vecchie; i requisiti ufficiali raccomandano più memoria PHP per script rispetto a PrestaShop 8. La compatibilità database da sola non basta: versione PHP, estensioni, memory limit, permessi filesystem e compatibilità moduli vanno comunque controllati prima dell'upgrade.Se sei su hosting condiviso, chiedi all'host la versione esatta MySQL/MariaDB e se puoi abilitare lo slow query log o ricevere report di query lente. Questo conta di più nelle performance quotidiane PrestaShop del brand name del database server.Su un nuovo hosting, chiedi motore e versione esatti, non solo "MySQL compatible". Alcuni host gestiti eseguono MariaDB dietro un'etichetta MySQL, e normalmente va bene, ma serve comunque una versione che soddisfi i requisiti PrestaShop e una configurazione capace di gestire il catalogo. Per performance, le leve importanti sono di solito dimensione InnoDB buffer pool, latenza disco, indici, visibilità query lente e se il database compete con PHP su un piccolo server condiviso.Durante la migrazione, fai dump e restore con il charset corretto, mantieni lo stesso prefisso tabelle salvo tu lo stia cambiando deliberatamente, e testa ricerca, salvataggio prodotto, creazione ordine e griglie back-office dopo l'import. Vecchi store possono portarsi dietro tabelle MyISAM o indici obsoleti da versioni PrestaShop molto vecchie; convertire a InnoDB e ripulire gli indici va fatto deliberatamente con un backup, non come pulsante cieco del pannello hosting.

Il cache warming viene eseguito automaticamente di default?

No. In Performance Revolution il riscaldamento programmato della cache d'origine è disattivato di default, il flag cache_warming_enabled parte come false e il warmer cron riporta semplicemente «disabled» senza fare nulla finché non lo attiva.Di fabbrica, quindi, nessuno avvia il warmer al posto Suo. Ha a disposizione il meccanismo, pronto all'uso:Una voce cron che, una volta attivata, percorre le Sue URL così che OPcache PHP, template Smarty e CSS/JS combinati siano compilati prima dell'arrivo dei visitatori reali.Controlli di riscaldamento manuale nel Back Office per un passaggio su richiesta.Impostazioni di concorrenza e durata massima, perché un passaggio non sovraccarichi un server freddo.Un'impostazione è attiva di default: cache_warming_post_deploy_enabled è true e consente soltanto al comando CLI post-deploy di eseguire un passaggio completo dopo un rilascio. Autorizza quel comando, da solo non pianifica nulla. Il riscaldamento edge di Cloudflare (cdn_edge_warm_enabled) è anch'esso disattivato di default.Errore comune: attivare il flag cron senza mai collegare un vero cron job (o l'hook post-deploy) che lo richiami. L'interruttore dice «consentito»; uno scheduler deve comunque avviarlo.

Negozi PrestaShop affollati più veloci con caching Redis, APCu o su file e ottimizzazione degli asset

Performance Revolution - Cache Redis e ottimizzazione della velocità per PrestaShop

Performance Revolution - Ridurre le vendite perse a causa di pagine lente

Performance Revolution - Intervenire rapidamente sui problemi della cache

Performance Revolution, Redis Cache & Speed for PrestaShop - Asset Deferral Settings

Performance Revolution - svuota e preriscalda la cache PrestaShop con un clic

Performance Revolution - HTML del negozio ottimizzato con asset minificati e differiti

Negozi PrestaShop affollati più veloci con caching Redis, APCu o su file e ottimizzazione degli asset

Performance Revolution

Name: Performance Revolution
Brand: mypresta.rocks
SKU: mprperformancerevolution
Price: 299.00 EUR
Availability: InStock

Modulo cache PrestaShop, cache full page e Redis, regole Cloudflare sull’edge e invalidazione automatica

Nessuna recensione

299,00 €

MPR Performance Revolution è un modulo di prestazioni per negozi PrestaShop che misura la velocità durante le visite reali, individua il lavoro responsabile dei rallentamenti e rende più rapido il negozio da un'unica area amministrativa. L'installazione applica un profilo iniziale prudente, mentre ogni intervento più incisivo resta regolabile separatamente.

Cloudflare è un servizio mondiale facoltativo per la distribuzione delle pagine, disponibile con un piano gratuito e piani a pagamento. La sua rete avvicina ai visitatori le pagine pubbliche idonee, mentre l'account Cloudflare mostra la zona del sito, il piano scelto e l'attività della rete. Il modulo collega il servizio a PrestaShop, riconosce il piano, trova le regole in conflitto e riporta lo stato del collegamento nel pannello del negozio.

Il modulo prepara inoltre copie riutilizzabili delle pagine pubbliche sul server del negozio, distinte per lingua, valuta, paese e dispositivo quando questi elementi cambiano il contenuto mostrato. Carrello, conclusione dell'ordine, account cliente e visite autenticate passano sempre dal negozio attivo. Una modifica a prodotto, prezzo, disponibilità, categoria, valuta o imposta rinnova automaticamente le pagine collegate.

Scegli tu gli indirizzi esclusi, il calendario di preparazione e ogni intervento su immagini e lavoro del browser. Le immagini di prodotti, categorie, tema e moduli ricevono versioni WebP e AVIF create nel negozio, le visite reali isolano le pagine lente per dispositivo, l'analisi del database indica la causa e la manutenzione elimina carrelli abbandonati, vecchi dati di visita e immagini inutilizzate dopo un riepilogo chiaro.

Il risultato è meno attesa lungo il percorso di acquisto, dati commerciali aggiornati e privati, prove per decidere l'intervento successivo, pagine più leggere e manutenzione ordinaria riunita in un solo posto.

Download immediato dopo l'acquisto

Demo live istantanea Negozio reale, pronto in circa 1 min

Richiedi preventivo

Le opzioni avanzate della licenza richiedono JavaScript. Il pulsante standard Aggiungi al carrello aggiungerà comunque la quantità selezionata come licenze semplici e non configurate.

Licenza a vita per dominio, tua per sempre. Include 3 mesi di supporto e aggiornamenti. Scopri di più

La demo è il modulo completo: acquistalo quando vuoi e attiva la stessa installazione, senza reinstallare né perdere nulla. Apri la scheda Licenza del modulo e fai clic su “Attiva da mypresta.rocks” (oppure incolla la chiave); impostazioni e dati restano invariati. Gli aggiornamenti si installano con un clic dalla scheda Aggiornamento.

Supporto e aggiornamenti

6 mesi +39,00 € 9 mesi +65,00 € 1 anno +89,00 €

Rinnovo automatico del supporto

+29,90 €/mese

Servizi aggiuntivi

Configurazione professionale Configuriamo completamente il modulo secondo le tue esigenze: tutte le opzioni impostate, testate e verificate entro 1 giorno lavorativo. +29,00 €

Integrazione visiva Modifiche CSS e template per adattarsi al tuo tema: include verifica multi-dispositivo e revisione degli screenshot. +49,00 €

Totale opzioni: 0,00 €

Totale selezionato: 299,00 €

Come rende più veloce l'intero negozio un solo modulo?

MPR Performance Revolution misura la rapidità durante le visite reali, collega i rallentamenti al database, ai moduli e ai modelli di pagina, e applica gli interventi su pagine pubbliche, immagini e lavoro del browser dalla stessa amministrazione PrestaShop.

Visite reali: risultati per pagina, dispositivo e periodo trasformano un problema generico in un punto preciso.
Pagine pubbliche sicure: le pagine idonee sono pronte sul server del negozio e tramite Cloudflare, mentre i dati privati restano dinamici.
Informazioni aggiornate: catalogo, prezzi, disponibilità, valute e imposte rinnovano solo le pagine interessate.
Distribuzione più leggera: file ridotti, immagini caricate più tardi e versioni WebP e AVIF locali alleggeriscono il browser.
Diagnosi e manutenzione: operazioni lente, costruzione delle pagine, vecchi dati e immagini inutilizzate diventano attività concrete.
Avvio semplice, controllo profondo: un profilo consigliato lavora dopo l'installazione e ogni scelta importante resta regolabile.

andamento della velocità delle visite reali per pagina e dispositivo

Quali pagine fanno davvero aspettare i clienti?

Il modulo registra durante le visite il tempo della prima risposta e del contenuto principale, la reazione ai gesti e la stabilità dell'impaginazione. I dati restano nel negozio e vengono organizzati per indirizzo, telefono, tablet o computer e periodo selezionato.

Una pagina prodotto lenta su telefono emerge quindi come quella pagina e quella categoria di dispositivo. Il periodo attuale viene affiancato al precedente, così l'effetto di una modifica al tema, alle immagini o alla distribuzione si legge nelle visite successive e non in una singola prova svolta in condizioni ideali.

Performance Revolution – metriche da utenti reali, rinvio delle risorse e riscaldamento della cache

Come restano veloci le pagine pronte senza condividere un carrello?

Le pagine pubbliche idonee sono pronte sul server del negozio prima che inizi la costruzione completa. Copie distinte conservano il negozio, la lingua, la valuta, il paese e il dispositivo corretti quando questi dati cambiano la pagina. Carrello, conclusione dell'ordine, account, visite autenticate, dati privati di sessione e richieste incerte passano sempre dal negozio attivo.

Cloudflare fornisce la rete mondiale con un piano gratuito e piani a pagamento. MPR Performance Revolution riconosce il piano scelto, crea regole adatte, elimina i conflitti e mantiene disponibili le pagine pubbliche già convalidate durante un problema temporaneo del server. Scegli tu le esclusioni aggiuntive e gli orari, mentre le protezioni integrate delle aree private restano sempre attive.

Le modifiche a prodotti, categorie, pagine informative, produttori, fornitori, disponibilità, prezzi, combinazioni, valute e imposte rinnovano le copie collegate senza toccare le altre pagine già pronte.

Che cosa raggiunge il cliente in una forma più leggera?

Le immagini di prodotti, categorie, produttori, fornitori, tema attivo e moduli installati ricevono versioni WebP e AVIF create nel negozio quando il server supporta i formati. Gli originali rimangono, le nuove immagini vengono trattate automaticamente e quelle esistenti sono elaborate insieme, senza consegnare il catalogo a un servizio esterno.

Scegli separatamente riduzione e unione dei file, rinvio del lavoro secondario, eliminazione delle regole grafiche inutilizzate e caricamento successivo delle immagini. La schermata indica dimensione iniziale e risultato, perciò le scelte prudenti partono per prime e ogni intervento più forte viene valutato da solo.

Impostazioni nel back office di rinvio delle risorse con gli interruttori di ottimizzazione di CSS e JavaScript

Quali attività lente e vecchi dati richiedono attenzione?

Le operazioni lente del database compaiono con durata, frequenza e area del negozio che le ha richiamate. L'analisi dettagliata segnala letture complete, indici ignorati e ordinamenti inutili, mentre la misurazione protetta della pagina attribuisce il tempo di costruzione a moduli e modelli. Agenzia e sviluppatore ricevono una causa e un punto preciso.

La manutenzione conta carrelli abbandonati, sessioni degli ospiti, storico delle connessioni e vecchie statistiche prima della rimozione, poi tratta i gruppi selezionati subito o secondo un calendario. Mantiene inoltre le tabelle scelte e individua immagini prive di riferimenti per una rimozione protetta, mostrando prima il numero di record e lo spazio recuperato.

Quanto rapidamente inizia l'ottimizzazione e fin dove arriva la configurazione?

L'installazione applica un profilo consigliato per misurazione, riutilizzo sicuro, file più leggeri e immagini caricate più tardi. La distribuzione delle pagine pubbliche e gli interventi più incisivi sul browser restano scelte esplicite, quindi i primi vantaggi arrivano senza attivare tutto insieme.

Scegli gli indirizzi pubblici, i modelli di esclusione, l'ampiezza e il ritmo della preparazione, i formati delle immagini, i periodi di conservazione dei dati, la soglia delle operazioni lente e ogni intervento sul browser. Una modalità temporanea salva le impostazioni attive, le sospende durante il lavoro tecnico e ripristina lo stato precedente al termine.

La schermata di configurazione di Performance Revolution nel back office PrestaShop

Riferimento

mprperformancerevolution
Disponibile

2147483647 Articoli
Compatibilità PrestaShop

PS 1.7 – 9.x
Modello di prezzo

Acquisto singolo
Tipo di modulo

Front & Back-office
Rilevante per GDPR

No
Obiettivo di business

Ottimizzare le operazioni
Account esterno necessario

No
Complessità del modulo

Soluzione completa
Fase del percorso cliente

Gestire il negozio
Funziona con piattaforma

Nessuna piattaforma esterna

Cosa dicono di noi i nostri clienti

Recensioni azienda

5.0 ★ ★ ★ ★ ★ (4 recensioni)

Caricamento recensioni clienti...

Ancora nessuna recensione prodotto

Sii il primo a condividere la tua esperienza con questo modulo.

Scrivi una recensione

La tua valutazione *

★ ★ ★ ★ ★

Valuta aspetti specifici (opzionale)

Qualità

★ ★ ★ ★ ★

Rapporto qualità-prezzo

★ ★ ★ ★ ★

Stabilità

★ ★ ★ ★ ★

Compatibilità

★ ★ ★ ★ ★

Supporto

★ ★ ★ ★ ★

Il tuo nome *

La tua email *

Titolo recensione

La tua recensione *

Aggiungi foto (max 3)

Clicca per caricare o trascina e rilascia

Offre un centro di controllo completo delle prestazioni per PrestaShop: cache Redis/APCu/file, cache dei frammenti Smarty, cache delle query, ottimizzazione degli asset, lazy loading, generazione AVIF/WebP, header CDN page cache per visitatori anonimi, preriscaldamento della cache e una dashboard per cache hit ratio, query lente, Core Web Vitals, memoria e stato del backend di cache.

Leggi la documentazione completa Scarica PDF

Hai una domanda su questo prodotto? I nostri esperti sono qui per aiutarti. Chiedi informazioni su installazione, compatibilità o specifiche.

1301 domande

9 categorie

2013 sviluppo moduli dal

1.6–9 versioni PrestaShop

Vedi tutte le domande

v1.5.152026-05-27

AddedFinalize performance endpoint SEO cleanup
AddedRetain generated assets across cache clears
AddedFlip CDN cache from whitelist to blacklist — cache all pages by default

Funziona bene con Performance Revolution

I moduli che il nostro team abbina davvero a questo, e perché ciascuno merita di stare nella stessa configurazione.

Pagine PrestaShop più veloci aggiungendo lazy loading e attributi di decoding alle immagini del negozio

Automatic SEO Images Lazy Tags

69,00 €

★ ★ ★ ★ ★

Complement

Performance Revolution offre al tuo team ampi controlli di velocità, caching, warming, gestione degli asset e analisi dei colli di bottiglia, ma la consegna delle immagini sul front-end nelle pagine ricche di immagini è una leva specifica che beneficia di un trattamento dedicato, non solo del caching generale.

Automatic SEO Images Lazy Tags copre proprio questo, aggiungendo loading="lazy" e, in via opzionale, decoding="async" alle immagini di prodotti, elenchi e contenuti modificabili senza toccare il tema. Completa la suite di performance: uno gestisce caching e colli di bottiglia lato back-end, l'altro rinvia le immagini fuori schermo così il browser dà priorità a ciò che gli acquirenti vedono per primo, ciascuno nel proprio ambito.

Insieme affrontate la velocità dal server e dal browser allo stesso tempo. Performance Revolution gestisce caching e colli di bottiglia degli asset mentre il lazy loading alleggerisce le pagine ricche di immagini lato client, così una pagina categoria o prodotto beneficia sia di un caching ben gestito alle spalle sia di un caricamento immagini più leggero davanti all'acquirente, riducendo il rischio che pagine lente facciano perdere traffico.

Pulizia di vecchi carrelli, log, ricerche e registri email dal database PrestaShop

Database Cleanup

0,00 €

★ ★ ★ ★ ★

Complement

Performance Revolution si concentra su caching, warming, gestione degli asset e analisi dei colli di bottiglia, lo strato di performance in tempo reale del tuo negozio. Col tempo, però, i dati operativi accumulati, come carrelli obsoleti, vecchi log e record scaduti, appesantiscono l'amministrazione quotidiana, un ambito che la messa a punto della cache non copre.

Database Cleanup si occupa di quella manutenzione, offrendo una schermata controllata nel Back Office per rimuovere i carrelli obsoleti, le statistiche di ricerca, i prezzi specifici scaduti, i log, le connessioni, i record degli ospiti e i vecchi record e-mail, con un'anteprima prima dell'eliminazione. Completa la suite di performance occupandosi dell'igiene dei dati, una questione separata dal caching a runtime.

Usati insieme, il negozio resta veloce in esecuzione e snello nei dati memorizzati. Performance Revolution mantiene le pagine rapide da servire mentre Database Cleanup aiuta a evitare che le tabelle operative si gonfino di record ormai inutili, così l'amministrazione resta gestibile, con ciascuno strumento responsabile di un aspetto diverso della salute del negozio.

Configurazione della cache Redis in PrestaShop dal back office con test immediato della connessione

Redis Cache Manager & Monitor

99,00 €

★ ★ ★ ★ ★

Complement

Performance Revolution può usare Redis tra i suoi livelli di cache e offre warming e analisi dei colli di bottiglia, ma un negozio attento vuole spesso un modo dedicato per verificare e mantenere la connessione Redis in sé, separato dal più ampio pannello di performance.

Redis Dashboard & Key Manager fornisce proprio questo: un pannello nel Back Office per configurare host, porta, password, database e prefisso delle chiavi, testare la connessione tramite l'estensione PHP redis e visualizzare metriche in tempo reale come versione, uptime e memoria. Completa Performance Revolution concentrandosi sulla verifica e pulizia di Redis come compito a sé.

Insieme ottieni una gestione ampia delle performance più una visione chiara e mirata del tuo backend Redis. Performance Revolution gestisce strategia di caching e colli di bottiglia mentre Redis Dashboard & Key Manager rende il livello Redis facile da controllare e pulire, così è meno probabile farsi sorprendere da un backend di cache mal configurato, con ciascuno strumento che copre una fetta diversa dello stesso obiettivo di velocità.

Accelerazione del negozio PrestaShop con un audit di profiling PHP, query, caching e Core Web Vitals

PrestaShop Speed & Core Web Vitals Audit

490,00 €

★ ★ ★ ★ ★

Measurement

Performance Revolution ti dà i comandi per agire sulla velocità, ma capire quali contano di più per il tuo negozio specifico, e se il vero collo di bottiglia sia PHP, le query, gli asset o l'hosting, richiede spesso una lettura esterna basata su evidenze.

Performance Audit fornisce questo: profila il tuo sito in produzione su PHP, query lente, cache e CCC, Core Web Vitals, pipeline delle immagini, asset del tema, hosting e CDN, e poi classifica ogni collo di bottiglia in base al suo impatto su tempi di caricamento e conversioni. Completa il modulo diagnosticando anziché configurare.

Il vantaggio è che la tua messa a punto è guidata. Mantieni Performance Revolution per applicare modifiche a cache e asset mentre l'audit ti dice, in ordine di priorità, dove si trovano i rallentamenti reali sul tuo negozio effettivo, così lo sforzo va al collo di bottiglia con il maggior ritorno invece di disperdersi su ogni impostazione disponibile.

Visualizza tutti i problemi noti

14 Implementato

14 richieste

Caricamento richieste funzionalità...

Vedi la roadmap completa

Reso entro 30 giorni
Reso semplice - senza domande

Moduli Plug & Play
Installa, configura e guadagna

Supporto al primo posto
Priorità ad aiuto e soddisfazione

Potrebbe anche piacerti

Aiuta i clienti PrestaShop a trovare prodotti rapidamente con ricerca AJAX istantanea

Smart Search Revolution

299,00 €

★ ★ ★ ★ ★

Esplorazione dei media prodotto con gallerie Swiper, video e lightbox PhotoSwipe in PrestaShop

Gallery Revolution

299,00 €

★ ★ ★ ★ ★

Ricerca a faccette più veloce sul negozio PrestaShop con URL di filtro puliti e pagine SEO

Filter Revolution

299,00 €

★ ★ ★ ★ ★

Visualizzazione di segnali di viste e vendite recenti sulle pagine prodotto PrestaShop

Product Sales & Views Live Stats

149,00 €

★ ★ ★ ★ ★

Cookie	Fornitore	Finalità	Durata
PrestaShop-*	PrestaShop	Gestione della sessione e funzionalità del carrello	Sessione
PHPSESSID	PHP	Identificativo sessione PHP	Sessione
mprcr_consent	MPR Cookies Revolution	Memorizza le preferenze di consenso dei cookie	365 giorno/i
mprcr_version	MPR Cookies Revolution	Traccia la versione della configurazione del consenso	365 giorno/i

Cookie	Fornitore	Finalità	Durata
TawkConnectionTime	Tawk.to	Tiene traccia del tempo di connessione della sessione chat	Sessione
__tawkuuid	Tawk.to	Identifica i visitatori ricorrenti della chat	6 mese/i

Cookie	Fornitore	Finalità	Durata
_ga	Google Analytics	Distingue utenti unici assegnando un numero generato casualmente	2 anno/i
_ga_*	Google Analytics	Utilizzato per mantenere lo stato della sessione tra le richieste di pagina	2 anno/i
_gid	Google Analytics	Distingue utenti unici per 24 ore	24 ora/e