Snelle pagina's, verkeerde toestemming

Paginacaching is een van de beste dingen die je kunt doen voor snelheid en hostingkosten. Het is ook een van de makkelijkste manieren om ongemerkt een toestemmingsopzet te breken. Een cache doet precies wat hem wordt opgedragen: hij slaat een respons één keer op en serveert die aan iedereen die bij dezelfde sleutel past. Als die opgeslagen respons iets bevat dat specifiek is voor de toestemmingskeuze of locatie van één bezoeker, krijgt de volgende bezoeker dat ook.

Deze gids behandelt de cachinglagen die doorgaans voor een uitgeverssite zitten — CDN-edgecaches, full-page-cachingplugins, reverse proxy's, service workers en de browser zelf — en hoe je voorkomt dat elk daarvan de verkeerde toestemmingservaring serveert.

De kernregel: houd toestemming uit gecachete HTML

De veiligste architectuur rendert de gecachete HTML-pagina toestemmingsneutraal. De pagina bevat de CMP-loader en je tags in een geblokkeerde of wachtende staat, maar geen beslissing over deze specifieke bezoeker. De CMP draait vervolgens in de browser, leest de opgeslagen keuze, bepaalt of de banner moet worden getoond en geeft tags dienovereenkomstig vrij.

Problemen beginnen wanneer de server tijdens het renderen toestemmingsbeslissingen neemt, bijvoorbeeld:

• een thema of plugin dat advertentie- of analytics-tags alleen afdrukt wanneer er een toestemmingscookie aanwezig is;
• servercode die de bannermarkup weglaat voor bezoekers die al hebben gekozen;
• sjablonen die de toestemmingsstatus van een bezoeker in een inline scriptvariabele inbedden.

Zodra die pagina is gecachet, wordt de status van de eerste bezoeker die van iedereen. Een bezoeker die tracking heeft geweigerd, krijgt mogelijk een pagina met al actieve tags, of een nieuwe bezoeker ziet nooit een banner omdat de gecachete kopie afkomstig is van iemand die hem al had weggeklikt.

Waarom “Vary: Cookie” zelden het antwoord is

De leerboekoplossing voor content per bezoeker is caches te vertellen te variëren op de cookie-header. In de praktijk dragen bezoekers veel cookies met unieke waarden, dus variëren op de volledige cookie-header drukt je cache-hitpercentage meestal naar bijna nul. Sommige CDN's laten je de cachesleutel in plaats daarvan opbouwen uit de waarde van één cookie, wat werkbaar is als je toestemmingscookie een klein aantal mogelijke statussen heeft, maar het voegt complexiteit toe en vermenigvuldigt nog steeds het aantal gecachete kopieën. De beslissing naar de browser verplaatsen is eenvoudiger en houdt de cache efficiënt.

Geografie aan de edge

Veel uitgevers tonen per regio verschillende banners: een opt-inbanner voor de EU en het VK, een opt-outmelding voor Amerikaanse staten en iets lichters elders. Als de server de variant kiest op basis van het IP-adres van de bezoeker en die pagina wordt gecachet, kan een Europese lezer een gecachete Amerikaanse pagina krijgen, of andersom.

Drie patronen voorkomen dat:

1. Geolocatie aan de clientzijde. Laat de CMP de regio in de browser bepalen, zodat de gecachete HTML voor iedereen gelijk blijft.
2. Land in de cachesleutel. Als je aan de edge moet beslissen, neem dan de landcode die je CDN levert op in de cachesleutel. Je krijgt één gecachete kopie per land, wat voorspelbaar is.
3. Ongecachete edgelogica. Voer de regionale beslissing uit in een edgefunctie die een kleine, ongecachete waarde in een verder gecachete pagina injecteert.

Welke je ook kiest, documenteer het. Geobugs behoren tot de moeilijkst te reproduceren, omdat ze alleen optreden bij bezoekers op één plek die toevallig een pagina krijgen die door iemand op een andere plek is gecachet.

Het CMP-script zelf cachen

De CMP-loader lang cachen is goed voor de prestaties, maar heeft een prijs wanneer de configuratie verandert. Als je leveranciers, doeleinden of bannertekst bijwerkt en het script of het configuratiebestand een jaar lang is gecachet, blijven sommige bezoekers de oude versie zien. Kijk hoe je CMP zijn bestanden versioneert: een veranderende bestandsnaam of versieparameter laat je agressief cachen en toch wijzigingen direct uitrollen. Bevestig ook dat je eigen CDN geen querystrings uit URL's van scripts van derden verwijdert als de CMP daarop steunt.

Service workers en offlinecaches

Sites met een progressive-webapplaag cachen HTML vaak in een service worker. Dezelfde regel geldt: sla nooit een pagina op die een specifieke toestemmingsbeslissing weerspiegelt. Sluit toestemmingsgerelateerde eindpunten en pagina's van het voorkeurencentrum uit van service-workercaching en zorg dat er altijd een verse CMP-configuratie kan worden opgehaald.

De back/forward-cache

Moderne browsers houden onlangs bezochte pagina's in het geheugen, zodat de terugknop ze direct herstelt. Als een bezoeker op de ene pagina het voorkeurencentrum opent, toestemming intrekt en dan op terug drukt, kan de herstelde pagina nog tags van daarvoor hebben draaien. Luister naar de gebeurtenis pageshow en controleer de eigenschap persisted: wanneer een pagina uit deze cache wordt hersteld, lees dan de opgeslagen toestemmingsstatus opnieuw en stop of start tags zodat ze kloppen.

Een testroutine

• Laad een pagina in een schone sessie, weiger, laad dan een tweede pagina en bevestig dat er geen trackingtags afgaan.
• Herhaal dit met een tweede schone browser en bevestig dat de banner verschijnt, wat bewijst dat hij niet is weggecachet.
• Controleer de responsheaders om te zien of pagina's uit de cache worden geserveerd en vergelijk de HTML met en zonder toestemmingscookie — die moet identiek zijn.
• Test vanuit minstens twee regio's nadat je de cache hebt geleegd en nogmaals nadat de cache is opgewarmd.
• Trek toestemming in, gebruik de terugknop en verifieer dat tags stoppen.

Belangrijkste inzichten

• Gecachete HTML moet toestemmingsneutraal zijn; laat de CMP in de browser beslissen.
• Varieer niet op de volledige cookie-header; dat vernietigt de hitpercentages.
• Als banners per regio verschillen, beslis dan aan de clientzijde of voeg het land toe aan de cachesleutel.
• Versioneer CMP-bestanden zodat lange cachelevensduren configuratiewijzigingen niet vertragen.
• Houd rekening met service workers en de back/forward-cache en test met een warme cache, niet alleen na een leegmaakactie.