Cache a pagina intera PrestaShop, Redis e cache CDN

Cosa faremmo

Misureremmo il percorso delle richieste in produzione prima di scegliere un'altra cache. Mantieni una cache funzionante se garantisce la correttezza dei dati e riduce il carico misurato. Usa la cache a pagina intera per le visite pubbliche ripetute idonee e intervieni anche sulle operazioni costose non memorizzate nella cache, soprattutto carrello e checkout. Redis è un'opzione quando un adattatore implementato può riutilizzare i dati che causano il ritardo.

Il percorso dipende dalle versioni esistenti di PrestaShop e PHP, da moduli, integrazioni, tema, dati del catalogo, gruppi di clienti, mercati e traffico. Considera la capacità del team di monitorare, svuotare e ripristinare ogni servizio aggiunto. Un'importazione delle scorte dall'ERP, prezzi dipendenti dal paese o un'intestazione personalizzata possono cambiare la politica sicura anche quando due negozi usano lo stesso modulo di cache.

Apporta la modifica su una copia di staging privata con dati rappresentativi e gli stessi moduli, integrazioni e tema pertinenti. Isola namespace della cache e archiviazione delle sessioni dalla produzione e impedisci a ordini di prova, email ed esportazioni di raggiungere i sistemi di produzione. Modifica un livello alla volta, prova navigazione, aggiornamenti e ripristino dopo un errore, poi pianifica il passaggio in produzione tenendo disponibile la configurazione precedente e designando chi verifica ordini e aggiornamento dei dati.

Se vuoi valutare il collo di bottiglia prima di scegliere una cache, il PrestaShop Speed & Core Web Vitals Audit fornisce un piano di interventi basato su misurazioni e ordinato per priorità; l'implementazione viene definita separatamente.

Quale percorso corrisponde ai tuoi riscontri?

Individua il livello di cache che stai modificando

Una cache è utile solo quando l'applicazione la legge. Installare Redis non sposta automaticamente in memoria tutte le cache di PrestaShop.

Smarty normalmente riutilizza i template compilati. Non compila ogni template a ogni richiesta. PrestaShop avvia Smarty con la cache globale dell'output disattivata e gestisce la cache in modo selettivo. Usa le impostazioni supportate del back office anziché modificare indiscriminatamente la cache globale dell'output.

Le schermate Prestazioni di PrestaShop 1.7.8 e 9 elencano i backend Memcache, Memcached, APC/APCu e XCache, in base alle estensioni installate. Non offrono Redis o un backend su filesystem in quel selettore. Il precedente CacheFs è un'implementazione separata. Redis richiede un adattatore o un modulo che implementi il livello che intendi usare.

Cache::store() usa un array locale alla richiesta, mentre Configuration ha cache statiche. I risultati idonei del database possono usare il backend Cache persistente. Cambiare quel backend non reindirizza ogni ricerca di categorie, hook, configurazioni o template.

Scegli una politica sicura per la cache a pagina intera

La cache a pagina intera memorizza una risposta generata idonea per i visitatori successivi. Se non c'è un riscontro nella cache, la generazione normale avviene comunque. Una cache delle pagine PHP può ridurre il lavoro successivo di controller e template mantenendo il costo dell'inizializzazione. Un riscontro nel proxy o nella CDN può evitare completamente il server di origine.

Inizia dalle pagine pubbliche per utenti anonimi. Escludi carrello, checkout, autenticazione, pagine dell'account, percorsi del back office, endpoint privati dei moduli, webservice, callback e richieste che modificano lo stato. Considera anche AJAX, parametri di query, link di anteprima, cookie di sessione e risposte che impostano cookie.

Una chiave di cache deve distinguere ogni contesto che modifica la risposta pubblica. A seconda del negozio, può includere hostname, negozio, lingua, valuta, paese, contesto fiscale, visualizzazione per dispositivo e parametri di query supportati. I prezzi per gruppo clienti e le promozioni personalizzate richiedono particolare attenzione.

Non servire a un cliente i contenuti privati di un altro. Se un contesto non può essere rappresentato in modo sicuro in una chiave, escludilo dalla cache. Evita di rimuovere i cookie solo per forzare un riscontro nella cache. Verifica sia la ricerca nella cache sia la decisione di memorizzare una risposta appena generata.

