Redazione: 4SYSTEMPubblicato il Aggiornato il

9 lettura minima

Un'efficiente cache WordPress riutilizza i contenuti pubblici senza riutilizzare i dati del visitatore. Un vecchio prezzo, un carrello che sembra vuoto o una forma rifiutata non possono necessariamente essere corretti svuotando tutto. È necessario identificare la risposta coinvolta, il livello che la mantiene e le condizioni in cui varia.

L'impostazione corretta non è "cache all". Consiste nel conservare ciò che può essere condiviso, isolare le sessioni e pianificare un'eliminazione dopo la modifica. La validazione riguarda il contenuto ricevuto e le azioni possibili, non solo la velocità di visualizzazione.

Identifica cosa conserva ogni livello

Possono verificarsi quattro livelli nella stessa visita. Distinguendoli si evita di chiedere a un'estensione di correggere un problema che non controlla.

  • Navigatore : mantiene le risposte localmente, inclusi i file e talvolta HTML. Questa cache appartiene al client, a differenza di una cache condivisa tra i visitatori.[11]
  • Pagina : un'estensione in cui il server mantiene una risposta HTML già prodotta. Se contiene un nome o un cestino, il suo riutilizzo deve essere controllato.
  • Oggetto : l'applicazione riutilizza i dati intermedi, anziché l'intera pagina. Scopri quali oggetti vengono archiviati, con quali chiavi e quale invalidazione. Non dare per scontato che un difetto visivo provenga da questo strato.
  • CDN : Un servizio davanti all'hosting può conservare le risposte indipendentemente dalla cache della pagina. Un'eliminazione in WordPress non dimostra che questa copia sia scomparsa.

Nota l'estensione attiva, le opzioni dell'host, l'eventuale CDN e la cache degli oggetti persistente. Per ciascun livello, identificare chi imposta le esclusioni e chi attiva l'eliminazione. Non sovrapporre due mascherini di pagina senza sapere come si incastrano.

Cache WordPress: legge le direttive senza contraddizioni

Tre direttive HTTP soddisfano esigenze diverse:

  • no-cache consente l'archiviazione, ma richiede la riconvalida prima del riutilizzo da parte della cache HTTP. Non significa “nessuna copia”.[11]
  • no-store chiede di non memorizzare la risposta. Tuttavia, non cancella le vecchie risposte già conservate per questo URL: una correzione deve elaborare anche queste copie.[11]
  • private riserva spazio di archiviazione per le cache private, in particolare per il browser. Non si tratta né di crittografia né di controllo dell'accesso all'account.[11]

Per una risposta personalizzata che necessita di essere riconvalidata, Cache-Control: no-cache, private è uno schema documentato da MDN.[11] Non riservare spazio di archiviazione per le risposte che la tua policy richiede di non conservare.

Una cache gestita può seguire le proprie regole: controllare la documentazione e il comportamento della CDN o del server, non solo Cache-Control.[11] Infine, un cookie non rende automaticamente privata una risposta.[11]

Esclude percorsi dinamici e sessioni principali

WooCommerce chiede di escludere il carrello degli acquisti, la convalida dell'ordine e l'account cliente dalla cache, poiché queste pagine visualizzano informazioni specifiche per il visitatore.[10] Controlla gli URL configurati, le varianti linguistiche e i passaggi dell'account. Una regola mirata solo /cart/ non è sufficiente se il carrello utilizza un altro indirizzo.

Il nostro approccio consiste quindi nel tracciare le variazioni: connessione, paniere attivo, valuta o prezzo in base al profilo, se queste funzioni esistono. Per HTML condiviso, favorire una soluzione alternativa quando la sessione personalizza la risposta. Una variazione più fine richiede chiavi documentate e una ricetta che dimostri l'isolamento.

Cookie woocommerce_cart_hash, woocommerce_items_in_cart e wp_woocommerce_session_ sono tra i segnali descritti da WooCommerce.[10] Configurarne l'elaborazione dopo l'integrazione; non rimuoverli per aumentare artificialmente le risposte fornite dalla cache.

L'esclusione di _wc_session_ viene menzionato anche per i sistemi che offrono una cache del database, a seconda dell'estensione o dell'hosting.[10] Questo avviso condizionale non giustifica la disabilitazione della cache degli oggetti.

Controlla anche il minicestino integrato nelle pagine pubbliche. Se questo blocco viene rinnovato separatamente, controlla la risposta che lo alimenta in entrambi i profili: una pagina esclusa correttamente non protegge un frammento personalizzato archiviato altrove.

Tabella diagnostica per livello e scenario utente

Ecco una griglia di lavoro, non un elenco degli incidenti osservati. I sintomi sono scenari diagnostici; le prove indicano cosa dovrebbe stabilire la tua ricetta.

Scenario utenteLivello da esaminareControllo prioritàDecisione e prova previste
Visitatore anonimo, vecchio prezzoPagina e CDNConfronta il record registrato, il HTML ricevuto e la risposta dopo l'eliminazione mirataInvalidare le copie interessate; mantenere il prezzo e le risposte previsti.
Vecchio prezzo in un browserNavigatoreConfronta lo stesso percorso in un nuovo profiloEsamina la freschezza HTTP; preservare le intestazioni e il confronto.
Cesto di un altro visitatorePagina e CDNTestare le sessioni A e B separatamenteEscludere il viaggio personalizzato; dimostrare che ogni sessione conserva i suoi articoli.
Sessione incoerente nonostante il recente HTMLOggetto o databaseEsaminare le chiavi e le esclusioni documentateModifica la regola identificata; allega la sua configurazione e il test.
Modulo rifiutato dopo essere tornato alla paginaPagina e browserControlla il token possibile e invia la rispostaAdatta l'aggiornamento o ignora la cache; conservare una spedizione di prova accettata.
Aggiungi al carrello tramite URLServer e CDNControlla la regola attiva ?add-to-cart=Fornire una soluzione alternativa adeguata, come nell'esempio di Varnish documentato da WooCommerce.[10]

