Efeito Flicker em Teste A/B: o que é e como eliminar

O efeito flicker é o intervalo em que o visitante enxerga a página original antes de a ferramenta de teste A/B trocar o conteúdo pela variação. Quase todo mundo o trata como defeito estético, e ele é pior do que isso: como só a variação passa pela troca visível, o custo dela cai inteiro sobre um braço, e o experimento passa a medir a variação com uma penalidade embutida. No exemplo trabalhado deste guia, um teste A/A linha com 250.000 visitantes por braço, em que a variação só reaplica o mesmo conteúdo, mostra perda de 4,0 por cento com valor-p de 0,0036. Nenhuma palavra da página mudou. Este guia explica a linha do tempo que produz o flicker, por que o snippet anti-flicker troca um viés por outro, como medir o problema no seu site com A/A, A/A linha e marcas de desempenho, e o checklist para eliminá-lo. Faz parte do nosso guia completo de feature flags e aprofunda o problema que apresentamos em teste A/B client-side x server-side.

O que é o efeito flicker e por que ele acontece

O efeito flicker, também chamado de FOOC (flash of original content), é consequência direta de onde a decisão do teste acontece. Num teste client-side, o servidor entrega a página original para todo mundo, e só dentro do navegador um script decide em qual braço o visitante está e altera a página. Entre o HTML chegar e o script agir, o navegador não fica parado: ele pinta o que já tem.

A sequência é sempre a mesma:

1. O HTML chega e o navegador começa a montar a página.
2. A primeira pintura acontece com o conteúdo original, se nada a impedir.
3. O script da ferramenta é baixado, às vezes depois de um gerenciador de tags que também precisa ser baixado.
4. A configuração do teste é lida e o visitante é sorteado para um braço.
5. A mudança é aplicada no documento, e o navegador pinta de novo.

Tudo o que o visitante vê entre o passo 2 e o passo 5 é o controle. Se esse intervalo é imperceptível, o flicker não existe na prática. Se passa de um piscar, o visitante vê o título trocar, a imagem saltar ou o botão mudar de cor debaixo do cursor.

A Optimizely descreve o mecanismo na própria documentação: ao carregar de forma assíncrona, o navegador não espera o script terminar antes de exibir o corpo da página, e isso pode produzir a piscada. A mesma página registra a consequência que interessa a quem analisa experimentos: o flicker torna o resultado do experimento menos confiável.

Três formas de atacar o problema, três contas diferentes

Existem três famílias de solução, e cada uma paga o problema com uma moeda diferente.

Snippet síncrono no topo do head. O navegador para de montar a página até o script da ferramenta rodar. Se a decisão e a mudança acontecem antes da primeira pintura, não existe original visível. O custo é que o script vira um recurso bloqueante: se ele demora, a página inteira demora, para os dois braços. É o modo que a Optimizely recomenda, com a observação de que o carregamento assíncrono elimina o atraso mas aumenta muito a chance de piscada.

Snippet anti-flicker. Um pequeno código no head esconde a página (em geral com opacity zero ou visibility oculta) até a ferramenta avisar que aplicou a variação, ou até um tempo limite estourar. O original nunca aparece, mas o visitante olha para uma tela vazia durante esse tempo. Como a página é escondida antes de se saber o braço, o controle também espera.

Decisão no servidor ou na borda da rede. O HTML já sai com a variação, e não existe versão errada para esconder. O custo é de engenharia, e parte da latência se desloca para o servidor. É o caminho descrito em como implementar teste A/B server-side e em experimentação no edge.

abordagem	flicker visível	custo de velocidade	quem paga o custo	complexidade
assíncrono sem proteção	alto, sempre que o script chega depois da pintura	nenhum na exibição inicial	só a variação (troca visível)	baixa
assíncrono via gerenciador de tags	o mais alto, há dois downloads antes da decisão	nenhum na exibição inicial	só a variação	baixa
síncrono no topo do head	baixo, se a decisão cabe antes da pintura	bloqueio do tempo de download e execução do script	os dois braços	baixa
anti-flicker com tempo limite	nenhum até o limite, total depois dele	página escondida até aplicar ou estourar	os dois braços, e mais a variação se ela demora mais	baixa a média
servidor ou borda	nenhum	processamento no servidor ou na borda	os dois braços, em geral pouco	alta

