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 Instant Redis 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 Instant Redis.

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 - PrestaShop performance Redis cache and speed optimization

Performance Revolution - Reduce the sales cost of slow pages

Performance Revolution - Act on cache problems quickly

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: 269.10 EUR
Availability: InStock

Modulo Performance e Cache - Redis, Minificazione CSS/JS, Immagini WebP, Lazy Load + CDN

Nessuna recensione

PrestaShop 1.6 – 9.0PHP 7.1+Versione 1.5.8

269,10 € 299,00 € (Risparmi 10%)

IVA esclusa

La gestione delle prestazioni PrestaShop con cache Redis rende visibile e controllabile il lavoro sulla velocità, dai livelli di cache alle misurazioni degli utenti reali. Le pagine lente sprecano traffico a pagamento e fanno abbandonare i clienti prima del pagamento; questo modulo offre al team controlli pratici per cache, preriscaldamento, gestione delle risorse e analisi dei rallentamenti in un unico pannello di amministrazione.

La configurazione supporta rilevamento automatico, Redis, APCu e cache su file, oltre a durata, connessione Redis, cache di sezioni riutilizzabili, cache delle query e soglie per query lente. I controlli delle risorse includono riduzione dimensioni, raggruppamento, rinvio intelligente delle risorse dei moduli, unione CSS, rimozione del CSS inutilizzato, CSS critico, suggerimenti risorse, rinvio JavaScript a riposo, caricamento differito nativo e opzioni WebP o AVIF.

Il modulo salva campioni di utenti reali e riepiloghi orari per TTFB, FCP, LCP, CLS, FID, INP, tempi di rendering, dispositivo e URL. Preriscaldamento cache, cache pagina Cloudflare, comportamento di pulizia e salvataggi temporanei della modalità sviluppo inseriscono il lavoro sulle prestazioni nella normale manutenzione del negozio.

Download immediato dopo l'acquisto

Instant Live Demo Real store, ready in ~1 min

5 demo installs ready · refills every 48h

Richiedi preventivo

Licenza a vita per dominio — tua per sempre. Include 3 mesi di supporto e aggiornamenti. Learn more

The demo is the complete module — buy anytime and activate the same installation, nothing to reinstall and nothing lost. Open the module's License tab and click "Activate from mypresta.rocks" (or paste your key); your settings and data stay exactly as they are. Updates install in one click from the Update tab.

Supporto e aggiornamenti

3 months Gratuito 6 months +39,00 € 9 months +65,00 € 12 months +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 €

Più tipi di cache. La configurazione supporta rilevamento automatico, Redis, APCu e cache su file con durata, connessione, password e prefisso chiave.
Cache per contenuti riutilizzabili e query. Le impostazioni coprono sezioni di pagina, cache delle query, durata della cache e registro delle query lente con soglia configurabile.
Controlli di ottimizzazione risorse. Il personale può gestire riduzione dimensioni, raggruppamento, rinvio intelligente, unione CSS, CSS critico, suggerimenti risorse e JavaScript posticipato.
Opzioni di consegna immagini. Il modulo espone caricamento differito nativo e opzioni WebP e AVIF, compreso il filtro dei tipi immagine negli elenchi.
Dati sui tempi dei visitatori in tempo reale. I beacon del front-end registrano tempi di caricamento, stabilità, dispositivo, URL e negozio, con riepiloghi orari per il confronto.
Preriscaldamento origine e rete perimetrale. Le impostazioni controllano sorgente URL, concorrenza, durata massima, IP locale, limiti recenti, preriscaldamento completo dopo rilascio e intervallo Cloudflare.
Gestione cache pagina Cloudflare. Le impostazioni coprono attivazione, durata, identificativo zona, credenziali, URL negozio e pulizia automatica dopo salvataggio di prodotti, categorie o pagine CMS.
Modalità sviluppo temporanea gestita. La configurazione può salvare impostazioni cache, disattivare funzioni correlate e mantenere scadenza e valori salvati.

Prestazioni PrestaShop, cache Redis e ottimizzazione della velocità

PrestaShop Speed & Redis Cache - Performance aiuta i proprietari di negozi a identificare e ridurre i problemi di velocità che costano conversioni: pagine senza cache, risorse pesanti, query lente e prestazioni reali scarse. Le pagine lente fanno aspettare i clienti, e l’attesa danneggia ricavi, efficacia pubblicitaria e fiducia. Il modulo riunisce pannelli, livelli Redis, pulizia, preriscaldamento, analisi dei rallentamenti, misure reali e impostazioni di ottimizzazione.

Riduci il costo commerciale delle pagine lente

La velocità della pagina influisce sul fatto che i visitatori restino abbastanza da vedere i prodotti e completare il pagamento. Una categoria o una pagina prodotto lenta può sprecare traffico pagato perché i clienti escono prima che il negozio converta. Performance Revolution mostra stato della cache, percentuali di successo e azioni rapide per capire se gli strumenti aiutano il percorso d’acquisto.

Intervieni rapidamente sui problemi di cache

I problemi di cache spesso emergono nel momento peggiore: dopo una campagna, un aggiornamento prodotto o un picco di traffico. Se il primo visitatore dopo una modifica paga il costo di ricostruire tutto, il negozio sembra lento proprio quando i clienti contano di più. Il modulo permette di pulire e preriscaldare cache su richiesta, anche in modo pianificato.

Trova i veri colli di bottiglia

Aggiungere altra cache può nascondere un negozio lento senza risolverlo. Ricerche dati lente, contenuti generati pesanti o script non essenziali possono continuare a danneggiare i clienti reali. Performance Revolution include registrazione delle query lente, statistiche e raccolta di velocità reale per lavorare sui veri freni.

Performance Revolution — Cache Redis e velocità per PrestaShop - Impostazioni rinvio risorse

Rendi le pagine utilizzabili prima

Alcuni script sono utili ma non devono bloccare la prima interazione. Se risorse secondarie ritardano la pagina visibile, i clienti percepiscono il negozio come lento anche quando il caricamento termina. Il modulo può rimandare risorse non essenziali e snellire stili, immagini e contenuti generati sotto il tuo controllo.

Misure reali, rinvio delle risorse e preriscaldamento cache

Performance Revolution centralizza i controlli nel pannello di amministrazione: livelli cache, browser cache, pulizia e preriscaldamento, analisi query lente, misure reali, rinvio risorse e impostazioni di ottimizzazione. È pensato per la gestione pratica del negozio, non per interventi server isolati. I risultati dipendono comunque da hosting, tema, moduli e configurazione corretta.

Riferimento

mprperformancerevolution
Disponibile

2147483647 Items
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 i clienti di noi

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.

1258 domande

9 categorie

2014 sviluppo moduli dal

1.7–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 €

★ ★ ★ ★ ★

Vedi dettagli

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

Instant Redis

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.

Instant Redis 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 Instant Redis 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

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

Performance Revolution

Modulo Performance e Cache - Redis, Minificazione CSS/JS, Immagini WebP, Lazy Load + CDN

Prestazioni PrestaShop, cache Redis e ottimizzazione della velocità

Riduci il costo commerciale delle pagine lente

Intervieni rapidamente sui problemi di cache

Trova i veri colli di bottiglia

Rendi le pagine utilizzabili prima

Misure reali, rinvio delle risorse e preriscaldamento cache

Cosa dicono i clienti di noi

Funziona bene con Performance Revolution

You might also like