Frammenti dinamici, popolamento tramite AJAX, edge-side includes ed esclusione delle richieste personalizzate sono soluzioni diverse. Il popolamento successivo e lo sfarfallio non sono proprietà inevitabili della cache a pagina intera. Se la tua implementazione sostituisce frammenti dell'intestazione o del carrello dopo il caricamento, riserva spazio e verifica i dispositivi lenti. Un contatore del carrello che mostra zero non dimostra, da solo, che il carrello sul server sia vuoto.

Performance Revolution esegue la propria cache delle pagine all'origine all'interno di PHP dopo il bootstrap e la sua politica di ammissibilità controlla cliente, carrello e altri contesti della richiesta. La pagina di aiuto tratta i workflow supportati per cache delle pagine, CSS critico, preriscaldamento e CDN.

L'invalidazione fa parte del progetto

• Svuota o aggiorna le voci interessate dopo modifiche a prodotti, categorie, scorte, prezzi, promozioni, traduzioni e configurazione.
• Considera l'attivazione e la scadenza programmate delle regole prezzo.
• Richiedi a importazioni e integrazioni di attivare l'invalidazione appropriata. Le scritture dirette nel database possono aggirare gli hook dell'applicazione.
• Usa il TTL come limite alla durata dei dati, non come prova che le modifiche diventino visibili immediatamente.
• Preriscalda solo le pagine pubbliche idonee ed evita di sovraccaricare il server di origine con richieste simultanee prive di riscontro nella cache.

Verifica una modifica al prezzo e una variazione delle scorte attraverso ogni percorso di aggiornamento che usi. Uno svuotamento manuale può risolvere un incidente, ma dati ricorrentemente obsoleti richiedono una correzione dell'invalidazione.

Esempio pratico: prezzi pubblici e importazione delle scorte dall'ERP

Il tuo negozio vende al dettaglio a visitatori di paesi diversi e offre prezzi separati ai clienti professionali autenticati. Preriscalda una pagina prodotto e una pagina categoria pubbliche in ogni contesto di prezzo supportato, poi accedi come cliente professionale. Confronta il prezzo visualizzato, la visualizzazione delle imposte e il totale del carrello con un riferimento senza cache; la visita del cliente professionale deve seguire la politica di esclusione concordata.

In staging, preriscalda le varianti pubbliche delle pagine prodotto e degli elenchi e conferma i riscontri in ogni livello di cache HTML abilitato. Modifica solo il prezzo nel back office, poi confronta ogni variante con un riferimento senza cache prima di qualsiasi svuotamento manuale. Preriscalda di nuovo, conferma i riscontri, poi modifica solo le scorte tramite l'effettiva importazione ERP e ripeti i controlli, inclusi messaggi di disponibilità e copie sui nodi periferici. Prova ogni percorso di aggiornamento separatamente: se uno lascia dati vecchi, escludi la cache delle pagine interessata finché quel percorso non la invalida in modo affidabile.

Collega Redis a un'integrazione implementata

Redis è un servizio chiave-valore in memoria, eseguito sul tuo server o fornito dal tuo hosting. Può archiviare valori della cache, voci della cache delle pagine o sessioni PHP quando un'integrazione corrispondente lo usa. Identifica prima l'adattatore, le versioni PrestaShop/PHP supportate, il formato delle chiavi, la politica TTL, l'invalidazione e il comportamento in caso di errore.

1. Conferma che il tuo hosting fornisca un servizio Redis raggiungibile. Un servizio gestito dall'hosting non richiede che tu abbia accesso SSH.
2. Verifica il client PHP richiesto nell'ambiente PHP web, non soltanto in PHP CLI. PHP-FPM e CLI possono caricare configurazioni diverse.
3. Configura host, porta, autenticazione, TLS dove richiesto, database e namespace nell'integrazione scelta. Nei container, usa l'indirizzo corretto del servizio; localhost indica il container attuale.
4. Assegna a ogni installazione e all'ambito negozio/gruppo richiesto un namespace esplicito. Un prefisso predefinito condiviso come ps_ non isola i negozi.
5. Visita pagine rappresentative e verifica chiavi, TTL e letture/scritture specifici dell'adattatore.
6. Verifica invalidazione, errore di connessione e ripristino nell'ambiente di staging.