A linha que mais engana é a do gerenciador de tags. A Optimizely é explícita: o snippet deve vir na resposta do servidor, e não entregue por gerenciador de tags nem injetado por outro script. O motivo é aritmético: o gerenciador precisa ser baixado e executado antes de sequer começar a baixar a ferramenta. O guia de Google Tag Manager para teste A/B detalha quando essa instalação ainda faz sentido.

Por que o efeito flicker é um problema estatístico, não só estético

Um teste A/B só é justo se os dois braços forem tratados de forma idêntica em tudo, exceto na mudança testada. O efeito flicker quebra essa premissa de três formas diferentes.

1. A troca visível pune só a variação

O controle é pintado uma vez e fica. A variação é pintada, desfeita e pintada de novo. Se a troca causa qualquer reação (estranhamento, desconfiança, um clique no lugar em que o botão estava, rolagem perdida por salto de layout), essa reação existe só num braço. O experimento mede o conteúdo da variação menos o custo da troca, e reporta a soma como se fosse o conteúdo.

O tamanho do viés depende de duas coisas: a fração de visitantes que chega a ver a troca e quanto eles perdem. O efeito geral é o produto das duas. A tabela abaixo é um modelo aritmético, não dado de mercado: as frações e perdas são hipóteses para mostrar a ordem de grandeza.

fração que vê a troca	perda de quem vê	efeito no braço inteiro	visitantes por variação para detectar	dias a 125.000/semana
10%	10%	1,00%	3.785.510	424
25%	10%	2,50%	610.010	69
40%	10%	4,00%	239.975	27
25%	20%	5,00%	154.304	18
50%	20%	10,00%	39.475	5

A conversão base é de 4 por cento, com 95 por cento de confiança e 80 por cento de poder. A leitura importante está nas linhas de cima: um flicker que machuca pouca gente produz um viés pequeno demais para ser detectado, e grande o bastante para apagar uma vitória real de 1 ou 2 por cento. Viés não precisa ser significativo para distorcer uma decisão.

2. O anti-flicker atrasa todo mundo, e às vezes atrasa mais um braço

O anti-flicker resolve a assimetria visual escondendo a página dos dois braços. O custo de velocidade, então, cai sobre os dois, e uma comparação entre controle e variação não enxerga esse custo: os dois perdem, a diferença entre eles não muda. Só um grupo sem snippet nenhum mostraria quanto o programa de testes está custando para o site inteiro.

A assimetria volta quando a variação demora mais para ficar pronta. Uma variação que espera um elemento existir, baixa uma imagem nova ou roda mais código libera a página depois do controle. Suponha, só para dimensionar, que cada 100 milissegundos custem 0,6 por cento da conversão, a mesma ordem de grandeza que o Bing mediu em receita (a seção de velocidade abaixo mostra de onde vem esse número e por que ele não se transfere direto para o seu site). Se a variação é revelada 150 milissegundos depois do controle, ela perde 0,9 por cento. Uma variação que vale mais 3,00 por cento aparece como mais 2,07 por cento. Com 250.000 visitantes por braço, o poder de detectar o efeito cai de 57,52 para 31,87 por cento, e a amostra necessária sobe de 424.620 para 885.402 por variação.

3. Quando o tempo limite estoura, o teste perde visitantes de forma seletiva

O tempo limite existe para a página nunca ficar presa. O que acontece com o visitante que estoura é um detalhe que muda a análise. A VWO documenta que, quando o código dela estoura o limite, o conteúdo original é exibido, quem é novo no teste não entra nele, quem já estava num braço vê o original, e visitas e conversões não são registradas. Entre as causas listadas estão conexão fraca e variação pesada demais.

Junte as duas frases: se a variação é mais pesada, ela estoura mais vezes, e quem some do braço dela são justamente os visitantes com aparelho lento e conexão ruim. O braço fica menor e mais rico do que deveria. Isso aparece como divisão desigual de tráfego (SRM): numa divisão planejada de 50/50, 250.000 visitantes num braço contra 246.900 no outro já dão valor-p de 0,00001 no teste de proporção, e o verificador de SRM faz essa conta com os seus números.

Os três mecanismos são variantes do mesmo defeito: a forma de entregar o teste afeta a métrica de um braço de um jeito diferente do outro. É exatamente a definição de viés de instrumentação, e o motivo pelo qual resultado grande demais pede desconfiança antes de comemoração. Twyman resumiu a regra numa frase que Kohavi e coautores citam no artigo do KDD 2014: qualquer número que parece interessante ou diferente costuma estar errado. O blog trata a disciplina em lei de Twyman. Com flicker, o sinal de alerta é o inverso do habitual: variação que perde de forma consistente, teste após teste, em mudanças visuais acima da dobra.

