Pagine veloci, consenso sbagliato

La cache delle pagine è una delle cose migliori che puoi fare per la velocità e i costi di hosting. È anche uno dei modi più semplici per rompere una configurazione del consenso senza accorgertene. Una cache fa esattamente ciò che le viene detto: memorizza una risposta una volta e la serve a tutti coloro che corrispondono alla stessa chiave. Se quella risposta memorizzata contiene qualcosa di specifico della scelta di consenso o della posizione di un visitatore, la riceve anche il visitatore successivo.

Questa guida tratta i livelli di cache che di solito si trovano davanti a un sito di un editore — cache edge delle CDN, plugin di cache a pagina completa, reverse proxy, service worker e il browser stesso — e come evitare che ciascuno serva l'esperienza di consenso sbagliata.

La regola di fondo: tenere il consenso fuori dall'HTML in cache

L'architettura più sicura produce una pagina HTML in cache neutra rispetto al consenso. La pagina contiene il loader del CMP e i tuoi tag in stato bloccato o in attesa, ma nessuna decisione su questo specifico visitatore. Il CMP poi gira nel browser, legge la scelta memorizzata, decide se mostrare il banner e rilascia i tag di conseguenza.

I problemi iniziano quando il server prende decisioni di consenso al momento del rendering, per esempio:

• un tema o un plugin che stampa i tag pubblicitari o di analitiche solo quando è presente un cookie di consenso;
• codice lato server che omette il markup del banner per i visitatori che hanno già scelto;
• template che incorporano lo stato di consenso di un visitatore in una variabile di uno script inline.

Una volta messa in cache quella pagina, lo stato del primo visitatore diventa lo stato di tutti. Un visitatore che ha rifiutato il tracciamento può ricevere una pagina con i tag già attivi, oppure un nuovo visitatore può non vedere mai un banner perché la copia in cache proviene da qualcuno che l'aveva già chiuso.

Perché «Vary: Cookie» raramente è la risposta

La soluzione da manuale per i contenuti per singolo visitatore è dire alle cache di variare in base all'header dei cookie. In pratica i visitatori portano molti cookie con valori univoci, quindi variare sull'intero header dei cookie di solito porta il tuo tasso di hit della cache quasi a zero. Alcune CDN permettono di costruire la chiave di cache a partire dal valore di un solo cookie, il che è praticabile se il tuo cookie di consenso ha un numero ridotto di stati possibili, ma aggiunge complessità e moltiplica comunque il numero di copie in cache. Spostare la decisione nel browser è più semplice e mantiene la cache efficiente.

La geografia all'edge

Molti editori mostrano banner diversi per regione: un banner opt-in per UE e Regno Unito, un avviso di esclusione per gli stati USA e qualcosa di più leggero altrove. Se il server sceglie la variante in base all'indirizzo IP del visitatore e quella pagina viene messa in cache, un lettore europeo può ricevere una pagina USA in cache, o viceversa.

Tre schemi evitano questo problema:

1. Geolocalizzazione lato client. Lascia che sia il CMP a determinare la regione nel browser, così l'HTML in cache resta lo stesso per tutti.
2. Il paese nella chiave di cache. Se devi decidere all'edge, includi nella chiave di cache il codice paese fornito dalla tua CDN. Ottieni una copia in cache per paese, il che è prevedibile.
3. Logica edge senza cache. Esegui la decisione regionale in una funzione edge che inietta un piccolo valore non in cache in una pagina altrimenti in cache.

Qualunque scelta tu faccia, documentala. I bug geografici sono fra i più difficili da riprodurre, perché compaiono solo per i visitatori di un luogo che per caso ricevono una pagina messa in cache da qualcuno di un altro.

Mettere in cache lo script del CMP stesso

Mettere in cache a lungo il loader del CMP fa bene alle prestazioni, ma ha un costo quando la configurazione cambia. Se aggiorni vendor, finalità o testo del banner e lo script o il file di configurazione è in cache per un anno, alcuni visitatori continueranno a vedere la vecchia versione. Controlla come il tuo CMP versiona i file: un nome di file o un parametro di versione che cambia ti permette di usare la cache in modo aggressivo e comunque di rilasciare subito le modifiche. Verifica inoltre che la tua CDN non elimini le query string dagli URL di script di terze parti se il CMP vi si affida.

Service worker e cache offline

I siti con un livello di progressive web app spesso mettono in cache l'HTML in un service worker. Vale la stessa regola: non memorizzare mai una pagina che rifletta una specifica decisione di consenso. Escludi dalla cache del service worker gli endpoint legati al consenso e le pagine del centro preferenze, e assicurati che sia sempre possibile recuperare una configurazione aggiornata del CMP.

La cache avanti/indietro

I browser moderni tengono in memoria le pagine visitate di recente, in modo che il pulsante Indietro le ripristini all'istante. Se un visitatore apre il centro preferenze in una pagina, revoca il consenso e poi preme Indietro, la pagina ripristinata può avere ancora in esecuzione i tag di prima. Ascolta l'evento pageshow e controlla la sua proprietà persisted: quando una pagina viene ripristinata da questa cache, rileggi lo stato di consenso memorizzato e ferma o avvia i tag di conseguenza.

Una routine di test

• Carica una pagina in una sessione pulita, rifiuta, poi carica una seconda pagina e conferma che nessun tag di tracciamento venga attivato.
• Ripeti con un secondo browser pulito e conferma che il banner compaia, a riprova che non è stato eliminato dalla cache.
• Controlla gli header di risposta per vedere se le pagine sono servite dalla cache, e confronta l'HTML con e senza cookie di consenso — dovrebbe essere identico.
• Testa da almeno due regioni dopo aver svuotato la cache, e di nuovo dopo che la cache si è scaldata.
• Revoca il consenso, usa il pulsante Indietro e verifica che i tag si fermino.

Punti chiave

• L'HTML in cache deve essere neutro rispetto al consenso; lascia che sia il CMP a decidere nel browser.
• Evita di variare sull'intero header dei cookie; distrugge i tassi di hit.
• Se i banner differiscono per regione, decidi lato client o aggiungi il paese alla chiave di cache.
• Versiona i file del CMP in modo che le lunghe durate di cache non ritardino le modifiche alla configurazione.
• Gestisci i service worker e la cache avanti/indietro, e testa con la cache calda, non solo dopo uno svuotamento.