Experimentação no Edge: Teste A/B na Camada do CDN

O teste A/B no edge significa decidir qual variação um visitante vê num ponto de presença do CDN, fisicamente perto dele, em vez de decidir no navegador ou num servidor de origem distante. Ele herda a maior vantagem do teste server-side, a ausência de cintilação, e acrescenta uma segunda por cima: a decisão acontece em uma de centenas de localidades da rede próximas do visitante, em vez de uma única região, o que corta a ida e volta que a renderização server-side tradicional pode adicionar. Isto não substitui os conceitos de feature flag que já rodam a maior parte dos experimentos server-side: são os mesmos conceitos executados em outra infraestrutura, com um conjunto diferente de trocas que este guia cobre por inteiro.

Três lugares onde a decisão de variação pode acontecer

Todo teste A/B, seja qual for a ferramenta, responde em algum momento do ciclo da requisição à mesma pergunta: qual variação este visitante específico vê. O que muda é onde essa pergunta é respondida.

O teste client-side roda um script no navegador que reescreve a página já renderizada, e é isso que causa o lampejo da versão original, coberto em profundidade na nossa comparação entre client-side e server-side. Um teste server-side tradicional move essa decisão para o backend, antes de qualquer HTML sair, o que elimina a cintilação por completo mas ainda leva todo visitante até onde esse backend roda fisicamente. O teste no edge mantém a propriedade de decidir antes de enviar o HTML e realoca a decisão para um ponto de presença do CDN perto do visitante, um entre centenas que Cloudflare, Fastly, Vercel e AWS operam mundo afora.

Por que a cintilação zero é estrutural, não um recurso

A cintilação existe só porque o navegador renderiza alguma versão da página antes de o script de teste terminar de decidir e reescrever o DOM. O edge elimina essa janela do mesmo jeito que qualquer teste server-side: a função no edge avalia a variação, monta ou encaminha a resposta correta, e o navegador nunca recebe uma versão que precisa descartar e substituir. A Cloudflare documenta esse padrão diretamente no próprio exemplo de teste A/B com Workers, em que o worker lê um cookie de atribuição e roteia a requisição para o caminho correto do backend antes de qualquer conteúdo chegar ao visitante, sem nenhuma etapa de reescrita no cliente, segundo a documentação de Workers da Cloudflare.

A Vercel faz a mesma troca de forma explícita na própria orientação: rodar a decisão no Edge Middleware, à frente da resposta, reduz o deslocamento de layout ao evitar experimentos carregados no cliente e dispensa o JavaScript extra que um script de teste client-side exige, segundo a base de conhecimento da própria Vercel. A Fastly enquadra do mesmo jeito na documentação de teste A/B do Compute, descrevendo o objetivo como servir a resposta final, já decidida, direto do edge, em vez de manipular o DOM depois do fato.

O que o edge acrescenta além da ausência de cintilação: proximidade

A parte específica do edge, em comparação com um teste server-side tradicional de região única, é onde essa decisão acontece fisicamente. Um backend que vive numa região da AWS responde a todo visitante a partir dali, não importa quão longe ele esteja. Uma função no edge responde do ponto de presença mais próximo de quem fez a requisição. A Cloudflare afirma que a própria rede cobre 348 cidades em 8 regiões, com 95% da população mundial conectada à internet a menos de 50 milissegundos de um dos seus data centers, segundo a página de rede da Cloudflare. Essa proximidade é o argumento de latência inteiro da experimentação no edge: não que a computação no edge seja instantânea, mas que o salto de rede até ela é curto em quase todo lugar.

Para tráfego brasileiro, esse ponto costuma ser mais concreto do que parece na teoria: uma origem hospedada numa região dos Estados Unidos paga a distância em toda requisição, e a decisão de variação feita ali herda essa distância inteira. Não vale colocar número nisso sem medir o seu próprio caso, e o teste honesto é simples: compare o tempo até o primeiro byte da sua página servida pela origem com o de um recurso servido pelo CDN, a partir do país onde o seu público está.

O AWS Lambda@Edge, construído em cima do CloudFront, roda sob restrições mais apertadas que uma função Lambda comum justamente porque executa no caminho da requisição: funções disparadas nos eventos de requisição ou resposta do visualizador são limitadas a 128MB de memória, uma fração dos 10.240MB disponíveis para funções nos eventos de requisição ou resposta de origem, e os dois tipos de evento têm teto de 30 segundos de execução, bem abaixo do limite de 15 minutos de uma Lambda padrão, segundo o guia do desenvolvedor do CloudFront da própria AWS comparando CloudFront Functions e Lambda@Edge. Esse teto de memória não é uma limitação para contornar, é um sinal sobre para que serve a computação no edge: uma decisão rápida tomada em toda requisição, não um lugar para rodar cálculo estatístico pesado, que pertence ao pipeline de análise e não ao caminho da requisição.