Quanto a velocidade custa, segundo quem mediu de verdade

Duas fontes são citadas quase sempre que alguém fala de velocidade e conversão, e elas têm qualidades de evidência muito diferentes.

fonte	desenho	o que afirma	como ler
Kohavi e coautores, KDD 2013 e KDD 2014 (Bing)	experimento controlado de lentidão: 10% dos usuários atrasados em 100 ms e outros 10% em 250 ms, por duas semanas	cada 100 ms de ganho melhora a receita em 0,6%	causal, num buscador de escala enorme; a inclinação vale para aquele site naquele momento
Deloitte, “Milliseconds Make Millions”, 2020, encomendado pelo Google	regressão logarítmica sobre 4 semanas de dados de 37 marcas e cerca de 30 milhões de sessões móveis	0,1 s de melhora em quatro métricas de velocidade associada a mais 8,4% de conversão no varejo e mais 10,1% em viagens	observacional; o relatório diz que só resultados estatisticamente significativos por marca entraram e que a Deloitte não auditou os dados

O experimento do Bing é o que sustenta a lógica deste guia, porque isola o atraso de todo o resto. Os autores do artigo de 2014 acrescentam um detalhe importante para anti-flicker: atrasar em 250 ms elementos do painel direito, carregados depois do evento de carregamento da janela, não teve impacto detectável, apesar de o experimento ter quase 20 milhões de usuários. Nem toda espera custa igual; esconder a página inteira é esconder justamente o que está no caminho crítico.

O estudo da Deloitte é útil como sinal de direção e perigoso como número. É correlação entre velocidade e resultado, com seleção dos resultados significativos, e um mais 8,4 por cento por 100 milissegundos é o tipo de número que merece a lei de Twyman antes de virar premissa de planejamento. O raciocínio completo sobre como obter uma inclinação própria está em velocidade de página e conversão.

E as próprias ferramentas documentam números de espera. A VWO informa que, por padrão, o código assíncrono dela espera 2.000 milissegundos pelas configurações do teste e 2.500 milissegundos pela biblioteca, com limite superior configurável de 5.000 milissegundos, que ela não recomenda ultrapassar. Não é o tempo que todo visitante espera, é o teto antes de desistir. Mas é uma escala de segundos, e o experimento do Bing já mediu perda de receita com atrasos de 100 e 250 milissegundos.

Como medir o flicker no seu site

Não dá para consertar o que não se mede, e o flicker tem a vantagem de ser mensurável com ferramentas que todo navegador já oferece. São quatro medições, da mais barata para a mais cara.

1. Tempo até a aplicação, por braço. No ponto em que a mudança termina de ser aplicada, registre uma marca com performance.mark. No controle, registre a mesma marca no ponto equivalente do código. A interface de desempenho do navegador também expõe a primeira pintura de conteúdo (First Contentful Paint), e a comparação entre as duas diz se o visitante chegou a ver o original.

// no fim da aplicação da variação, e no ponto equivalente do controle
performance.mark('ab-aplicado');
const aplicado = performance.getEntriesByName('ab-aplicado')[0].startTime;
const fcp = performance.getEntriesByName('first-contentful-paint')[0];
// se ainda não houve pintura de conteúdo, a mudança chegou antes dela
const viuOriginal = fcp ? aplicado > fcp.startTime : false;
enviarEvento('ab_tempo_aplicacao', { braco, aplicado, viuOriginal });

Com anti-flicker ligado, registre também o momento em que a página é revelada, porque é essa marca que define a espera do visitante. Reporte por braço a mediana, o percentil 75 e o percentil 95, e não a média: o flicker mora na cauda, nos aparelhos lentos.

2. Taxa de visitantes que viram o original. É a proporção de viuOriginal verdadeiro na variação. É o número que alimenta a primeira coluna da tabela de viés acima, e o único que diz se o problema é de 2 ou de 40 por cento do tráfego.

3. Teste A/A com o snippet. Os dois braços passam pelo mesmo caminho de carregamento e nenhum muda nada. Serve para validar sorteio, divisão e contagem, e o caminho está em teste A/A. Ele não mede o flicker, porque nenhum dos braços troca conteúdo.

4. Teste A/A linha. A variação passa pelo caminho completo de aplicação, mas reaplica exatamente o conteúdo do controle: reescreve o mesmo título, troca a imagem pela mesma imagem, recoloca o mesmo bloco. O resultado final na tela é idêntico ao controle, e a única diferença entre os braços é a troca em si. Se o A/A linha perde, a perda é o custo do mecanismo, e não de conteúdo.

