Performance Revolution: configurazione e aiuto

Carica lo ZIP in Moduli > "Module Manager", installalo e fai clic su "Configure". Il menu del back office è Prestazioni, con Pannello di controllo, "Cache", Risorse, Query, "Backup", Impostazioni e Controllo sistema.

Prima di attivare altri livelli, annota il comportamento di homepage, categoria, prodotto, carrello, account e checkout. Prova sia in un browser cliente sia in un browser dipendente. Seleziona il negozio desiderato e salva una copia della configurazione prima di modificare la cache del core o le regole CDN.

Inizia da Impostazioni > Backend cache. Il processo PHP deve poter scrivere nelle directory della cache PrestaShop e delle risorse generate. L'installazione della cache oggetti Redis di PrestaShop richiede anche accesso alla classe cache del core interessata e ai file di configurazione. Le azioni Cloudflare richiedono un token autorizzato per la zona selezionata e le operazioni richieste.

Salva e controlla l'adattatore selezionato in Pannello di controllo. Se Redis non si connette, verifica hostname, porta, autenticazione, database e supporto Redis di PHP. Non presumere che scegliere il backend del modulo attivi anche la cache oggetti del core.

Apri "Cache" > Panoramica per gli interruttori Cache globale, "Front Office", Pannello di amministrazione e "Webservice". Sono attivi per impostazione predefinita. L'interruttore globale controlla l'uso della cache del modulo, quelli di ambito limitano i relativi contesti di richiesta.

Usa "Cache" > Livelli per controllare i livelli, "Browser" per esaminare le voci, Pagine per i dati della cache pagine e Preset per i preset disponibili. Leggi un preset prima di applicarlo perché modifica più impostazioni insieme.

Apri Impostazioni > Caching dei frammenti.

Uno sviluppatore può memorizzare un frammento di categoria includendone l'identità:

{mpr_cache id="category_products" ttl=3600 tags=["product","category"] vary=["category" => $category.id]}
  {foreach from=$products item=product}
    {include file='catalog/_partials/miniatures/product.tpl' product=$product}
  {/foreach}
{/mpr_cache}

La chiave cache include lingua, negozio, valuta e gruppo clienti predefinito, a meno che l'inclusione del contesto sia disattivata. Aggiungi a vary ogni altro valore che influisce sul frammento. Non inserire markup specifico del cliente in un frammento condiviso senza adeguata variazione o sostituzione dinamica.

Usa segnaposto dinamici per i valori supportati della richiesta corrente:

<span class="cart-count">{mpr_dynamic name="cart_count"}</span>
<span class="cart-total">{mpr_dynamic name="cart_total"}</span>
<span class="customer-name">{mpr_dynamic name="customer_name" default=""}</span>
<span class="csrf-token">{mpr_dynamic name="csrf_token"}</span>

I nomi supportati comprendono anche valori di cliente, lingua, valuta e negozio. Un provider personalizzato può usare actionMPRDynamicContent:

public function hookActionMPRDynamicContent($params)
{
    if (($params['name'] ?? '') === 'loyalty_points') {
        return (string) $this->getCurrentCustomerPoints();
    }
    return $params['default'] ?? '';
}

Apri Impostazioni > Cache delle query.

Usa Query per esaminare le query raccolte. Attiva la profilazione durante la diagnosi, poi valutane il sovraccarico prima di mantenerla attiva.

Apri Impostazioni > Ottimizzazione risorse. Attiva e prova una modifica alla volta sul tuo tema.

Attivare il CSS generato non avvia un browser durante una richiesta del negozio. Costruiscilo con i worker separati. Stato del CSS iniziale generato segnala la disponibilità. Il worker "Critical CSS" richiede Node 22.12 o successivo e il relativo ambiente browser configurato. Segui le istruzioni incluse nel worker per generazione e distribuzione.

Questi comandi CLI controllano o inizializzano il lavoro; non completano da soli la generazione tramite browser:

