Snabba sidor, fel samtycke

Sidcachning är en av de bästa sakerna du kan göra för hastighet och hostingkostnader. Det är också ett av de enklaste sätten att förstöra en samtyckesuppsättning utan att märka det. En cache gör exakt det den blir tillsagd: den lagrar ett svar en gång och serverar det till alla som matchar samma nyckel. Om det lagrade svaret innehåller något som är specifikt för en besökares samtyckesval eller plats får nästa besökare det också.

Den här guiden går igenom de cachelager som typiskt sitter framför en utgivares webbplats — CDN-edgecacher, plugins för helsidescachning, reverse proxies, service workers och webbläsaren själv — och hur du hindrar var och en från att servera fel samtyckesupplevelse.

Grundregeln: håll samtycke utanför cachad HTML

Den säkraste arkitekturen renderar den cachade HTML-sidan som samtyckesneutral. Sidan innehåller CMP-laddaren och dina taggar i blockerat eller väntande läge, men inget beslut om just den här besökaren. CMP:n körs sedan i webbläsaren, läser det lagrade valet, avgör om bannern ska visas och släpper taggarna därefter.

Problemen börjar när servern fattar samtyckesbeslut vid renderingen, till exempel:

• ett tema eller plugin som bara skriver ut annons- eller analystaggar när en samtyckescookie finns;
• serverkod som utelämnar bannerns markup för besökare som redan har valt;
• mallar som bäddar in en besökares samtyckestillstånd i en variabel i ett inline-skript.

När den sidan väl är cachad blir den första besökarens tillstånd allas tillstånd. En besökare som avvisade spårning kan få en sida med taggar som redan är aktiva, eller så kanske en ny besökare aldrig ser en banner eftersom den cachade kopian kom från någon som redan hade stängt den.

Varför “Vary: Cookie” sällan är svaret

Lärobokens lösning för besökarspecifikt innehåll är att be cacher variera på cookie-headern. I praktiken bär besökare många cookies med unika värden, så att variera på hela cookie-headern gör oftast att cachens träffgrad faller till nästan noll. Vissa CDN:er låter dig i stället bygga cachenyckeln av ett enda cookievärde, vilket är genomförbart om din samtyckescookie har ett litet antal möjliga tillstånd, men det tillför komplexitet och multiplicerar ändå antalet cachade kopior. Att flytta beslutet till webbläsaren är enklare och håller cachen effektiv.

Geografi vid edgen

Många utgivare visar olika banners per region: en opt-in-banner för EU och Storbritannien, ett avanmälningsmeddelande för amerikanska delstater och något lättare på andra håll. Om servern väljer variant utifrån besökarens IP-adress och sidan cachas kan en europeisk läsare få en cachad amerikansk sida, eller tvärtom.

Tre mönster undviker detta:

1. Geolokalisering på klientsidan. Låt CMP:n avgöra regionen i webbläsaren, så att den cachade HTML:en förblir densamma för alla.
2. Land i cachenyckeln. Om du måste avgöra vid edgen, inkludera landskoden som din CDN tillhandahåller i cachenyckeln. Du får en cachad kopia per land, vilket är förutsägbart.
3. Ocachad edgelogik. Kör det regionala beslutet i en edgefunktion som injicerar ett litet, ocachat värde i en annars cachad sida.

Vilket du än väljer, dokumentera det. Geobuggar hör till de svåraste att återskapa, eftersom de bara visar sig för besökare på en plats som råkar få en sida som cachats av någon på en annan.

Att cacha själva CMP-skriptet

Att cacha CMP-laddaren länge är bra för prestanda, men det har ett pris när konfigurationen ändras. Om du uppdaterar leverantörer, ändamål eller bannertext och skriptet eller konfigurationsfilen är cachad i ett år fortsätter vissa besökare att se den gamla versionen. Kontrollera hur din CMP versionerar sina filer: ett föränderligt filnamn eller en versionsparameter låter dig cacha aggressivt och ändå rulla ut ändringar direkt. Bekräfta också att din egen CDN inte tar bort frågesträngar från tredjepartsskripts URL:er om CMP:n förlitar sig på dem.

Service workers och offlinecacher

Webbplatser med ett progressivt webbappslager cachar ofta HTML i en service worker. Samma regel gäller: lagra aldrig en sida som speglar ett specifikt samtyckesbeslut. Undanta samtyckesrelaterade slutpunkter och inställningscentersidor från service workerns cachning och se till att en färsk CMP-konfiguration alltid kan hämtas.

Bakåt/framåt-cachen

Moderna webbläsare håller nyligen besökta sidor i minnet så att bakåtknappen återställer dem direkt. Om en besökare öppnar inställningscentret på en sida, återkallar samtycke och sedan trycker bakåt kan den återställda sidan fortfarande ha taggar igång från tidigare. Lyssna på händelsen pageshow och kontrollera dess egenskap persisted: när en sida återställs från den här cachen, läs om det lagrade samtyckestillståndet och stoppa eller starta taggar därefter.

En testrutin

• Ladda en sida i en ren session, avvisa, ladda sedan en andra sida och bekräfta att inga spårningstaggar avfyras.
• Upprepa med en andra ren webbläsare och bekräfta att bannern visas, vilket visar att den inte cachats bort.
• Kontrollera svarshuvuden för att se om sidor serveras från cache och jämför HTML:en med och utan en samtyckescookie — den ska vara identisk.
• Testa från minst två regioner efter att ha rensat cachen och sedan igen efter att cachen värmts upp.
• Återkalla samtycke, använd bakåtknappen och verifiera att taggarna stoppas.

Viktigaste lärdomarna

• Cachad HTML ska vara samtyckesneutral; låt CMP:n avgöra i webbläsaren.
• Undvik att variera på hela cookie-headern; det förstör träffgraden.
• Om banners skiljer sig per region, avgör på klientsidan eller lägg landet i cachenyckeln.
• Versionera CMP-filer så att långa cachetider inte fördröjer konfigurationsändringar.
• Hantera service workers och bakåt/framåt-cachen, och testa med uppvärmd cache, inte bara efter en rensning.