Esempi diagnostici locali, supponendo che Redis sia intenzionalmente raggiungibile sullo stesso host alla porta 6379:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 -n 0 DBSIZE

Rispetta i requisiti di autenticazione e trasporto del tuo servizio. PONG conferma la raggiungibilità, non che PrestaShop usi Redis. Un numero di chiavi diverso da zero può appartenere a un'altra applicazione. Esamina il namespace e l'attività dell'integrazione selezionata. I riscontri e i mancati riscontri dell'intera istanza non possono identificare il beneficio per un singolo negozio.

Usa SCAN con un prefisso noto per un'ispezione controllata. MONITOR può esporre i dati dei comandi e aggiungere carico; riservane brevi usi diagnostici a un ambiente controllato.

Redis Cache Manager & Monitor fornisce test amministrativi della connessione, monitoraggio e gestione di namespace/chiavi; la pagina di aiuto tratta i workflow del modulo.

Gli adattatori della cache applicativa, la configurazione delle sessioni PHP e la cache a pagina intera restano interventi di integrazione separati. Un'opzione salvata o una connessione riuscita dalla dashboard non dimostrano che una cache applicativa sia cambiata. Se il namespace previsto resta vuoto, controlla database selezionato, prefisso e ammissibilità della pagina prima di modificare la capacità. Controlla gli errori di connessione dell'ambiente di esecuzione web e la configurazione dell'adattatore; installare un'estensione PHP da solo non aggiunge Redis al selettore nativo.

Memcached è un'altra opzione di cache in memoria, con funzionalità diverse. Sia Redis sia Memcached possono avere gestori delle sessioni PHP configurati separatamente. Scegli in base ad adattatori supportati, esigenze operative e misurazioni anziché presumere che uno sia sempre più veloce.

Distingui tra sessioni, espulsione e durabilità

I carrelli PrestaShop sono record del database. Anche l'identità del cliente coinvolge i cookie di PrestaShop e record nel database. Le sessioni PHP/Symfony sono un altro livello. Spostare le sessioni PHP su Redis non sposta le righe dei carrelli né garantisce la continuità dell'accesso dei clienti.

Se cambi il gestore delle sessioni PHP, segui le indicazioni di configurazione di phpredis per la versione installata e applicale al pool PHP-FPM corretto. Verifica dove il framework della tua applicazione prevede di configurare le sessioni.

Definisci TTL delle sessioni, blocchi, autenticazione, capacità, persistenza e comportamento in caso di errore. Le sessioni su Redis possono comunque richiedere blocchi per impedire che richieste simultanee sovrascrivano lo stato. Verifica richieste parallele dalla stessa sessione e da sessioni diverse.

Numeri di database Redis separati possono aiutare a distinguere le chiavi, ma condividono memoria dell'istanza, politica di espulsione ed esposizione ai guasti. Uno svuotamento della cache può coinvolgere le sessioni se l'ambito è sbagliato. Preferisci un servizio separato per le sessioni quando richiedono una politica diversa di durabilità ed espulsione.

Le politiche di espulsione di Redis si applicano all'istanza. volatile-lru espelle le chiavi con TTL, che possono includere le sessioni. Non le protegge. Scegli consapevolmente l'espulsione della cache e monitora gli errori di scrittura se usi una politica senza espulsione.

Per le sessioni, scegli esplicitamente persistenza RDB/AOF, replica e obiettivi di ripristino. La persistenza riduce alcuni scenari di perdita ma non garantisce assenza di perdite o accessi ininterrotti.

In un negozio con bilanciamento del carico, verifica che ogni nodo web usi il backend condiviso previsto e un namespace compatibile. Prova un percorso che passa tra i nodi. La sola archiviazione condivisa delle sessioni PHP non può correggere incoerenze nella configurazione applicativa, nell'ambito dei cookie o nei segreti e non sostituisce il database che contiene i carrelli.