O nome não é invenção deste guia. Kohavi e Longbotham usam exatamente esse termo (A/A′ no original, lido “A/A linha”) no artigo de resultados inesperados do SIGKDD Explorations, para o caso de redirecionamento: o braço A linha mostra a mesma página, só que chegando por um redirecionamento. E o resultado que eles relatam é o argumento inteiro deste texto: em todos os casos em que a Microsoft rodou esse A/A linha, a versão com redirecionamento teve desempenho significativamente pior que a outra. A recomendação deles se transpõe diretamente para o flicker: preferir um mecanismo no servidor que gere o HTML e, quando isso não for possível, garantir que controle e tratamento paguem a mesma penalidade, rodando A, A linha e B linha para que a comparação entre A linha e B linha seja justa e a diferença entre A e A linha meça o custo do mecanismo.

Exemplo trabalhado: o A/A linha que perdeu 4 por cento

Cenário. Uma loja com conversão de 4,00 por cento e 125.000 visitantes por semana instala a ferramenta de teste por gerenciador de tags, de forma assíncrona. A medição de tempo até a aplicação mostra que uma parte relevante dos visitantes móveis vê o título original antes da troca. O time quer saber se isso custa conversão antes de rodar a próxima leva de testes de título.

Desenho. Um A/A linha: o controle carrega o snippet e não muda nada; a variação reescreve o título e a imagem principal com o mesmo texto e a mesma imagem. Hipótese de planejamento: perda de 4 por cento relativo (por exemplo, 40 por cento dos visitantes veem a troca e perdem 10 por cento). Métrica primária: conversão. Duração fixada antes de começar.

Amostra. Coloque os parâmetros na calculadora: taxa atual de 4, efeito mínimo de 4 por cento relativo, confiança de 95, poder de 80, 125.000 visitantes por semana e teste bilateral.

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

A tela mostra 239.975 visitantes por variação, 479.950 no total e 27 dias. A calculadora dimensiona um efeito para cima; uma queda do mesmo tamanho relativo exige um pouco menos (230.949 por variação, pelo mesmo cálculo), então 27 dias é uma estimativa conservadora. Para sentir a sensibilidade, troque só o efeito mínimo:

perda que você quer detectar	visitantes por variação	total	dias a 125.000/semana
5% relativo	154.304	308.608	18
4% relativo	239.975	479.950	27
3% relativo	424.620	849.240	48

O time arredonda para quatro semanas completas, o que dá 250.000 visitantes por braço.

A leitura precoce que não se deve fazer. Depois de uma semana, com 62.500 visitantes por braço, a variação tinha 2.400 conversões contra 2.500 do controle. É a mesma perda de 4,0 por cento, com valor-p de 0,1450. Parar aqui e concluir que “flicker não importa” seria ler um teste com cerca de 30 por cento de poder como se fosse prova de ausência. Ver o problema do peeking para o custo de olhar antes da hora nas duas direções.

O resultado. Depois de quatro semanas:

braço	visitantes	conversões	taxa
A, snippet sem troca	250.000	10.000	4,00%
A linha, troca pelo mesmo conteúdo	250.000	9.600	3,84%

Cole na calculadora:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

A tela mostra taxa de 4,00% no controle e 3,84% na variação, melhora relativa de -4,0%, valor-p de 0,0036, intervalo de 95 por cento da diferença de -0,3% a -0,1% (pp) e o veredito Vencedora com significância · A vence. Por trás do arredondamento da tela, a diferença absoluta é de menos 0,1600 ponto percentual, o z vale menos 2,9148, o valor-p exato é 0,003559 e o intervalo vai de menos 0,2676 a menos 0,0524 ponto percentual.

O que o resultado diz. O controle venceu uma versão idêntica a ele. Não existe explicação de conteúdo; a perda é o preço do mecanismo de entrega. E a divisão estava correta: 250.000 contra 250.000 não acende nenhum alerta de SRM, e o A/A com o snippet, rodado antes, tinha dado 10.000 contra 10.031 conversões, com taxa de 4,00% contra 4,01%, melhora de +0,3%, valor-p de 0,8231 e o veredito Ainda sem significância. A régua funcionava; ela só pesava sobre um lado.