Segmentação por região nativa, sem uma segunda ida e volta

Uma capacidade que as plataformas de edge oferecem de forma nativa, e que o teste client-side ou server-side de região única não tem sem requisições extras, é a informação de geolocalização já resolvida pela própria rede, antes de o seu código rodar. Os Cloudflare Workers expõem isso pelo objeto cf da requisição, que inclui o código de país de duas letras do visitante, além de região, cidade, continente e até se é um país da União Europeia, tudo preenchido pela rede da Cloudflare no momento da requisição, segundo a documentação da API de runtime dos Workers. Um worker pode ler esse valor e escolher uma variação, uma moeda ou um idioma na mesma passada em que decide o teste A/B, sem nenhuma chamada separada a uma API de geolocalização e sem latência adicional para essa consulta.

Isso importa especificamente para testes que combinam experimento com regra de geografia: mostrar uma variação de preço regional só para visitantes de um país, ou testar um formato de moeda que nunca deveria vazar para fora da região alvo. O teste client-side aproxima isso com uma chamada de geolocalização a partir do navegador, o que adiciona uma ida e volta e uma dependência de serviço de terceiro; um servidor distante de região única também lê cabeçalhos de geo, mas só depois que a requisição já viajou até lá. No edge, o dado de geo e a decisão de roteamento chegam juntos, no ponto mais próximo do visitante.

Vale uma nota que a documentação dos fornecedores não faz por você: país, região e cidade são dados sobre uma pessoa. Usá-los para decidir o que ela vê é tratamento de dado pessoal, e a LGPD não deixa de valer porque o processamento acontece na borda da rede. A arquitetura no edge tem uma propriedade favorável aqui, que é poder usar a informação para rotear e descartá-la na mesma requisição, sem enviar nada a terceiros. Guardar geo ao lado do identificador de variação no seu pipeline de análise é a decisão oposta, e ela precisa ser deliberada, não um efeito colateral de ter o dado à mão.

Comparando as plataformas de edge, sem eleger favorita

Não existe runtime de edge universalmente melhor, só o que encaixa na infraestrutura que o time já tem. Um retrato neutro do que cada fornecedor documenta sobre a própria plataforma:

Plataforma	Modelo de runtime	Força real	Limitação real
Cloudflare Workers	Isolates V8, sem contêiner com partida a frio, KV e Durable Objects para estado	Roda independente de hospedagem; presença de rede ampla (348 cidades segundo a própria página de rede); exemplo maduro de teste A/B na documentação oficial	O modelo de isolate não tem sistema de arquivos local persistente; estado exige KV ou Durable Objects, mais uma peça de infraestrutura para administrar
Vercel Edge Middleware	Edge Runtime baseado em V8, integrado ao Next.js	Caminho mais simples se a aplicação já é publicada na Vercel; modelos oficiais de teste A/B prontos para copiar	Preso à plataforma e ao modelo de publicação da Vercel; pouco útil se a aplicação está hospedada em outro lugar
AWS Lambda@Edge	Funções Lambda rodando nas localidades de edge do CloudFront	Encaixa naturalmente numa stack que já usa CloudFront e AWS; reaproveita o ferramental Lambda conhecido	Limites mais apertados dos quatro: teto de 128MB nos gatilhos de requisição e resposta do visualizador (contra 10.240MB nos de origem), mais partida a frio nesse ponto, segundo o guia do desenvolvedor do CloudFront da própria AWS
Fastly Compute	Sandbox WebAssembly (Rust, JavaScript e outras linguagens que compilam para Wasm)	Exemplo dedicado e documentado de teste A/B e personalização, com partida a frio na casa dos milissegundos; isolamento forte entre inquilinos	Ecossistema e mercado de contratação menores que os de Workers ou Lambda; a cadeia de build WebAssembly adiciona uma etapa a que times só de JavaScript não estão acostumados

Cada linha dessa tabela é um retrato do que cada fornecedor afirma sobre o próprio produto hoje. Limites de runtime, presença regional e condições de plano gratuito mudam com frequência suficiente para valer a conferência na documentação atual antes de se comprometer com uma delas.

Os riscos que ninguém menciona na apresentação

