Teste A/B Client-Side x Server-Side
Teste A/B client-side x server-side: como cada abordagem funciona, o problema do flicker, impacto em SEO/performance e quando escolher cada uma.
📚 Este artigo faz parte do guia Feature Flags: o Guia Completo.
Teste A/B client-side x server-side é a escolha de arquitetura mais consequente que uma equipe faz antes de rodar o primeiro experimento: onde a decisão de qual variação mostrar acontece, no navegador da pessoa ou no seu servidor. Já tocamos rapidamente nesse ponto no guia completo de teste A/B; aqui vamos fundo nas duas abordagens, no problema real que uma delas resolve (o flicker) e em como isso se conecta ao mundo de feature flags, que é hoje o jeito mais comum de rodar experimentos server-side em produto.
O que é teste A/B client-side
No teste client-side, a página carrega normalmente e um script de JavaScript (o “snippet” da ferramenta de teste) roda no navegador da pessoa, decide qual variação ela vai ver e modifica o HTML já carregado para aplicar essa variação, seja trocando um texto, escondendo um elemento ou reorganizando o layout. É o modelo original do teste A/B na web, popularizado por ferramentas como Optimizely, VWO e Kameleoon, e ainda é o mais comum para times de marketing e CRO.
A vantagem central é a velocidade de instalação: um único snippet colado no <head> do site, ou injetado via um gerenciador de tags como o Google Tag Manager, e a ferramenta já consegue criar variações visuais direto num editor visual, sem depender de um time de engenharia para cada teste. É por isso que o client-side domina o mercado de otimização de landing page e e-commerce, onde o ritmo de teste importa mais do que a robustez arquitetural.
A desvantagem central tem nome: flicker, também chamado de FOOC (flash of original content). Como o navegador sempre renderiza alguma versão da página antes do script de teste terminar de rodar, existe uma janela de tempo, de dezenas de milissegundos a poucos segundos, em que o visitante pode ver a página original antes da variação aparecer. A VWO descreve esse comportamento diretamente em seu help center: o flicker acontece porque a variação é aplicada via JavaScript depois que a página original já começou a carregar, e o atraso é inerente a qualquer teste que manipula o DOM no navegador.
O que é teste A/B server-side
No teste server-side, a decisão de qual variação mostrar acontece antes de qualquer HTML sair do servidor rumo ao navegador. O backend (ou uma camada de borda, como veremos adiante) avalia em qual variação aquele visitante entra e já monta a resposta com o conteúdo final, sem precisar de um script no cliente para reescrever nada depois. Não existe uma “versão original” para piscar, porque o servidor nunca envia a versão que não vai ser mostrada.
Esse modelo é o padrão em produtos de feature flag e experimentação como Statsig, GrowthBook, LaunchDarkly e Split.io. A documentação da GrowthBook é direta sobre o motivo: testes server-side permitem experimentos complexos que atravessam várias partes do código e evitam o problema de flicker que aparece no client-side. A troca é o custo de engenharia: rodar um teste server-side normalmente exige um SDK de servidor, uma forma de avaliar a variação antes de renderizar (server-side rendering ou uma chamada de API antes do render) e disciplina para manter a atribuição do visitante estável entre sessões, o que não é trabalho de configurar um editor visual, é trabalho de código.
O problema do flicker, com números reais
O flicker não é só estética. Uma análise da DebugBear sobre a home page da Adroll, usando o anti-flicker snippet da ferramenta de personalização Mutiny, encontrou um caso concreto: o filme da carga de página não mostrava nenhum conteúdo até 6 segundos depois da página abrir, mesmo com os recursos que bloqueiam a renderização terminando por volta de 2,9 segundos. Quando a CSS que esconde o conteúdo foi desativada manualmente no teste, o Largest Contentful Paint melhorou de 6 segundos para 2,7 segundos, uma diferença de 3,3 segundos só por causa do mecanismo anti-flicker. A DebugBear resume o efeito de forma direta: o snippet aumenta o LCP (uma métrica de Core Web Vitals que entra no ranqueamento de busca) e, sem ele, o teste corre o risco de mostrar a variação errada piscando ou o layout saltando quando o conteúdo novo tem tamanho diferente do original (o que também penaliza o Cumulative Layout Shift).
A saída mais comum para reduzir o flicker no client-side, documentada tanto pela Optimizely quanto pela Kameleoon, é o snippet anti-flicker: esconder o body (ou só os elementos afetados) com visibility: hidden ou opacity: 0 assim que a página começa a carregar, e só revelar depois que o script de teste aplicou a variação, com um timeout de segurança para nunca deixar a página travada em branco caso o script falhe (a prática de mercado, popularizada pelo antigo Google Optimize com um padrão de 4 segundos, é reduzir esse valor; a documentação da Optimizely recomenda mascarar os elementos com visibility: hidden sem fixar um número universal). Funciona, mas troca um problema visível (a piscada) por outro mais silencioso (atraso de renderização), e o resultado depende de configurar isso com cuidado.
Tabela comparativa: client-side x server-side
| Critério | Client-side | Server-side |
|---|---|---|
| Velocidade de setup | Rápida: snippet único, editor visual, sem depender de deploy | Mais lenta: exige SDK de servidor, endpoints de avaliação e, às vezes, deploy de código |
| Risco de flicker (FOOC) | Real, mitigado (não eliminado) com anti-flicker | Nenhum por construção: a variação já sai pronta no HTML |
| Impacto em SEO/performance | Depende da implementação; snippet anti-flicker pode piorar LCP e CLS se mal configurado | Neutro para SEO/performance quando bem implementado; sem script extra bloqueando o render |
| Quem consegue implementar | Marketing e CRO, sem depender de um time de engenharia | Exige um time de engenharia com acesso ao backend ou à camada de renderização |
| Casos de uso ideais | Testes visuais de landing page, copy, layout, e-commerce de conversão rápida | Testes de produto, preço, onboarding, permissão de acesso, lógica de negócio, mobile/apps |
Nenhuma linha dessa tabela decide sozinha. Um site de marketing que só testa título e botão dificilmente justifica montar infraestrutura server-side; um produto SaaS que testa fluxo de checkout ou regra de preço dificilmente aguenta o risco de um script de terceiro decidindo isso no navegador do cliente.
Quando escolher client-side
Client-side é a escolha certa quando o teste é essencialmente visual (título, CTA, imagem, ordem de seção), o time que vai rodar o teste não tem, ou não precisa envolver, um desenvolvedor a cada variação, e o volume de testes por mês é alto o bastante para que a velocidade de configurar via editor visual pese mais do que o risco residual de flicker. É o terreno natural de landing pages, e-commerce e sites de conteúdo, onde CRO precisa iterar rápido e o custo de um flicker de 100 milissegundos, bem mitigado, é aceitável frente ao ganho de agilidade.
Quando escolher server-side
Server-side vale o investimento de engenharia quando o teste envolve lógica que não é só aparência: preço, permissão de acesso a uma funcionalidade, uma regra de negócio inteira, ou qualquer fluxo que também precisa funcionar em mobile e apps nativos, onde não existe DOM de navegador para um snippet manipular. Também é a escolha certa quando a experiência não pode tolerar nem um milissegundo de flicker, como em produtos onde a percepção de estabilidade é parte do valor entregue, ou quando o teste precisa coexistir com regras de acesso que não podem, por segurança, ser decididas no cliente (a LaunchDarkly documenta esse ponto: chave de servidor nunca deve rodar no navegador, porque as regras de segmentação podem conter dado sensível).
Híbridos e a computação de borda como meio-termo
Entre os dois extremos existe um meio-termo real, não só teórico: rodar a avaliação da variação na borda (edge), em vez de no navegador ou num servidor central distante. A ideia é simples: a decisão de qual variação mostrar continua acontecendo antes do HTML ser montado, então não existe flicker, mas ela acontece num nó de rede geograficamente perto do visitante, em vez de um datacenter central, o que reduz a latência que o server-side tradicional pode adicionar. A Statsig documenta isso com a integração à Vercel Edge Config e a suporte a Cloudflare Workers, Fastly Compute e Akamai EdgeWorkers, com o objetivo de avaliar o flag o mais perto possível do usuário, para eliminar tanto o flicker quanto a espera de rede por uma decisão vinda de longe.
Outra forma de híbrido, mais comum na prática do dia a dia, é a organizacional: usar client-side para os testes rápidos de marketing e reservar server-side (ou uma camada de feature flag) só para os testes de produto que realmente precisam da robustez. A GrowthBook, por exemplo, oferece um modo de “avaliação remota” que evita expor as regras de segmentação no navegador mesmo em contextos client-side, levando parte da segurança do server-side para uma implementação mais leve. Não existe uma resposta única, existe a pergunta certa: o que este teste específico precisa, e o que ele pode pagar em engenharia para ter isso.
Ferramentas por abordagem (visão neutra)
| Abordagem | Exemplos | O que a própria documentação destaca |
|---|---|---|
| Client-side | VWO, Optimizely, Kameleoon | Editor visual, instalação rápida por snippet; documentação própria reconhece o risco de flicker e oferece mitigação via anti-flicker |
| Server-side / feature flag | Statsig, GrowthBook, LaunchDarkly, Split.io | SDK de servidor, avaliação antes do render, evita flicker por construção; exige mais integração de engenharia |
| Edge | Statsig (Vercel Edge Config, Cloudflare Workers, Fastly, Akamai) | Avaliação da variação na borda da rede, perto do visitante, unindo baixa latência com ausência de flicker |
Essa tabela é só um retrato do que cada categoria de ferramenta divulga sobre a própria abordagem, não um ranking. Confira sempre a documentação oficial mais recente antes de decidir, porque recursos de produto mudam.
Como isso se conecta a feature flags
Server-side testing e feature flags são, na prática, a mesma infraestrutura usada para dois fins diferentes. Um feature flag decide, no servidor, se uma funcionalidade aparece para um usuário; um teste A/B server-side usa exatamente esse mecanismo para decidir qual variação de uma funcionalidade aparece, e depois mede o efeito. É por isso que ferramentas como LaunchDarkly, GrowthBook e Statsig vendem as duas coisas juntas: a mesma avaliação de regra que liga e desliga uma feature também aloca tráfego entre variações de um experimento. Se esse ecossistema é novo para você, o guia completo de feature flags explica o conceito do zero, e feature flags x teste A/B aprofunda especificamente a diferença entre “ligar uma funcionalidade” e “testar qual variação converte mais”, que é exatamente o par de perguntas por trás da escolha entre client-side e server-side.
Faça isso automático na Donnu
A Donnu A/B é hoje uma ferramenta client-side, de propósito: um snippet leve, pensado para instalar em minutos sem depender de um time de engenharia, com a mesma preocupação de flicker que você acabou de ler tratada dentro do produto, não deixada para você configurar por conta própria. Isso não é a resposta certa para todo teste (um teste de preço ou de regra de acesso ainda pede a robustez do server-side), mas é a resposta certa para a fatia de testes que mais se repete no dia a dia de marketing e CRO: mudanças visuais que precisam ir ao ar rápido, sem abrir uma frente de engenharia.
Se o seu próximo teste é desse tipo, comece um teste grátis de 14 dias e veja o snippet em ação. Se o seu caso pede mais robustez, comece pelo guia completo de feature flags e por feature flags x teste A/B para mapear o que a sua stack já tem antes de escolher uma ferramenta nova.
Referências
- VWO. Why Do I Notice a Page Flicker When the VWO Test Page is Loading? help.vwo.com.
- Optimizely. Site performance best practices e Install the Optimizely snippet as a non-blocking resource. support.optimizely.com.
- Kameleoon. What is the flicker effect in A/B testing? kameleoon.com/blog.
- GrowthBook. Running Experiments on GrowthBook e Client-side feature flagging. docs.growthbook.io/experiments.
- Statsig. CDN Edge Testing for Cached Resources. docs.statsig.com/guides/cdn-edge-testing.
- LaunchDarkly. Choosing an SDK type. launchdarkly.com/docs/sdk/concepts/client-side-server-side.
- DebugBear. Anti-Flicker Snippets From A/B Testing Tools And Page Speed. debugbear.com/blog.
- Google Search Central. A/B Testing Best Practices for Search. developers.google.com/search.
Perguntas frequentes
- O que causa o efeito flicker (FOOC) em testes client-side?
- O navegador renderiza a página original primeiro e só depois o script de teste roda, avalia a variação e manipula o DOM para aplicá-la. Nesse intervalo, por menor que seja, o visitante pode ver a versão original piscar antes da variação aparecer. É por isso que o efeito também é chamado de FOOC, "flash of original content", termo usado pela VWO e por outras ferramentas de teste no navegador.
- Teste A/B server-side sempre evita o flicker?
- Sim, por construção: a decisão de qual variação mostrar acontece antes do HTML ser enviado ao navegador, então não existe um "estado original" para piscar. O que o server-side não elimina sozinho é a latência de rede entre o visitante e o servidor que decide a variação, por isso ferramentas como a Statsig e a Vercel levam essa decisão para a borda (edge), o mais perto possível do visitante.
- Teste A/B client-side prejudica o SEO?
- Não pelo teste em si, mas pelo jeito como muitas implementações são feitas. O Google recomenda usar rel="canonical" apontando para a URL original, evitar cloaking (mostrar algo diferente para o robô de busca) e não prolongar o teste além do necessário, conforme a documentação oficial do Google Search Central sobre teste de sites. O ponto que pesa mais na prática é performance: um snippet de anti-flicker mal configurado pode aumentar o Largest Contentful Paint, uma métrica de Core Web Vitals que entra no ranqueamento.
- Dá para migrar de client-side para server-side depois?
- Dá, e é um caminho comum: muitas equipes começam com uma ferramenta client-side leve para testes de página e migram partes do experimento para o servidor quando o teste passa a envolver lógica de produto, preço ou permissão de acesso, não só aparência visual. A migração custa engenharia real (endpoints de avaliação, SDKs de servidor, atribuição estável entre sessões), então vale planejar cedo qual parte do roadmap realmente precisa de server-side.
- Client-side e server-side podem rodar ao mesmo tempo no mesmo produto?
- Sim, e na prática é comum ver esse desenho: client-side para testes rápidos de marketing e landing page, server-side ou uma camada de feature flag para testes de produto, preço e onboarding. Não é um dado de pesquisa, é o padrão que aparece quando se olha para que cada categoria de ferramenta é vendida. O critério não é "qual ferramenta é melhor", é "o que aquele teste específico precisa": velocidade de instalação ou robustez de infraestrutura.