O que fazer com ele. Três consequências práticas. Primeiro, todo A/B de mudança acima da dobra rodado nessa instalação carrega uma penalidade da ordem de 4 por cento, com intervalo que vai de cerca de 1,3 a 6,7 por cento relativo. Segundo, uma variação que perdeu por pouco nos últimos meses pode ter sido boa. Terceiro, a correção vem antes do próximo teste: mover o snippet para o head, de forma síncrona, e repetir o A/A linha para confirmar que a perda sumiu, pela mesma lógica da rodada de confirmação.

Checklist para eliminar o flicker

1. Snippet síncrono e leve, no topo do head. A Optimizely pede que ele seja o primeiro script da página, logo depois das declarações de charset, das meta tags e do CSS. Qualquer script que venha antes atrasa a decisão.
2. Nada assíncrono na frente da ferramenta. Gerenciador de tags adiciona um download inteiro antes da decisão. Se precisar usá-lo, aceite o anti-flicker e meça o custo.
3. CSS da variação aplicado antes da pintura. Mudança de estilo pode entrar como regra de CSS no próprio carregamento síncrono, em vez de esperar o documento ficar pronto para alterar elemento por elemento.
4. Seletores estáveis. Seletor que depende de posição ou de classe gerada automaticamente falha em silêncio ou espera um elemento que chega tarde. Use identificadores ou atributos de dados fixos.
5. Anti-flicker restrito e com tempo limite curto. Esconda só os elementos que mudam, e só nas páginas com teste ativo. A Optimizely lembra que o flicker só é problema em mudanças visíveis no carregamento, acima da dobra; mudança abaixo da dobra ou disparada por ação do visitante pode dispensar esconder qualquer coisa.
6. Preconnect para os domínios da ferramenta. A Optimizely recomenda preconnect e preload para o domínio do snippet no topo do head, e preconnect para o endpoint de eventos.
7. Variação leve. Imagem nova otimizada, pouco código, nenhuma dependência extra. Variação pesada é a que estoura o tempo limite e perde visitantes.
8. Mudança estrutural vai para o servidor ou para a borda. Layout novo, página de preço, fluxo diferente: quando a mudança é grande, trocar no navegador é caro e visível. É o terreno de experimentação no edge.
9. Tempo até a aplicação medido por braço, em todo teste. Mediana, percentil 75 e percentil 95, com a taxa de quem viu o original. Trate como métrica de guardrail.
10. A/A linha depois de qualquer mudança de instalação. Trocou o snippet de lugar, mudou de ferramenta, adicionou gerenciador de tags: rode de novo.

Erros comuns

• Testar o flicker só no computador do escritório. Conexão rápida e máquina potente escondem o problema. O flicker mora no percentil 95, no celular com rede instável.
• Achar que o anti-flicker zerou o custo. Ele zerou a piscada. A espera continua, para os dois braços, e só aparece contra um grupo sem snippet.
• Rodar A/A e concluir que não há flicker. Num A/A nenhum braço troca nada. Quem mede o custo da troca é o A/A linha.
• Aumentar o tempo limite para “não perder visitantes”. Diminui os estouros e aumenta a espera máxima de quem está na página escondida. É uma troca, não uma solução.
• Ignorar SRM pequeno em teste de variação pesada. A diferença de tamanho entre braços pode ser o tempo limite removendo justamente os visitantes lentos de um lado.
• Comparar ferramentas pelo tamanho do script e mais nada. O que importa é quando a decisão acontece em relação à primeira pintura. O comparativo de ferramentas de teste A/B põe performance ao lado dos outros critérios.
• Descartar variação que perdeu por pouco sem checar o mecanismo. Perda de 2 a 4 por cento em mudança visual acima da dobra é exatamente o tamanho que um flicker produz.

Faça isso automático na Donnu

A dor específica do flicker é que ele não aparece em lugar nenhum do relatório. O teste termina, a variação perdeu por pouco, e ninguém sabe se perdeu pelo conteúdo ou pela forma como foi entregue.

O snippet da Donnu foi escrito com a regra de nunca quebrar a página do cliente, e o código dele mostra como isso se traduz no problema deste guia. A configuração do teste pode vir embutida na própria resposta do script, e nesse caminho a decisão do braço é tomada de forma síncrona, sem uma segunda ida à rede (a exceção é a segmentação por tags do WordPress, que espera o documento carregar). Se o script for instalado de forma síncrona no head, isso acontece antes da primeira pintura; a tag padrão que o painel entrega é assíncrona, e para ela vale o trecho anti-flicker descrito a seguir. Nesse caminho, a página só é escondida quando existe um teste ativo que casa com aquela URL, e controle e variação passam pelo mesmo caminho de esconder e revelar. Há um tempo limite de tolerância, e falha nenhuma quebra ou trava a página: se a configuração não chega e não há cópia salva no navegador, o visitante vê a página original, e um erro no código da variação é descartado em silêncio, com a página visível. O painel oferece também um trecho anti-flicker opcional, para colar no head, que esconde a página antes de o script assíncrono chegar. E o snippet tem orçamento de tamanho: a verificação que roda junto com o build falha se o arquivo passa do teto.