A experimentação no edge resolve cintilação e corta latência, mas introduz modos de falha que um snippet client-side ou uma renderização simples nunca enfrentam, porque todos eles voltam ao mesmo ponto: um cache de CDN que não foi construído pensando na sua lógica de variação.

Envenenamento de cache: o visitante errado recebe a variação errada

Um cache de CDN decide se duas requisições são a mesma coisa usando uma chave de cache, normalmente só a URL. Se o seu código no edge varia a resposta por cookie de atribuição, país ou tipo de dispositivo, mas a chave de cache ignora tudo isso, o CDN pode guardar a resposta personalizada do primeiro visitante e servir exatamente essa resposta a todos os outros que pedirem aquela URL, não importa a qual variação ou região pertençam. A pesquisa da PortSwigger sobre envenenamento de cache descreve o mecanismo por baixo com precisão: qualquer diferença na resposta provocada por uma entrada que o cache não inclui na chave pode ser armazenada e repetida para outros usuários, transformando o próprio cache no mecanismo de entrega do conteúdo errado. Num teste A/B, isso significa que o experimento inteiro pode colapsar em silêncio para “todo mundo vê o que a primeira requisição pegou”, sem nenhum erro ser lançado em lugar nenhum.

A correção espelha o princípio que a própria Cloudflare documenta para as Cache Rules: todo cabeçalho de requisição que muda a resposta, um cookie de variação, um valor de Accept-Language, um tipo de dispositivo, precisa estar refletido na chave de cache ou na configuração de Vary da origem, ou a resposta precisa passar longe do cache, segundo a documentação de cache da Cloudflare sobre tratamento de Vary. Sem configuração, o comportamento padrão não considera automaticamente todo cabeçalho pelo qual a sua origem varia: a origem tem que declarar Vary explicitamente e a regra de cache tem que ser instruída a respeitar, que é exatamente a lacuna que transforma um erro de personalização num incidente de envenenamento de cache.

A invalidação de cache multiplica a cada dimensão que você acrescenta

Depois que a variação vira parte da chave de cache, “invalidar esta página” deixa de significar um objeto e passa a significar toda combinação de variação, região e dispositivo já servida para aquela URL. Um teste que sobe um novo controle depois de declarar vencedor, ou que precisa de reversão de emergência, tem que limpar cada uma dessas combinações, não a cópia única que uma página estática teria. Times que não planejam isso antes descobrem sempre do mesmo jeito: revertem a variação perdedora no código do edge e uma fatia dos visitantes continua vendo a versão antiga, cacheada e perdedora, até cada combinação expirar naturalmente ou ser limpa na mão.

O custo de computação é cobrado diferente de um acerto de cache estático

Servir uma resposta estática já cacheada por um CDN é quase de graça nos volumes em que a maioria dos sites opera. Rodar uma função em toda requisição, para ler um cookie, resolver geo e escolher uma variação, não é: Cloudflare Workers, Fastly Compute, Lambda@Edge e Vercel Edge Middleware cobram todos por requisição e tempo de computação, seguindo o modelo de preço publicado por cada fornecedor, em vez da economia de tráfego e acerto de cache de um CDN comum. Raramente isso é caro para um teste só, mas é uma linha de custo real e recorrente que um snippet client-side ou uma página puramente estática não carregam, e vale conferir a página de preços atual de cada plataforma antes de assumir que um teste no edge é de graça por ser “só CDN”.

Quando a experimentação no edge se paga, e quando é excesso de engenharia

Situação	Combina com edge	Combina mais com client-side ou server-side comum
Teste só troca título, imagem ou botão em poucas páginas	Raramente vale	Um snippet leve ou uma renderização simples resolvem com muito menos superfície operacional
Tolerância zero a cintilação num público global e de alto tráfego	Sim, é o caso de uso central	Não se aplica, é exatamente o problema que o edge existe para resolver
Teste precisa variar por país ou região antes de a página ser montada	Sim, o dado de geo nativo elimina uma consulta extra	Geolocalização no cliente adiciona ida e volta; server-side de região única adiciona distância
Time pequeno, sem ninguém dono da chave de cache e do código no edge	Normalmente ainda não vale	Arquitetura mais simples reduz a chance de um envenenamento de cache silencioso
Teste toca preço, permissão ou regra de negócio que já vive no servidor	Vale se esse backend já está atrás de um CDN com computação no edge	Um teste server-side tradicional pode já bastar sem mudar para o edge

A regra prática honesta: experimentação no edge é uma otimização de latência e de cintilação por cima do teste server-side, não uma disciplina separada a que se recorre por padrão. Se um teste server-side comum já atende ao critério, coberto passo a passo no nosso guia de implementação server-side, mover a mesma lógica para o edge só vale quando a proximidade extra, ou o dado de geo nativo, muda de fato o resultado para os seus visitantes.