Controlla l'ordine e conserva la prova della convalida

Prima di qualsiasi modifica, preparare una scheda ricetta: URL, scenario, stato della connessione, contenuto previsto, livelli attivi e modifica pianificata. Utilizza account di prova e dettagli di contatto fittizi. Annotare i nomi dei cookie utili, mai i loro valori o token in un documento condiviso.

  1. Stabilire il riferimento. Controllare i dati salvati e il comportamento senza riutilizzarli da parte delle cache interessate. In una pre-produzione protetta, testa prima il percorso dinamico, quindi attiva i livelli separatamente. Uno staging con regole cache diverse non convalida la produzione.
  2. Segui la risposta. Esaminare il browser, quindi il CDN, la cache della pagina e infine gli oggetti, se necessario. Prendi nota delle intestazioni e dei flag del provider disponibili. L'assenza di un indicatore non dimostra l'assenza di una cache.
  3. Decidi ed elimina. Correggi il livello identificato, elimina gli URL interessati e controlla le varianti. Organizzare anche l'invalidazione dopo una modifica del prezzo, del contenuto o della configurazione; non fare affidamento esclusivamente sullo spurgo manuale.
  4. Dimostrare l'isolamento. Apri due profili browser separati, A e B. Aggiungi articoli diversi, accedi all'account e invia i moduli consentiti. Due schede dello stesso profilo non costituiscono due sessioni isolate. Quindi ripetere questi passaggi dopo aver riutilizzato la cache e quindi dopo essersi disconnessi. Un test riuscito immediatamente dopo l'eliminazione non verifica tutte le risposte conservate.

Archivia la configurazione conservata, le acquisizioni oscurate, le risposte pertinenti e la decisione di accettazione. Non convalidare se i dati passano da una sessione all'altra, anche quando il caricamento appare migliore.

Caso fittizio: vecchio prezzo, panieri ancora distinti

In questo caso esplicitamente fittizio, un negozio mostra un vecchio prezzo su una scheda prodotto, mentre il carrello deve rimanere specifico per ciascun visitatore. Inizia controllando il prezzo registrato e la risposta del pubblico: una copia obsoleta HTML non è un errore di sessione.

Se il record pubblico è una copia obsoleta, indirizzarne l'invalidazione nella cache della pagina e nella CDN. Se il prezzo varia in base all'account, considera questa variazione come personalizzata, senza pubblicare la risposta in una cache comune.

La validazione prevista combina due osservazioni: il modulo presenta il prezzo di riferimento e i panieri A e B rimangono distinti dopo la navigazione e il ritorno al modulo. Un prezzo corretto non è sufficiente per accettare la configurazione.

Moduli: visualizzazione separata, invio e anagrafica

Per ogni modulo identificare la pagina di visualizzazione, la destinazione di invio, eventuali token e dati precompilati. La nostra regola della ricetta è testare la visualizzazione, l'invio, il messaggio di conferma e un nuovo tentativo dopo la navigazione. La risposta pubblica HTML e la risposta personalizzata non dovrebbero ricevere automaticamente la stessa policy.

Se l'estensione genera un token in base alla sessione o al suo periodo di validità, verificarne il meccanismo di rinnovo. In assenza di compatibilità documentata, ignora la cache della pagina su questo percorso; non rimuovere la protezione per rendere utilizzabile il modulo. Escludere le risposte di invio che contengono dati personali o stato della sessione dalla cache condivisa.

Queste impostazioni non dimostrano la conformità al GDPR: non verificano la base giuridica del modulo né la sua politica di conservazione. Una volta validata la ricetta funzionale, il ns Guida ai Segnali Web principali aiuta a distinguere caricamento, interattività e stabilità prima di altre correzioni.

Domande frequenti

Perché la reimpostazione della password riporta al login?

WooCommerce segnala che una pagina di account memorizzata nella cache può causare questo loop, soprattutto se la cache del server non lo esclude.[10] Chiedere la verifica all'host, quindi testare nuovamente il collegamento con un account fittizio, senza una sessione già connessa. Includere i passaggi di reimpostazione nell'esclusione del percorso dell'account, non solo nella schermata principale.

Possiamo mantenere i file CSS memorizzati nella cache dell'account cliente?

Sì, i file statici immutabili sono particolarmente adatti per la memorizzazione nella cache.[11] HTML dell'account e le relative risorse pubbliche non hanno la stessa policy. Verificare che il file rimanga lo stesso per tutti e non contenga dati di sessione. Quando un file cambia, controllane il controllo delle versioni o l'invalidazione, senza disabilitare indiscriminatamente la cache di tutti gli elementi.

È necessario eliminare tutto dopo una modifica del prodotto?

Non sistematicamente. Elenca le pagine che includono i dati modificati: file, categoria, ricerca o blocco di consigli, a seconda del tuo sito. Un'eliminazione mirata è rilevante se queste dipendenze sono note e coperte dall'integrazione. Se non lo sono, scegli un'eliminazione documentata più ampia, quindi rifai la ricetta; non dare per scontato che cambi solo la spina.

La tua prossima azione: formalizzare una ricetta

Scegli una scheda prodotto, il carrello e un modulo di prova. Completare la griglia, identificare la persona responsabile di ogni strato e richiedere la prova dell'isolamento prima di effettuare la manutenzione di un ambiente. Se le regole per l'hosting, CDN e WordPress si sovrappongono, il file servizi web di 4SYSTEM può aiutarti a inquadrare la diagnosi e la convalida.

Fonti

IT