Hurtige sider, forkert samtykke

Sidecaching er noget af det bedste, du kan gøre for hastighed og hostingomkostninger. Det er også en af de nemmeste måder at ødelægge en samtykkeopsætning uden at lægge mærke til det. En cache gør præcis, hvad den får besked på: den gemmer et svar én gang og serverer det til alle, der matcher den samme nøgle. Hvis det gemte svar indeholder noget, der er specifikt for én besøgendes samtykkevalg eller placering, får den næste besøgende det også.

Denne guide gennemgår de cachinglag, der typisk sidder foran et udgiversite — CDN-edgecaches, full-page-cachingplugins, reverse proxies, service workers og selve browseren — og hvordan du forhindrer hvert af dem i at servere den forkerte samtykkeoplevelse.

Kerneregel: hold samtykke ude af cachet HTML

Den sikreste arkitektur renderer den cachede HTML-side samtykkeneutralt. Siden indeholder CMP-loaderen og dine tags i en blokeret eller ventende tilstand, men ingen beslutning om netop denne besøgende. CMP'en kører derefter i browseren, læser det gemte valg, afgør om banneret skal vises og frigiver tags i overensstemmelse hermed.

Problemerne begynder, når serveren træffer samtykkebeslutninger ved rendering, for eksempel:

• et tema eller plugin, der kun udskriver annonce- eller analytics-tags, når der findes en samtykkecookie;
• serverkode, der udelader bannermarkup for besøgende, der allerede har valgt;
• skabeloner, der indlejrer en besøgendes samtykketilstand i en inline scriptvariabel.

Når den side er cachet, bliver den første besøgendes tilstand til alles tilstand. En besøgende, der afviste tracking, kan få en side med allerede aktive tags, eller en ny besøgende ser aldrig et banner, fordi den cachede kopi stammer fra en, der allerede havde afvist det.

Hvorfor “Vary: Cookie” sjældent er svaret

Lærebogsløsningen på indhold pr. besøgende er at bede cacher variere på cookie-headeren. I praksis har besøgende mange cookies med unikke værdier, så at variere på hele cookie-headeren trækker normalt din cache-hitrate ned mod nul. Nogle CDN'er lader dig i stedet bygge cache-nøglen ud fra værdien af én enkelt cookie, hvilket kan fungere, hvis din samtykkecookie har et lille antal mulige tilstande, men det tilføjer kompleksitet og multiplicerer stadig antallet af cachede kopier. At flytte beslutningen ind i browseren er enklere og holder cachen effektiv.

Geografi ved edge

Mange udgivere viser forskellige bannere efter region: et opt-in-banner til EU og UK, en opt-out-meddelelse til amerikanske stater og noget lettere andre steder. Hvis serveren vælger varianten ud fra den besøgendes IP-adresse, og den side bliver cachet, kan en europæisk læser få en cachet amerikansk side eller omvendt.

Tre mønstre undgår dette:

1. Geolokation på klientsiden. Lad CMP'en bestemme regionen i browseren, så den cachede HTML er den samme for alle.
2. Land i cache-nøglen. Hvis du skal beslutte ved edge, så medtag landekoden, som din CDN leverer, i cache-nøglen. Du får én cachet kopi pr. land, hvilket er forudsigeligt.
3. Ucachet edge-logik. Kør den regionale beslutning i en edge-funktion, der injicerer en lille, ucachet værdi i en ellers cachet side.

Uanset hvad du vælger, så dokumentér det. Geofejl hører til de sværeste at reproducere, fordi de kun optræder for besøgende ét sted, som tilfældigvis får en side, der er cachet af en anden et andet sted.

Cachelagring af selve CMP-scriptet

At cache CMP-loaderen længe er godt for ydeevnen, men har en pris, når konfigurationen ændres. Hvis du opdaterer leverandører, formål eller bannertekst, og scriptet eller konfigurationsfilen er cachet i et år, vil nogle besøgende blive ved med at se den gamle version. Tjek, hvordan din CMP versionerer sine filer: et skiftende filnavn eller en versionsparameter lader dig cache aggressivt og alligevel udrulle ændringer med det samme. Bekræft også, at din egen CDN ikke fjerner query strings fra tredjepartsscripts' URL'er, hvis CMP'en er afhængig af dem.

Service workers og offline-caches

Sites med et progressive web app-lag cacher ofte HTML i en service worker. Den samme regel gælder: gem aldrig en side, der afspejler en bestemt samtykkebeslutning. Udeluk samtykkerelaterede endepunkter og sider i præferencecenteret fra service worker-caching, og sørg for, at en frisk CMP-konfiguration altid kan hentes.

Back/forward-cachen

Moderne browsere holder nyligt besøgte sider i hukommelsen, så tilbageknappen gendanner dem øjeblikkeligt. Hvis en besøgende åbner præferencecenteret på én side, trækker samtykket tilbage og derefter trykker tilbage, kan den gendannede side stadig have tags kørende fra før. Lyt efter hændelsen pageshow og tjek dens egenskab persisted: når en side gendannes fra denne cache, så genlæs den gemte samtykketilstand og stop eller start tags, så de passer.

En testrutine

• Indlæs en side i en ren session, afvis, indlæs så en anden side og bekræft, at ingen trackingtags affyres.
• Gentag med en anden ren browser og bekræft, at banneret vises, hvilket beviser, at det ikke blev cachet væk.
• Tjek svarheadere for at se, om sider serveres fra cache, og sammenlign HTML'en med og uden samtykkecookie — den bør være identisk.
• Test fra mindst to regioner efter rydning af cachen og igen, efter cachen er varmet op.
• Træk samtykket tilbage, brug tilbageknappen og verificér, at tags stopper.

Vigtigste pointer

• Cachet HTML bør være samtykkeneutral; lad CMP'en beslutte i browseren.
• Undgå at variere på hele cookie-headeren; det ødelægger hitraten.
• Hvis bannere er forskellige efter region, så beslut på klientsiden eller føj landet til cache-nøglen.
• Versionér CMP-filer, så lange cachelevetider ikke forsinker konfigurationsændringer.
• Håndtér service workers og back/forward-cachen, og test med varm cache, ikke kun efter en rydning.