Raske sider, feil samtykke

Sidebufring er noe av det beste du kan gjøre for hastighet og hostingkostnader. Det er også en av de enkleste måtene å ødelegge et samtykkeoppsett uten å merke det. En buffer gjør nøyaktig det den får beskjed om: den lagrer et svar én gang og leverer det til alle som matcher samme nøkkel. Hvis det lagrede svaret inneholder noe som er spesifikt for én besøkendes samtykkevalg eller plassering, får neste besøkende det også.

Denne guiden tar for seg bufringslagene som vanligvis sitter foran et utgivernettsted — CDN-edgebufre, full-page-bufringsplugins, reverse proxyer, service workers og selve nettleseren — og hvordan du hindrer hvert av dem i å levere feil samtykkeopplevelse.

Kjerneregelen: hold samtykke ute av bufret HTML

Den tryggeste arkitekturen rendrer den bufrede HTML-siden samtykkenøytralt. Siden inneholder CMP-lasteren og taggene dine i en blokkert eller ventende tilstand, men ingen beslutning om akkurat denne besøkende. CMP-en kjører deretter i nettleseren, leser det lagrede valget, avgjør om banneret skal vises og slipper tagger fri tilsvarende.

Problemene begynner når serveren tar samtykkebeslutninger ved rendering, for eksempel:

• et tema eller en plugin som bare skriver ut annonse- eller analytics-tagger når en samtykkeinformasjonskapsel finnes;
• serverkode som utelater bannermarkup for besøkende som allerede har valgt;
• maler som bygger en besøkendes samtykketilstand inn i en inline skriptvariabel.

Når den siden er bufret, blir den første besøkendes tilstand alles tilstand. En besøkende som avviste sporing, kan få en side med tagger som allerede er aktive, eller en ny besøkende ser aldri et banner fordi den bufrede kopien stammer fra noen som allerede hadde avvist det.

Hvorfor «Vary: Cookie» sjelden er svaret

Lærebokløsningen for innhold per besøkende er å be bufre variere på cookie-headeren. I praksis har besøkende mange informasjonskapsler med unike verdier, så å variere på hele cookie-headeren presser vanligvis bufferens treffrate mot null. Noen CDN-er lar deg i stedet bygge buffernøkkelen fra verdien til én enkelt informasjonskapsel, noe som er gjennomførbart hvis samtykkeinformasjonskapselen har få mulige tilstander, men det øker kompleksiteten og multipliserer fortsatt antallet bufrede kopier. Å flytte beslutningen inn i nettleseren er enklere og holder bufferen effektiv.

Geografi ved edge

Mange utgivere viser ulike bannere etter region: et opt-in-banner for EU og Storbritannia, en opt-out-melding for amerikanske delstater og noe lettere andre steder. Hvis serveren velger varianten ut fra den besøkendes IP-adresse og den siden blir bufret, kan en europeisk leser få en bufret amerikansk side, eller omvendt.

Tre mønstre unngår dette:

1. Geolokasjon på klientsiden. La CMP-en bestemme regionen i nettleseren, slik at den bufrede HTML-en er lik for alle.
2. Land i buffernøkkelen. Hvis du må bestemme ved edge, ta med landskoden CDN-en din leverer i buffernøkkelen. Du får én bufret kopi per land, noe som er forutsigbart.
3. Ubufret edge-logikk. Kjør den regionale beslutningen i en edge-funksjon som injiserer en liten, ubufret verdi i en ellers bufret side.

Uansett hva du velger, dokumenter det. Geofeil hører til de vanskeligste å reprodusere, fordi de bare oppstår for besøkende ett sted som tilfeldigvis får en side bufret av noen et annet sted.

Bufring av selve CMP-skriptet

Å bufre CMP-lasteren lenge er bra for ytelsen, men har en pris når konfigurasjonen endres. Hvis du oppdaterer leverandører, formål eller bannertekst, og skriptet eller konfigurasjonsfilen er bufret i et år, vil noen besøkende fortsette å se den gamle versjonen. Sjekk hvordan CMP-en din versjonerer filene sine: et skiftende filnavn eller en versjonsparameter lar deg bufre aggressivt og likevel rulle ut endringer umiddelbart. Bekreft også at din egen CDN ikke fjerner query strings fra URL-er til tredjepartsskript hvis CMP-en er avhengig av dem.

Service workers og offline-bufre

Nettsteder med et progressive web app-lag bufrer ofte HTML i en service worker. Samme regel gjelder: lagre aldri en side som gjenspeiler en bestemt samtykkebeslutning. Utelat samtykkerelaterte endepunkter og sider i preferansesenteret fra service worker-bufring, og sørg for at en fersk CMP-konfigurasjon alltid kan hentes.

Back/forward-bufferen

Moderne nettlesere holder nylig besøkte sider i minnet slik at tilbakeknappen gjenoppretter dem umiddelbart. Hvis en besøkende åpner preferansesenteret på én side, trekker tilbake samtykket og deretter trykker tilbake, kan den gjenopprettede siden fortsatt ha tagger som kjører fra før. Lytt etter hendelsen pageshow og sjekk egenskapen persisted: når en side gjenopprettes fra denne bufferen, les den lagrede samtykketilstanden på nytt og stopp eller start tagger slik at de stemmer.

En testrutine

• Last en side i en ren økt, avvis, last så en andre side og bekreft at ingen sporingstagger utløses.
• Gjenta med en annen ren nettleser og bekreft at banneret vises, noe som beviser at det ikke ble bufret bort.
• Sjekk svarheadere for å se om sider leveres fra buffer, og sammenlign HTML-en med og uten samtykkeinformasjonskapsel — den bør være identisk.
• Test fra minst to regioner etter å ha tømt bufferen, og igjen etter at bufferen er varmet opp.
• Trekk tilbake samtykket, bruk tilbakeknappen og verifiser at taggene stopper.

Viktigste poenger

• Bufret HTML bør være samtykkenøytral; la CMP-en avgjøre i nettleseren.
• Unngå å variere på hele cookie-headeren; det ødelegger treffratene.
• Hvis bannere er ulike etter region, bestem på klientsiden eller legg landet til buffernøkkelen.
• Versjoner CMP-filer slik at lange bufferlevetider ikke forsinker konfigurasjonsendringer.
• Håndter service workers og back/forward-bufferen, og test med varm buffer, ikke bare etter en tømming.