Dimensiona Redis usando misurazioni di numero di chiavi, dimensioni dei dati, varianti, TTL e picchi di utilizzo. Osserva used_memory, used_memory_peak, maxmemory, evicted_keys, scritture rifiutate e connessioni. L'espulsione può essere prevista in una cache eliminabile con capacità limitata; interpretala insieme alla latenza e ai riscontri nella cache. Non esiste una formula della memoria basata sulle dimensioni del catalogo o un obiettivo universale del 90% di riscontri nella cache.

Calcola il tasso di riscontro per una finestra di osservazione dividendo l'incremento di keyspace_hits per la somma degli incrementi di keyspace_hits e keyspace_misses, escludendo le finestre con azzeramento dei contatori o senza ricerche. Questi contatori coprono l'intera istanza Redis, non solo il negozio. Un tasso di riutilizzo basso può riflettere molte varianti di paese/valuta o URL visitati raramente più volte. Correlalo con scadenze, importazioni, eventi di svuotamento e pressione sulla memoria prima di aumentare maxmemory. Monitora connected_clients in relazione al traffico e agli errori di connessione; la sola crescita non dimostra una perdita di risorse.

Configura Cloudflare o Varnish intorno all'applicazione

Il comportamento predefinito della cache di Cloudflare riguarda principalmente le risorse statiche idonee; la cache HTML richiede una configurazione deliberata. Inizia dalla distribuzione statica e conferma che le richieste dinamiche restino private. Usa TLS Full (Strict) con un certificato di origine valido e un hostname corrispondente. La modalità Flexible usa HTTP verso il server di origine e può entrare in conflitto con i reindirizzamenti HTTPS.

• Escludi carrello, checkout, account, amministrazione, API, AJAX e callback di pagamento dalla cache HTML condivisa.
• Rispetta le direttive private/no-store e il comportamento di Set-Cookie. Verifica le regole effettive sui nodi periferici, non soltanto gli header del server di origine.
• Lascia senza proxy i record DNS relativi alla posta dove richiesto dal servizio email.
• Ripristina gli indirizzi reali dei visitatori solo da proxy Cloudflare attendibili. Non fidarti di un header di inoltro arbitrario fornito dal client.
• Verifica le regole WAF e anti-bot su callback di pagamento, inserimento degli ordini e integrazioni.
• Disattiva Rocket Loader o escludi esplicitamente gli script del checkout se modifica l'ordine richiesto degli script; verifica l'intero flusso.

Un'integrazione HTML CDN controllata può contrassegnare per la cache solo le risposte GET/HEAD anonime idonee e inviare header di esclusione per gli altri contesti. Configura i meccanismi di svuotamento supportati e verifica le funzionalità attuali del tuo account. Gli header da soli non dimostrano che il nodo periferico abbia memorizzato o escluso una risposta.

Varnish è un reverse proxy HTTP. In caso di riscontro nella cache può rispondere prima dell'esecuzione di PHP. Richiede regole per metodi, cookie, chiavi di cache, risposte private, invalidazione e comportamento in caso di errore. Molte installazioni terminano TLS in un componente separato. I frammenti dinamici sono un'attività di implementazione facoltativa.

Aggiungi un reverse proxy quando il traffico anonimo misurato o la saturazione dei worker PHP ne giustificano la gestione. Non può eliminare il lavoro del checkout non memorizzato nella cache. Predisponi sufficiente capacità sul server di origine per mancati riscontri, svuotamenti e interruzioni e proteggi gli endpoint di invalidazione.

Svuota e diagnostica la cache corretta

Inizia da Parametri avanzati > Prestazioni > Svuota cache. Registra il sintomo che stai analizzando. Aggiornare il browser non svuota le cache del server di origine, di OPcache o dei nodi periferici.

1. Usa lo staging dove possibile. Modifica o escludi un livello alla volta.
2. Svuota le cache supportate dall'applicazione e verifica la pagina direttamente sul server di origine attraverso il tuo percorso diagnostico autorizzato.
3. Invalida gli eventuali moduli o namespace Redis separati coinvolti.
4. Reimposta OPcache web solo se il deployment lo richiede. Un opcache_reset() da CLI normalmente non reimposta il pool PHP-FPM web.
5. Svuota le voci interessate del proxy/CDN dopo aver corretto il server di origine.
6. Ricontrolla una nuova richiesta anonima e una richiesta personalizzata, poi ripristina le impostazioni previste.

