La cache funziona perché la stessa pagina va bene per tutti: la home, una scheda prodotto, un articolo del blog. Ma un sito non è fatto solo di pagine uguali per tutti. Il carrello di Mario non è quello di Lucia, l’area riservata mostra i dati di chi ha fatto il login, il checkout contiene indirizzi e ordini. In questo articolo vediamo come la cache iWebLab tratta i contenuti personalizzati, quali pagine non vanno mai in cache e quali situazioni conviene segnalarci.
La regola di fondo: ciò che è personale non si condivide
Una pagina in cache è una copia condivisa: chiunque la chieda riceve la stessa. Va benissimo per un catalogo, sarebbe un disastro per un carrello. Per questo la cache iWebLab distingue due tipi di pagine:
- Pagine pubbliche, uguali per tutti i visitatori: vengono servite dalla rete iWebLab Edge.
- Pagine personali, diverse per ogni visitatore: passano attraverso la rete e arrivano al server, che le costruisce su misura, ogni volta.
Le pagine che non vanno in cache
Il plugin per WordPress e il modulo per PrestaShop conoscono le pagine personali dei rispettivi CMS e le tengono fuori dalla cache. Le tipiche sono:
| Pagina | Perché resta fuori |
|---|---|
| Carrello | Contiene i prodotti scelti da quel visitatore. |
| Checkout e pagamento | Contiene indirizzi, spedizione, dati dell’ordine. |
| Area riservata / Il mio account | Mostra ordini, indirizzi e dati personali. |
| Login e registrazione | Gestiscono credenziali e sessioni. |
| Pannello di amministrazione | È il tuo strumento di lavoro, deve essere sempre aggiornato. |
Anche chi ha fatto il login, come un cliente registrato o un amministratore che naviga il sito, vede le pagine costruite per lui e non la copia condivisa.
Le pagine «quasi uguali per tutti»
Ci sono pagine pubbliche che contengono un piccolo elemento personale: il numero di prodotti nel carrello nell’intestazione, il nome del cliente in alto a destra, la lista dei desideri. Sarebbe un peccato rinunciare alla cache per tutta la pagina solo per un’icona.
Il plugin e il modulo iWebLab gestiscono questi elementi separatamente: la pagina arriva dalla cache, e le parti personali vengono completate per ogni visitatore. Così il catalogo resta veloce e il contatore del carrello resta giusto.
Quando un contenuto personalizzato può creare problemi
I CMS sono pieni di plugin e moduli, e alcuni personalizzano le pagine in modi che la cache non può indovinare. Non capita spesso, ma è utile conoscere i casi tipici, perché se il tuo sito ne ha uno conviene dircelo.
Prezzi diversi per tipo di cliente
Se il tuo negozio mostra prezzi diversi ai rivenditori registrati rispetto ai privati, la differenza riguarda chi ha fatto il login, e chi ha fatto il login vede le pagine costruite per lui. Se però i prezzi cambiano in base ad altro, per esempio a un codice inserito senza login, la situazione va verificata.
Lingua, paese o valuta decisi dal browser
Alcuni negozi scelgono la lingua, la valuta o le tasse da applicare guardando le impostazioni del browser o il paese del visitatore. Se la pagina cambia in base a queste informazioni ma l’indirizzo resta lo stesso, la cache rischia di servire a tutti la versione vista dal primo visitatore. Per esempio, un prezzo senza IVA pensato per un cliente estero potrebbe comparire anche a un cliente italiano. Se il tuo sito funziona così, segnalacelo: in genere la soluzione è usare indirizzi diversi per ogni lingua o paese.
Plugin che scrivono nella pagina dati del visitatore
Alcuni strumenti di marketing o di tracciamento scrivono direttamente nell’HTML informazioni sul visitatore. In una pagina condivisa, quelle informazioni finirebbero a tutti. Se usi plugin di questo tipo, chiedici una verifica: spesso basta cambiare un’impostazione del plugin.
Plugin che aprono una sessione su ogni pagina
Ci sono plugin, per esempio alcuni sistemi di preventivi o di listini personalizzati, che avviano una sessione per ogni visitatore fin dalla prima pagina. In quel caso ogni pagina diventa «personale» e non viene più servita dalla cache. Il sito funziona correttamente, ma perde i vantaggi della cache. Se noti che il tuo sito non sembra più veloce dopo l’attivazione, potrebbe essere questo: apri un ticket e controlliamo.
Esempi pratici
Il negozio con il contatore del carrello
Lucia aggiunge due prodotti al carrello e continua a navigare nel catalogo. Le schede prodotto le arrivano dalla cache, velocissime, e in alto vede comunque «2 prodotti nel carrello». Quando apre il carrello e va al checkout, le pagine vengono costruite dal server solo per lei.
Il sito con l’area soci
Un’associazione ha un sito pubblico e un’area riservata ai soci, con documenti e quote. Le pagine pubbliche vanno in cache. Quando un socio fa il login, vede le pagine dell’area riservata costruite per lui, con i suoi dati.
Il negozio internazionale
Un negozio vende in Italia e all’estero con indirizzi separati per ogni lingua. Ogni versione va in cache per conto suo, e ogni visitatore riceve quella giusta. Se invece la lingua venisse decisa dal browser sullo stesso indirizzo, sarebbe il caso da segnalarci prima di attivare la cache.
Cosa fare in pratica
- Prima di attivare la cache, se il tuo sito ha prezzi, lingue o contenuti che cambiano in base al visitatore senza login, scrivilo nel ticket: lo verifichiamo insieme.
- Dopo l’attivazione, prova il sito come farebbe un cliente: aggiungi al carrello, fai il login, cambia lingua. Se qualcosa non torna, apri un ticket indicando la pagina e cosa hai visto.
- Quando installi un plugin nuovo che personalizza le pagine (prezzi, geolocalizzazione, tracciamento), fai un controllo veloce delle stesse pagine.
In sintesi
La cache iWebLab serve dalla rete le pagine uguali per tutti e lascia al server quelle personali: carrello, checkout, area riservata, login e amministrazione. I casi particolari esistono, ma sono pochi e si risolvono: basta conoscerli e segnalarceli. Trovi altre informazioni nella pagina di iWebLab Cache, e per qualsiasi dubbio puoi contattarci.