O teste visual sobe em uma tarde, mas pisca na tela. O server-side não pisca, mas precisa de sprint. Veja a diferença real entre os dois modelos e como escolher por hipótese.
Índice do artigo
- Os dois modelos em uma frase cada
- Como funciona o client-side
- Como funciona o server-side
- Flicker: o que é e por que importa
- Teste A/B e SEO
- Qual usar em cada tipo de hipótese
- Modelo híbrido
- Os erros que mais aparecem
- Perguntas frequentes
Os dois modelos em uma frase cada
- Client-side: a página carrega no navegador e um script da ferramenta altera o que o usuário vê.
- Server-side: o servidor decide a variante antes de montar a resposta, e a página já chega pronta.
Em uma frase: client-side muda a página depois que ela chega; server-side decide antes de ela sair.
Como funciona o client-side
Um script (como o do VWO Testing ou o script da Dynamic Yield) é carregado na página, decide a variante do usuário e aplica as alterações no navegador: troca textos, cores, ordem de blocos, esconde ou mostra elementos.
Vantagens: implementação rápida, pouca dependência de dev, editor visual para o time de CRO. Limitações: risco de flicker, peso adicional no front, dificuldade para testar lógica de negócio (preço calculado, regra de frete, algoritmo de busca) e exposição das variações no código do navegador.
Como funciona o server-side
A aplicação consulta a plataforma de experimentação no servidor (SDK ou API), recebe a variante e renderiza a página já na versão certa. Exemplos:
- VWO FME e ABsmartly: SDKs no backend que retornam a flag ou o treatment para o usuário.
- Dynamic Yield: o endpoint Choose da Experience API ativa campanhas pelo nome, resolve targeting e alocação de grupos e devolve a variação.
- Croct: fetchContent no servidor do Next.js retorna o conteúdo do slot para aquele usuário.
Vantagens: sem flicker, acesso a regras de negócio, mesma experiência em web e app, estratégia de testes não exposta no navegador. A documentação da Dynamic Yield lista exatamente esses benefícios para a Experience API. Limitações: exige desenvolvimento, depende de a CDN conseguir entregar conteúdo dinâmico e aumenta a responsabilidade de engenharia sobre o experimento.
Flicker: o que é e por que importa
Flicker (ou “flash of original content”) é quando o usuário vê a versão original por uma fração de segundo antes de a variante aparecer. Além de ser ruim para a experiência, ele contamina o teste: o usuário da variante também viu o controle, e a diferença medida fica menor que a real.
Soluções de anti-flicker no client-side escondem a página até a variante ser aplicada, mas trocam flicker por página em branco, com impacto em performance percebida. O server-side elimina o problema na origem.
Teste A/B e SEO
Pontos de atenção que valem para os dois modelos:
- Não mostre ao robô de busca um conteúdo diferente do que mostra ao usuário com intenção de manipular ranking.
- Em testes com URLs diferentes, use canonical apontando para a URL original.
- Prefira redirects temporários quando precisar redirecionar.
- Encerre o teste e publique a versão vencedora; não mantenha testes rodando indefinidamente.
No server-side e em personalização renderizada no servidor (como a da Croct), o conteúdo chega no HTML, o que é bom para performance. Mantenha a versão padrão relevante para quem não recebe personalização.
Qual usar em cada tipo de hipótese
Hipótese
Modelo recomendado
Texto de headline, cor ou posição de CTA
Client-side
Ordem de blocos na home
Client-side ou server-side (se houver flicker perceptível)
Regra de frete grátis, preço exibido, parcelamento
Server-side
Algoritmo de busca ou recomendação
Server-side
Novo fluxo de checkout ou onboarding
Server-side (com feature flag)
Conteúdo personalizado por público
Server-side (CMS personalizável)
Experiência que precisa ser igual em web e app
Server-side
Modelo híbrido
A maioria dos programas maduros usa os dois. A Dynamic Yield, por exemplo, recomenda combinar script em algumas áreas e API em outras, e oferece templates client-side para campanhas server-side: o servidor decide a variação e o front busca o template para renderizar.
A regra é: comece o programa com client-side para ganhar velocidade e cultura de testes, e leve para server-side as hipóteses de maior impacto no negócio.
Os erros que mais aparecem
- Testar regra de negócio no client-side, mudando apenas o que é exibido e não o que é cobrado.
- Ignorar flicker e subestimar o efeito da variante.
- Usar redirect em teste client-side e gerar SRM (Sample Ratio Mismatch).
- Duas ferramentas testando a mesma página ao mesmo tempo.
- Esquecer o código do experimento server-side depois da decisão (Feature flags).
Perguntas frequentes
Qual a diferença entre teste A/B client-side e server-side?
No client-side, a variante é aplicada no navegador depois do carregamento; no server-side, o servidor decide a variante antes de enviar a página.
O que é flicker em teste A/B?
É quando o usuário vê rapidamente a versão original antes da variante, o que prejudica a experiência e contamina o resultado.
Teste A/B server-side precisa de desenvolvedor?
Sim, a integração com SDK ou API é feita no código da aplicação.
Teste A/B prejudica o SEO?
Não, se feito corretamente: sem cloaking, com canonical em testes de URL e com encerramento no prazo.
Posso usar client-side e server-side juntos?
Sim, e é comum. Só evite testes simultâneos na mesma página.
Quais ferramentas fazem teste server-side?
Entre outras, VWO FME, ABsmartly, a Experience API da Dynamic Yield e a Croct para conteúdo personalizado.