Pagini rapide, consimțământ greșit

Cache-ul de pagini este unul dintre cele mai bune lucruri pe care le poți face pentru viteză și costuri de găzduire. Este totodată una dintre cele mai ușoare căi de a strica o configurație de consimțământ fără să observi. Un cache face exact ce i se spune: stochează un răspuns o dată și îl servește tuturor celor care se potrivesc cu aceeași cheie. Dacă acel răspuns stocat conține ceva specific alegerii de consimțământ sau locației unui vizitator, următorul vizitator îl primește și el.

Acest ghid acoperă straturile de cache care se află de obicei în fața unui site de editor — cache-urile edge ale CDN-ului, pluginurile de cache de pagină completă, reverse proxy-urile, service worker-ele și browserul însuși — și cum să împiedici fiecare strat să servească experiența de consimțământ greșită.

Regula de bază: ține consimțământul în afara HTML-ului din cache

Cea mai sigură arhitectură redă pagina HTML din cache ca neutră față de consimțământ. Pagina conține încărcătorul CMP și tagurile tale în stare blocată sau de așteptare, dar nicio decizie despre acest vizitator anume. Apoi CMP rulează în browser, citește alegerea stocată, decide dacă afișează bannerul și eliberează tagurile în consecință.

Problemele încep când serverul ia decizii de consimțământ în momentul redării, de exemplu:

• o temă sau un plugin care tipărește taguri de anunțuri sau de analitică doar când există un cookie de consimțământ;
• cod de server care omite markup-ul bannerului pentru vizitatorii care au ales deja;
• șabloane care încorporează starea de consimțământ a unui vizitator într-o variabilă de script inline.

Odată ce pagina respectivă ajunge în cache, starea primului vizitator devine starea tuturor. Un vizitator care a respins urmărirea poate primi o pagină cu taguri deja active sau un vizitator nou poate să nu vadă niciodată un banner, pentru că exemplarul din cache provine de la cineva care îl închisese deja.

De ce “Vary: Cookie” este rareori răspunsul

Soluția din manual pentru conținutul per vizitator este să le spui cache-urilor să varieze după antetul de cookie-uri. În practică, vizitatorii poartă multe cookie-uri cu valori unice, deci variația după întregul antet de cookie-uri aduce de obicei rata de succes a cache-ului aproape de zero. Unele CDN-uri te lasă să construiești cheia de cache dintr-o singură valoare de cookie, ceea ce e fezabil dacă cookie-ul tău de consimțământ are puține stări posibile, dar adaugă complexitate și tot înmulțește numărul de exemplare din cache. Mutarea deciziei în browser este mai simplă și menține cache-ul eficient.

Geografia la nivelul edge

Mulți editori afișează bannere diferite în funcție de regiune: un banner opt-in pentru UE și Regatul Unit, o notificare opt-out pentru statele SUA și ceva mai ușor în rest. Dacă serverul alege varianta pe baza adresei IP a vizitatorului, iar pagina respectivă este pusă în cache, un cititor european poate primi o pagină americană din cache sau invers.

Trei tipare evită acest lucru:

1. Geolocalizare pe client. Lasă CMP-ul să determine regiunea în browser, astfel încât HTML-ul din cache să fie același pentru toți.
2. Țara în cheia de cache. Dacă trebuie să decizi la edge, include în cheia de cache codul de țară oferit de CDN. Obții un exemplar în cache per țară, ceea ce e previzibil.
3. Logică edge fără cache. Rulează decizia regională într-o funcție edge care injectează o valoare mică, necache-uită, într-o pagină altfel pusă în cache.

Indiferent ce alegi, documentează. Erorile de geografie sunt printre cele mai greu de reprodus, pentru că apar doar pentru vizitatorii dintr-un loc care primesc, din întâmplare, o pagină pusă în cache de cineva din altul.

Cache-uirea scriptului CMP în sine

Păstrarea îndelungată în cache a încărcătorului CMP este bună pentru performanță, dar are un cost când se schimbă configurația. Dacă actualizezi furnizori, scopuri sau textul bannerului, iar scriptul sau fișierul de configurare este ținut în cache un an, unii vizitatori vor continua să vadă versiunea veche. Verifică cum își versionează CMP-ul fișierele: un nume de fișier sau un parametru de versiune care se schimbă îți permite să folosești cache agresiv și să lansezi totuși modificările imediat. Confirmă și că propriul CDN nu elimină șirurile de interogare din URL-urile scripturilor terțe dacă CMP-ul se bazează pe ele.

Service worker-e și cache-uri offline

Site-urile cu un strat de aplicație web progresivă pun adesea HTML în cache într-un service worker. Se aplică aceeași regulă: nu stoca niciodată o pagină care reflectă o decizie de consimțământ anume. Exclude din cache-ul service worker-ului endpoint-urile legate de consimțământ și paginile centrului de preferințe și asigură-te că o configurație proaspătă a CMP poate fi mereu preluată.

Cache-ul înainte/înapoi

Browserele moderne țin în memorie paginile vizitate recent, astfel încât butonul Înapoi să le restaureze instantaneu. Dacă un vizitator deschide centrul de preferințe pe o pagină, retrage consimțământul și apoi apasă Înapoi, pagina restaurată poate avea încă tagurile active de dinainte. Ascultă evenimentul pageshow și verifică proprietatea sa persisted: când o pagină este restaurată din acest cache, recitește starea de consimțământ stocată și oprește sau pornește tagurile pentru a se potrivi.

O rutină de testare

• Încarcă o pagină într-o sesiune curată, respinge, apoi încarcă o a doua pagină și confirmă că nu se declanșează niciun tag de urmărire.
• Repetă cu un al doilea browser curat și confirmă că apare bannerul, ceea ce dovedește că nu a fost eliminat de cache.
• Verifică antetele de răspuns ca să vezi dacă paginile sunt servite din cache și compară HTML-ul cu și fără cookie de consimțământ — ar trebui să fie identic.
• Testează din cel puțin două regiuni după golirea cache-ului, apoi din nou după ce acesta s-a încălzit.
• Retrage consimțământul, folosește butonul Înapoi și verifică dacă tagurile se opresc.

Concluzii

• HTML-ul din cache trebuie să fie neutru față de consimțământ; lasă CMP-ul să decidă în browser.
• Evită variația după întregul antet de cookie-uri; distruge ratele de succes.
• Dacă bannerele diferă pe regiuni, decide pe client sau adaugă țara în cheia de cache.
• Versionează fișierele CMP pentru ca duratele lungi de cache să nu întârzie modificările de configurare.
• Tratează service worker-ele și cache-ul înainte/înapoi și testează cu cache-ul încălzit, nu doar după golire.