var/cache/prod e var/cache/dev restano in uso per le cache del framework e di Smarty dopo l'installazione di un adattatore Redis separato. Le strutture precedenti della versione 1.6 usano cache/smarty; il precedente CacheFs usa cache/cachefs. Conferma la versione esatta e la directory principale prima di qualsiasi pulizia del filesystem.

Preferisci l'operazione supportata di svuotamento della cache. Se il ripristino richiede una pulizia manuale, isola il sito, conserva la struttura delle directory e i controlli di accesso, esegui le operazioni come utente dell'applicazione e verifica proprietà e ricostruzione della cache. Non eseguire un'eliminazione ricorsiva senza un ambito preciso da una directory di lavoro incerta.

Usa un'invalidazione del namespace che tenga conto dell'integrazione. FLUSHDB elimina ogni chiave del database selezionato; FLUSHALL elimina tutti i database dell'istanza. Nessuno dei due sostituisce in modo sicuro uno svuotamento limitato al negozio su un'infrastruttura condivisa.

Se la cache restituisce prezzi, informazioni personali o stato del checkout errati, escludi il livello interessato finché non è corretto e verificato. Le impostazioni della cache in produzione devono seguire la correttezza e il carico misurato, anziché una regola incondizionata che imponga di lasciare ogni cache attiva.

Misura le prestazioni e correggi il lavoro non memorizzato nella cache

Registra le risposte a cache fredda e calda per gli stessi URL, dati, lingua, valuta, dispositivo e stato di accesso. Includi concorrenza, carico del server di origine e stato della cache. Confronta la normale navigazione con le richieste di carrello e checkout. Misura prove ripetute anziché una singola richiesta.

Il TTFB misura il ritardo prima dell'inizio della risposta. Aiuta la diagnosi del caricamento ma non è un Core Web Vital. I Core Web Vitals sono LCP, INP e CLS. Riporta LCP e INP come tempi, CLS come valore senza unità e il punteggio delle prestazioni Lighthouse separatamente. Punteggi migliori non garantiscono un miglior posizionamento.

Usa il profiler precedente di PrestaShop per le normali richieste del negozio basate sull'architettura precedente, in uno staging protetto. Usa la profilazione Symfony per le richieste gestite tramite Symfony. APM in produzione, log delle query lente e metriche del server web possono aiutare senza esporre una pagina di debug.

• Analizza hook costosi, query ripetute e chiamate esterne in tempo reale. Memorizza nella cache solo dati di cui puoi definire aggiornamento e ambito.
• Correggi indici mancanti e query costose. Applica una politica di conservazione prima di ripulire log, record email o dati di connessione.
• Usa le impostazioni supportate di compilazione Smarty e svuota i template compilati dopo il deployment, dove necessario.
• Attiva e dimensiona OPcache per l'ambiente web. JIT è separato e richiede un benchmark dell'applicazione. Se la verifica dei timestamp è disattivata, reimposta OPcache in modo affidabile durante il deployment.
• Scegli PHP dalla matrice di compatibilità della versione esatta. PrestaShop 1.7.8 non supporta ufficialmente PHP 8.
• Ottimizza MySQL in base al carico di lavoro e alla memoria totale disponibile. MySQL 8.0.30+ usa innodb_redo_log_capacity; MariaDB e le versioni MySQL precedenti sono diverse.
• Verifica ottimizzazione CSS/JavaScript, CSS critico, immagini responsive e script di terze parti. Riserva le dimensioni delle immagini e lo spazio dell'interfaccia dinamica per limitare gli spostamenti del layout.

Se dopo aver abilitato una cache la stessa richiesta resta lenta, profila anche i meccanismi della cache: costruzione delle chiavi, serializzazione, blocchi e calcolo ripetuto degli hash delle risorse possono aggiungere lavoro al percorso della richiesta. Confronta quel costo con il lavoro risparmiato, anche in assenza di un riscontro nella cache.

