Páginas rápidas, consentimento errado

O cache de páginas é uma das melhores coisas que você pode fazer pela velocidade e pelos custos de hospedagem. Também é uma das formas mais fáceis de quebrar uma configuração de consentimento sem perceber. Um cache faz exatamente o que lhe mandam: armazena uma resposta uma vez e a serve a todos que correspondem à mesma chave. Se essa resposta armazenada contiver algo específico da escolha de consentimento ou da localização de um visitante, o próximo visitante também o receberá.

Este guia cobre as camadas de cache que normalmente ficam na frente de um site de publisher — caches de borda de CDN, plugins de cache de página completa, reverse proxies, service workers e o próprio navegador — e como impedir que cada uma sirva a experiência de consentimento errada.

A regra básica: manter o consentimento fora do HTML em cache

A arquitetura mais segura renderiza a página HTML em cache como neutra em relação ao consentimento. A página contém o carregador do CMP e suas tags em estado bloqueado ou de espera, mas nenhuma decisão sobre esse visitante em particular. O CMP então roda no navegador, lê a escolha armazenada, decide se mostra o banner e libera as tags de acordo.

Os problemas começam quando o servidor toma decisões de consentimento no momento da renderização, por exemplo:

• um tema ou plugin que só imprime tags de anúncios ou de análise quando há um cookie de consentimento;
• código do lado do servidor que omite a marcação do banner para visitantes que já escolheram;
• templates que incorporam o estado de consentimento de um visitante em uma variável de script inline.

Depois que essa página é colocada em cache, o estado do primeiro visitante se torna o estado de todos. Um visitante que recusou o rastreamento pode receber uma página com as tags já ativas, ou um novo visitante pode nunca ver um banner porque a cópia em cache veio de alguém que já o havia dispensado.

Por que «Vary: Cookie» raramente é a resposta

A solução de manual para conteúdo por visitante é dizer aos caches que variem pelo header de cookies. Na prática, os visitantes carregam muitos cookies com valores únicos, então variar por todo o header de cookies geralmente leva a sua taxa de acertos de cache a quase zero. Alguns CDNs permitem montar a chave de cache a partir do valor de um único cookie, o que é viável se o seu cookie de consentimento tiver poucos estados possíveis, mas aumenta a complexidade e ainda multiplica o número de cópias em cache. Mover a decisão para o navegador é mais simples e mantém o cache eficiente.

Geografia na borda

Muitos publishers exibem banners diferentes por região: um banner de opt-in para a UE e o Reino Unido, um aviso de exclusão para os estados dos EUA e algo mais leve nos demais lugares. Se o servidor escolhe a variante a partir do endereço IP do visitante e essa página é colocada em cache, um leitor europeu pode receber uma página americana em cache, ou o contrário.

Três padrões evitam isso:

1. Geolocalização no cliente. Deixe o CMP determinar a região no navegador, para que o HTML em cache seja o mesmo para todos.
2. País na chave de cache. Se precisar decidir na borda, inclua na chave de cache o código do país fornecido pelo seu CDN. Você obtém uma cópia em cache por país, o que é previsível.
3. Lógica de borda sem cache. Execute a decisão regional em uma função de borda que injeta um pequeno valor sem cache em uma página que, fora isso, está em cache.

Qualquer que seja a sua escolha, documente-a. Bugs de geografia estão entre os mais difíceis de reproduzir, pois só aparecem para visitantes de um lugar que por acaso recebem uma página colocada em cache por alguém de outro.

Colocando em cache o próprio script do CMP

Manter o carregador do CMP em cache por muito tempo é bom para o desempenho, mas tem um custo quando a configuração muda. Se você atualiza vendors, finalidades ou o texto do banner e o script ou o arquivo de configuração está em cache por um ano, alguns visitantes continuarão vendo a versão antiga. Verifique como o seu CMP versiona seus arquivos: um nome de arquivo ou parâmetro de versão que muda permite usar cache de forma agressiva e ainda lançar as mudanças imediatamente. Confirme também que o seu próprio CDN não remove query strings de URLs de scripts de terceiros se o CMP depender delas.

Service workers e caches offline

Sites com uma camada de aplicativo web progressivo costumam guardar HTML em cache em um service worker. Vale a mesma regra: nunca armazene uma página que reflita uma decisão de consentimento específica. Exclua do cache do service worker os endpoints relacionados a consentimento e as páginas da central de preferências, e garanta que uma configuração atual do CMP sempre possa ser buscada.

O cache de voltar/avançar

Os navegadores modernos mantêm na memória as páginas visitadas recentemente para que o botão voltar as restaure instantaneamente. Se um visitante abre a central de preferências em uma página, retira o consentimento e depois aperta voltar, a página restaurada pode ainda ter tags rodando de antes. Escute o evento pageshow e verifique a propriedade persisted: quando uma página é restaurada a partir desse cache, releia o estado de consentimento armazenado e pare ou inicie as tags para corresponder a ele.

Uma rotina de testes

• Carregue uma página em uma sessão limpa, rejeite, carregue uma segunda página e confirme que nenhuma tag de rastreamento dispara.
• Repita com um segundo navegador limpo e confirme que o banner aparece, provando que ele não foi eliminado pelo cache.
• Verifique os headers de resposta para ver se as páginas são servidas do cache, e compare o HTML com e sem cookie de consentimento — deve ser idêntico.
• Teste a partir de pelo menos duas regiões após limpar o cache, e de novo depois que o cache esquentar.
• Retire o consentimento, use o botão voltar e verifique se as tags param.

Principais conclusões

• O HTML em cache deve ser neutro em relação ao consentimento; deixe o CMP decidir no navegador.
• Evite variar por todo o header de cookies; isso destrói as taxas de acerto.
• Se os banners diferem por região, decida no cliente ou adicione o país à chave de cache.
• Versione os arquivos do CMP para que longos tempos de cache não atrasem mudanças de configuração.
• Trate service workers e o cache de voltar/avançar, e teste com o cache aquecido, não apenas após uma limpeza.