php modules/mprperformancerevolution/cli/critical-css.php --targets
php modules/mprperformancerevolution/cli/critical-css.php --seed
php modules/mprperformancerevolution/cli/critical-css.php --status
php modules/mprperformancerevolution/cli/page-type-css.php --status

Ricostruisci i dati CSS offline dopo modifiche rilevanti a fogli di stile, template, script o contenuti. Se i dati generati mancano o non sono validi, il modulo torna ai fogli completi.

Apri Impostazioni > Navigazione istantanea.

Carrello, checkout, account, accesso, link con query string, file, link nofollow e strumenti del modulo sono esclusi dalla politica integrata. Il server convalida anche le richieste speculative.

Apri Impostazioni > Immagini.

La codifica AVIF a runtime può usare GD imageavif o Imagick con supporto AVIF. GD AVIF richiede generalmente PHP 8.1 o successivo. La generazione in batch può usare anche il backend Python incluso quando sono disponibili Python, Pillow, pillow_avif ed esecuzione dei processi. WebP usa le funzionalità GD supportate.

Alle immagini degli elenchi si applicano ulteriori valori predefiniti interni: il filtro dei tipi è disattivato per impostazione predefinita e l'elenco è default_sm,default_md,default_lg,home_default,product_main,product_main_2x. Non sono campi visibili separati nel modulo standard Immagini. Analogamente, la frequenza interna di campionamento RUM è 0.1.

Per un batch controllato, esegui dal negozio installato:

php modules/mprperformancerevolution/scripts/generate-images-cli.php --quality=50 --webp-quality=80 --webp --limit=100

Usa --path=PATH, ripetibile, per limitare il lavoro all'interno della radice del negozio. --force rigenera le varianti esistenti. Controlla conteggi di conversioni, elementi ignorati ed errori prima di un batch più grande.

Apri Impostazioni > Cache delle pagine di origine.

È una vera cache di pagine complete all'origine che usa il gestore cache del modulo. È separata dal caching HTML CDN e dai frammenti Smarty. Richieste di carrello, account, checkout, amministrazione, AJAX, cookie di sessione non sicuri e query sconosciute la escludono secondo la politica a runtime.

Attivala solo dopo aver verificato una pagina anonima pulita e i casi di esclusione richiesti. Richiedi lo stesso URL anonimo due volte e controlla X-MPR-PageCache. Poi prova accesso, creazione del carrello, cambi di valuta/lingua e pagine private in sessioni browser separate.

Apri Impostazioni > Cache pagine CDN. Inizia con la politica cookie predefinita "Strict".

Dopo il salvataggio, usa le Azioni CDN per applicare e verificare le regole e controllarne il risultato. Una modifica della politica cookie riapplica le regole e svuota la zona. Non considerare completata la configurazione se la transizione delle regole è fallita o in attesa.

Prova separatamente caching anonimo ed esclusione privata. Accessi, carrelli, checkout, account, AJAX, route protette dei moduli, personalizzazione e stati di richiesta non sicuri non devono condividere HTML anonimo. Mantieni il periodo di conservazione delle risorse generate finché HTML duraturo fa ancora riferimento a vecchie risorse.

Il modulo invia header cache ed esegue le operazioni Cloudflare supportate. Il caching effettivo sull'edge dipende comunque dalle regole della zona, dai permessi del token API e dal fatto che una risposta sia memorizzabile. Alcuni metodi di svuotamento Cloudflare non sono disponibili in tutti i piani.

Apri Impostazioni > Riscaldamento cache.

Copia il token effettivamente generato nel pianificatore del server. Un comando tipico del runner è:

* * * * * php /var/www/html/modules/mprperformancerevolution/cron.php --token=YOUR_TOKEN --max-tasks=20 --max-seconds=55 --context=cron

Adatta i percorsi PHP e negozio. Il runner gestisce anche pulizie dichiarate, invalidazioni/svuotamenti in attesa, lavori immagini e manutenzione CSS secondo lo stato delle attività. Attivazione della funzione e pianificazione dell'attività sono controlli separati.