Una cache può ridurre il lavoro ripetuto mentre le richieste senza riscontro restano lente. Mantienila quando migliora in modo sicuro le prestazioni misurate; rimuovila o sostituiscila solo dopo aver verificato il carico risultante e l'esperienza del cliente.

Prova il passaggio e consegna le procedure di ripristino

1. Registra impostazioni attuali, tempi delle richieste e stato della cache per pagine rappresentative di home, categoria e prodotto, oltre a carrello e checkout. Conserva i contesti esatti dei test affinché il confronto sia ripetibile.
2. In staging, preriscalda le varianti pubbliche previste. Usa profili browser separati per visitatori anonimi e clienti con gruppi o valute diversi. Controlla il comportamento di carrello, accesso e intestazione personalizzata oltre al corpo della pagina.
3. Esegui aggiornamenti tramite il back office, promozioni pianificate e ogni importazione o integrazione che usi. Confronta la cache applicativa e le eventuali copie proxy/CDN con i dati aggiornati attesi.
4. Prova uno svuotamento e la navigazione a cache fredda con un numero rappresentativo di richieste simultanee. Poi rendi indisponibile Redis o il servizio di cache delle pagine nell'ambiente controllato e verifica errori, carico in fallback e ripristino separatamente per ogni livello abilitato.
5. Concorda la finestra in produzione, la condizione di rollback e il responsabile. Applica la configurazione verificata, invalida o preriscalda solo l'ambito previsto e controlla navigazione reale, acquisti e importazione successiva dopo il passaggio.

Il rollback per HTML in cache eliminabile può consistere nell'escludere quel livello e svuotarne le copie. Il rollback di un gestore delle sessioni richiede una procedura propria: l'archivio precedente potrebbe non contenere le sessioni create dopo il passaggio. Concorda le aspettative di continuità prima di cambiare gestore e prova entrambe le direzioni. Non sostituire il database di produzione con quello di staging per attivare una configurazione di cache.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quale livello cambia, dove un riscontro nella cache interrompe l'elaborazione e cosa continua a essere eseguito?
• Quali contesti di richiesta sono inclusi nelle chiavi o esclusi e dove sono i riscontri che i contenuti privati non possano entrare nell'archiviazione condivisa?
• Quali aggiornamenti invalidano quali copie e chi è responsabile dell'invalidazione per importazioni ERP e promozioni pianificate?
• Cosa succede durante uno svuotamento, un'interruzione della cache o un rollback del gestore delle sessioni e il server di origine può sostenere il carico risultante?
• Dove sono registrati per il personale impostazioni verificate, mappa dei namespace, monitoraggio, istruzioni di svuotamento mirato e procedura di ripristino?

Domande dei titolari

Quale cache dovrei acquistare per prima?

Scegli in base alla richiesta lenta e al lavoro che ripete. Chiedi una misurazione iniziale e una prova reversibile prima di acquistare infrastruttura o un altro modulo. Se la diagnosi non è chiara, usa la guida alle prestazioni per organizzare le misurazioni.

Redis sostituisce OPcache o il database?

No. OPcache riutilizza codice PHP compilato; un'integrazione Redis riutilizza valori selezionati o archivia sessioni. Il database continua a contenere le registrazioni del negozio e le richieste senza cache necessitano comunque di capacità sufficiente.

Perché una visita ripetuta è veloce mentre un nuovo visitatore attende ancora?

La visita ripetuta può trovare un riscontro nella cache del browser, delle pagine o dei dati che manca alla nuova richiesta. Controlla lo stato effettivo della cache e il contesto del visitatore, poi confronta risultati a cache fredda e calda. Il tuo browser con cache già popolata non dimostra l'esperienza della prima visita.

Devo lasciare tutte le cache abilitate durante un problema?

Escludi il livello che serve contenuti errati o privati, poi analizzalo usando un riferimento senza cache. Controlla il carico del server di origine mentre gestisce più richieste e ripristina la politica verificata dopo aver risolto il problema.

Posso rimuovere la cache a pagina intera dopo aver ottimizzato il negozio?

Prova prima a escluderla in staging con un carico rappresentativo. Mantienila o rimuovila in base a correttezza, capacità nei picchi ed esperienza del cliente; una pagina senza cache più veloce da sola non dimostra che il traffico di picco sia sostenibile.