Uma arquitetura mínima, descrita ponta a ponta

Um experimento no edge típico tem a mesma forma em Cloudflare Workers, Vercel Edge Middleware e Fastly Compute, diferindo principalmente na sintaxe. A função no edge intercepta a requisição antes de ela chegar à origem ou ao cache. Ela verifica se já existe um cookie de atribuição; se não existir, atribui o visitante a uma variação por um método estável e determinístico (um sorteio persistido em cookie, no padrão que o próprio exemplo da Cloudflare segue), para que o mesmo visitante caia na mesma variação em requisições repetidas. Opcionalmente lê o dado de geo fornecido pela rede para aplicar uma regra regional na mesma passada. Depois, ou reescreve o caminho da requisição para buscar uma resposta diferente na origem, como faz o exemplo da Cloudflare, ou monta a resposta direto no edge, como demonstra o exemplo do Fastly Compute. Por fim, e esta é a etapa que os times mais pulam, garante que a resposta passe longe do cache ou carregue uma chave de cache que reflita toda dimensão pela qual ela realmente varia, para que o CDN nunca confunda dois visitantes que deveriam ver coisas diferentes. Isso espelha a prática de rollout progressivo em mais um ponto: comece com a regra de geo ou de variação restrita, confirme que o comportamento de cache está correto para essa fatia estreita e só então amplie, em vez de publicar uma regra global no edge e descobrir uma falha de chave de cache com o tráfego já passando por ela.

Faça isso automático na Donnu

Tudo o que está acima acontece antes de a Donnu A/B entrar na história. A Donnu é, de propósito, uma ferramenta de experimentação client-side: um snippet leve que roda no navegador, feito para instalar em minutos, sem um worker no edge, sem auditoria de chave de cache e sem uma distribuição do CloudFront para manter. Isso é uma escolha deliberada, não um esquecimento: a computação no edge resolve um problema de latência e cintilação que a maior parte dos testes de marketing e de CRO nunca chega a enfrentar, e traz junto exatamente o risco de envenenamento e de invalidação de cache que este guia acabou de percorrer.

O que não muda conforme o lugar da decisão, navegador, origem ou edge, é a parte que quase todo texto sobre teste no edge pula: decidir um vencedor com rigor estatístico de verdade. Um teste no edge com cintilação zero e perfeito continua produzindo resultado sem significado se parar antes de atingir a amostra, ou se alguém espiar o painel e encerrar cedo. A Donnu se concentra nessa camada: amostra calculada, leitura bayesiana honesta da significância e atribuição estável de variação, a mesma disciplina que importa esteja a variação vindo de um nó de CDN ou de um snippet na página. Se o seu teste é uma mudança visual e a cintilação é um custo aceitável e bem mitigado, um teste grátis de 14 dias coloca um experimento analisado com rigor no ar hoje. Se o seu caso realmente precisa de infraestrutura no edge ou server-side antes, comece pelos guias de teste client-side x server-side e de como implementar teste A/B server-side para desenhar a arquitetura antes de colocar uma camada de estatística por cima.

Referências

• Cloudflare. A/B testing with same-URL direct access. Documentação de Workers. developers.cloudflare.com/workers/examples/ab-testing.
• Cloudflare. Request properties (o objeto cf). Documentação da API de runtime dos Workers. developers.cloudflare.com/workers/runtime-apis/request.
• Cloudflare. Rede global: 348 cidades, menos de 50ms para 95% dos usuários. cloudflare.com/network.
• Cloudflare. Vary. Documentação de conceitos de cache. developers.cloudflare.com/cache/concepts/vary.
• Vercel. A/B Testing on Vercel. Guia da base de conhecimento. vercel.com/kb/guide/ab-testing-on-vercel.
• Fastly. Use A/B testing to personalize responses. Exemplos de soluções. fastly.com/documentation/solutions/examples/ab-testing.
• AWS. Differences between CloudFront Functions and Lambda@Edge (limites de duração e memória por tipo de evento). Guia do desenvolvedor do Amazon CloudFront. docs.aws.amazon.com/AmazonCloudFront.
• PortSwigger. Practical Web Cache Poisoning. Pesquisa. portswigger.net/research/practical-web-cache-poisoning.

Leia também: O guia completo de feature flags · Teste A/B client-side x server-side · Como implementar teste A/B server-side · Rollout progressivo e canary release · Read in English