O que nenhum snippet resolve sozinho é a instalação. Se o script chega por gerenciador de tags, o navegador já pode ter pintado o original antes de ele existir, e isso vale para qualquer ferramenta. Por isso a recomendação honesta é a do checklist: instale de forma síncrona quando puder, meça o tempo até a aplicação por braço e rode um A/A linha antes de confiar em testes de mudança visual. A calculadora de significância e a calculadora de tamanho de amostra fazem as contas deste guia com os seus números.

Referências

• Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. e Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Fonte do experimento de lentidão do Bing que atrasou 10 por cento dos usuários em 100 milissegundos e outros 10 por cento em 250 milissegundos por duas semanas, com a conclusão de que cada 100 milissegundos de ganho melhora a receita em 0,6 por cento, e da citação de Twyman de que qualquer número que parece interessante ou diferente costuma estar errado. PDF lido na íntegra. exp-platform.com.
• Kohavi, R., Deng, A., Longbotham, R. e Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014. Fonte da repetição do resultado de 0,6 por cento por 100 milissegundos, do experimento em que atrasar em 250 milissegundos elementos do painel direito carregados depois do evento de carregamento não teve impacto detectável com quase 20 milhões de usuários, e da aplicação da lei de Twyman a resultados bons demais. PDF lido na íntegra. exp-platform.com.
• Deloitte Digital, Google e Fifty-Five. Milliseconds Make Millions. 2020. Fonte da associação entre 0,1 segundo de melhora em quatro métricas de velocidade e mais 8,4 por cento de conversão no varejo e mais 10,1 por cento em viagens, da base de 37 marcas e cerca de 30 milhões de sessões em 4 semanas, do uso de regressão logarítmica, da inclusão apenas de resultados estatisticamente significativos por marca e da ressalva de que a Deloitte não auditou nem validou os dados. PDF lido na íntegra. thinkwithgoogle.com.
• VWO (central de ajuda sob a marca Wingify). Why Does Wingify SmartCode Time-out and How to Resolve It? Fonte dos tempos limite padrão de 2.000 milissegundos para as configurações e 2.500 milissegundos para a biblioteca, do limite superior de 5.000 milissegundos, das causas de estouro (variação pesada, conexão fraca, servidor inacessível) e do comportamento no estouro: original exibido, visitante novo fora do teste e visitas e conversões não registradas. help.wingify.com.
• Optimizely. Site performance best practices, Load snippet synchronously and asynchronously e Install the snippet as a non-blocking resource. Fonte das recomendações de colocar o snippet como primeiro script do head depois de charset, meta tags e CSS, incluí-lo na resposta do servidor em vez de gerenciador de tags, carregar de forma síncrona porque o assíncrono aumenta muito a chance de piscada, usar preconnect e preload; da afirmação de que o flicker torna o resultado do experimento menos confiável; e da observação de que o flicker só é problema em experimentos visuais acima da dobra, com mascaramento por visibility: hidden dos trechos afetados. support.optimizely.com · support.optimizely.com · support.optimizely.com.
• Kohavi, R. e Longbotham, R. Unexpected Results in Online Controlled Experiments. SIGKDD Explorations, 12(2), 2010. Fonte do termo teste A/A linha para um braço que chega à mesma página por um redirecionamento, do relato de que em todos os casos a versão com redirecionamento teve desempenho significativamente pior, da recomendação de preferir um mecanismo no servidor que gere o HTML ou dar a mesma penalidade aos dois braços, e do desenho A, A linha e B linha. PDF lido na íntegra. kdd.org.
• MDN Web Docs. PerformancePaintTiming. Fonte da definição de First Paint e First Contentful Paint expostos pela interface de desempenho do navegador, usados na medição de quem viu o original. developer.mozilla.org.

Leia também: Teste A/B client-side x server-side · Como implementar teste A/B server-side · Experimentação no edge · Velocidade de página e conversão · Viés de instrumentação · Teste A/A · Calculadora de significância · Read in English