Un passaggio manuale dopo il deploy può usare:

php modules/mprperformancerevolution/cli/warm-cache.php --full --both --url-set=all --concurrency=1 --resolve-ip=127.0.0.1 --max-seconds=120

Usa --edge solo per l'edge, --cron per la modalità cron e --help per gli argomenti supportati. Leggi il riepilogo degli stati disattivati, falliti o di scrittura esterna bloccata. Un passaggio sospeso o limitato dal budget può essere previsto con i valori predefiniti prudenti.

Apri Impostazioni > Monitoraggio. Attiva la raccolta delle metriche è attiva per impostazione predefinita, Conservazione delle metriche è 30 giorni e Metriche degli utenti reali sono attive. Il campionamento RUM interno è del 10 percento. Le metriche del pannello includono stato dell'adattatore, hit, miss, percentuale di hit, memoria, query lente e misure disponibili TTFB, FCP, LCP, CLS e INP.

Apri Impostazioni > Modalità dev per sospendere temporaneamente le impostazioni di cache. Modalità dev parte inattiva, salva la configurazione precedente e la ripristina alla disattivazione o scadenza. Modalità debug dipendente parte disattivata e abilita l'output di sviluppo PrestaShop solo per dipendenti riconosciuti con il cookie debug validato del modulo.

In Impostazioni > "Debug", Overlay di debug, Attiva il pannello di debug e Pannello profiler sono disattivati per impostazione predefinita. Indirizzi IP consentiti e ID dei dipendenti consentiti partono vuoti. Profiler: solo dipendenti è attivo per impostazione predefinita. Limita la diagnostica durante i test e disattivala al termine.

I file opzionali del profiler sono in optional-overrides/classes/Hook.php e optional-overrides/classes/db/Db.php. Usa il flusso protetto d'installazione degli override profiler per verificare quelli esistenti. Pulisci lo stato classi/cache PrestaShop secondo quel flusso. Non sovrascrivere override estranei con una copia incondizionata. Rimuovi gli override opzionali del profiler tramite lo stesso flusso quando non servono più.

Dopo ogni modifica della configurazione, controlla homepage, lista, prodotto, carrello e checkout, poi conferma header cache e motivi di esclusione in sessioni cliente separate. Gli hook di catalogo, stock, prezzi e contenuti invalidano i tag supportati, ma modifiche a tema, integrazioni e regole CDN possono richiedere uno svuotamento esplicito.

Se l'adattatore differisce dalla selezione, controlla disponibilità del backend e risoluzione dell'endpoint Redis. Se una pagina esclude la cache, leggi il motivo diagnostico prima di aumentare limiti o cambiare politica cookie. Per HTML obsoleto, controlla separatamente origine ed edge e conferma il completamento dell'invalidazione.

Se bundle, rinvio o modifiche CSS rompono un componente, disattiva l'impostazione interessata, svuota i relativi file generati o la cache e riprova. Per il CSS generato, controlla stato e log del worker. Per errori immagini, verifica encoder e permessi di scrittura. Per riscaldamento in attesa, controlla runner, interruttore della funzione, carico host e budget.

Prima di disinstallare, rimuovi gli override opzionali del profiler installati e controlla le regole CDN attive. Disattiva o rimuovi le regole edge del modulo tramite il flusso CDN, affinché la zona non continui a memorizzare route private senza la protezione d'origine prevista. Salva configurazione e dati generati necessari.

La disinstallazione rimuove attività pianificate, bootstrap debug dipendenti, classe cache Redis installata, menu e tabelle del modulo. Controlla poi la configurazione cache del core PrestaShop e ogni configurazione CDN esterna; non presumere che Module Manager annulli tutta la configurazione remota.

Richiede PrestaShop 1.6.1 o successivo e PHP 7.1 o successivo.