Velocidade de página e conversão: como testar de verdade

Velocidade de página move conversão, e existe evidência experimental séria disso. O que quase não existe é a possibilidade de você reproduzir essa medição no seu site. O efeito verdadeiro de uma melhoria realista de 200 ou 300 milissegundos é pequeno demais para o tráfego da esmagadora maioria dos sites: numa loja com conversão de 2,40 por cento, detectar um ganho relativo de 1,8 por cento exige 1.987.587 visitantes por variação, o que dá 928 dias a 30.000 visitantes por semana. A saída não é desistir nem repetir números de terceiros como se fossem seus, é inverter o experimento: degradar a variação de propósito, medir a inclinação com efeito grande e amostra pequena, e extrapolar. Este guia mostra quais números sobre velocidade se sustentam, quais são folclore, como montar um experimento de lentidão que cabe no seu tráfego, e o que fazer quando nem esse cabe. Faz parte do nosso guia completo de otimização de conversão.

O que se sabe de verdade sobre velocidade de página e conversão, com fonte

A literatura sobre velocidade é dominada por números repetidos de terceira mão. Vale separar o que veio de experimento controlado publicado do que veio de palestra.

afirmação	origem	qualidade da evidência
cada 100 ms de ganho melhora a receita em 0,6%	experimento de lentidão no Bing, publicado por Kohavi e coautores	alta, experimento controlado com braços de 100 ms e 250 ms por duas semanas
250 ms de atraso no servidor custam cerca de 1,5% de receita e 0,25% de CTR	mesmo experimento	alta
atraso de 100 a 400 ms reduz buscas por usuário em 0,2% a 0,6%	experimento de Brutlag no Google	alta, experimento controlado com braços de 200 ms e 400 ms
100 ms de lentidão reduzem vendas em 1% na Amazon	atribuído a Greg Linden, citado por Kohavi e coautores	média, é uma informação compartilhada em apresentação, não um artigo com metodologia
mostrar 30 resultados em vez de 10 derrubou tráfego e receita do Google em 20% por causa de meio segundo a mais	palestra de Marissa Mayer	baixa, e os próprios autores do Bing explicam por que a atribuição à velocidade não fecha

A última linha merece atenção porque é o número de velocidade mais citado da internet. Kohavi e coautores dão três razões para não acreditar na explicação:

1. Pelos experimentos de lentidão do Bing, 500 ms impactariam a receita em cerca de 3 por cento, não 20 por cento, e o CTR em cerca de 0,50 por cento, não 20 por cento.
2. Brutlag mediu no Google que atrasar a página de resultados em 100 a 400 ms reduz o número de buscas por usuário em 0,2 a 0,6 por cento, muito em linha com o Bing e muito longe dos 20 por cento.
3. Um experimento do Bing que mostrou 20 resultados em vez de 10 teve a perda de receita anulada ao acrescentar mais um anúncio principal, o que atrasou a página um pouco mais. A conclusão deles é que a proporção entre anúncios e resultados orgânicos pesa mais que a velocidade.

A lição de método aqui é maior do que a lição sobre velocidade: um número citado de palestra em palestra por quinze anos não vira evidência por repetição. O mesmo ceticismo vale para qualquer estatística de conversão que você encontrar sem um experimento por trás, e é o espírito da lei de Twyman.

Vale registrar o achado mais útil e menos citado do mesmo trabalho: nem toda parte da página importa igual. No Bing, atrasar em 250 ms os elementos do painel direito, carregados depois do evento de carregamento da janela, não produziu impacto detectável em métricas-chave, apesar de o experimento ter quase 20 milhões de usuários. Ou seja, o que está fora do caminho crítico pode ser lento sem custo.

Quanto tráfego um teste de velocidade de página honesto exige

Agora a conta que quase nunca aparece nos artigos sobre performance. A loja de exemplo:

parâmetro	valor
tráfego	30.000 visitantes por semana, 1.560.000 por ano
taxa de conversão	2,40%
ticket médio	R$ 180
receita anual	R$ 6.739.200
valor de 0,1 ponto percentual de conversão	R$ 280.800 por ano

Suponha que você acredite na regra do Bing e queira medir o efeito de tirar 300 ms do tempo de resposta. Pela regra de 0,6 por cento por 100 ms, isso seria algo próximo de 1,8 por cento relativo. Coloque esse MDE na calculadora:

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.

Com taxa base de 2,40 por cento, 95 por cento de confiança, 80 por cento de poder e teste bicaudal, a resposta é esta:

efeito relativo que você quer detectar	visitantes por variação	dias a 30.000/semana	dias a 1.000.000/semana
0,6% (100 ms, pela regra do Bing)	17.784.539	8.300	249
1,8% (300 ms)	1.987.587	928	28
3,0% (500 ms)	719.680	336	11
6,0% (1 s)	182.511	86	3
12,0% (2 s)	46.922	22	1

A coluna do meio é o motivo de existirem tantos artigos sobre velocidade e tão pouca medição própria. Nenhum site de 30.000 visitantes por semana consegue medir uma melhoria realista de velocidade pela taxa de conversão. Não é falta de ferramenta nem de rigor: é o efeito ser pequeno e a métrica ser rara.

A coluna da direita explica por que os números confiáveis do mercado vêm todos de buscadores. Com um milhão de visitantes por semana, o mesmo teste de 300 ms fecha em 28 dias.

O experimento de lentidão: inverta o sinal para caber no tráfego

A saída está na última linha da tabela, e é o desenho que Kohavi e coautores recomendam como a melhor forma de quantificar o impacto de performance: em vez de acelerar e tentar enxergar um ganho minúsculo, você atrasa de propósito e mede uma perda grande.

Três pontos que eles fazem sobre esse desenho, e que mudam como o resultado deve ser lido:

1. A lentidão mede a inclinação no ponto de hoje. Se o site mudar de velocidade ou o público mudar, a inclinação muda.
2. Ele responde à pergunta prática do trade-off. Se um recurso novo move a métrica M em X por cento e atrasa o site em T, o experimento de lentidão estima quanto do X foi comido pelo atraso, e permite estimar quanto o recurso valeria se fosse implementado de forma eficiente.
3. A extrapolação usa uma aproximação linear. Kohavi e coautores registram que confirmaram, rodando lentidões de tamanhos diferentes, que a aproximação linear é bem razoável no Bing. Isso é uma verificação empírica deles, não uma lei da natureza: se você for extrapolar, rode pelo menos dois níveis de atraso e confira se o efeito escala.

E há um segundo truque, independente do primeiro: troque a métrica primária por uma mais frequente. A conversão final é rara por definição. Adição ao carrinho, início de checkout, uso de busca interna e profundidade de rolagem acontecem muito mais e, por serem mais frequentes, exigem amostra muito menor. Isso tem um custo conceitual que precisa ser declarado: você está medindo uma métrica substituta, e substituta não é a métrica do negócio.

Combinando os dois truques, com taxa de adição ao carrinho de 8,00 por cento:

efeito relativo	visitantes por braço	dias a 30.000/semana
1,8%	561.747	263
3,0%	203.325	95
6,0%	51.515	25
12,0%	13.219	7

A última linha é um teste que cabe numa semana. Foi assim que o experimento de velocidade saiu do impossível para o rotineiro, sem afrouxar nada de estatística.

O exemplo trabalhado: um atraso de 2 segundos, lido na calculadora

Desenho. Metade do tráfego entra no experimento, para limitar a exposição ao prejuízo deliberado. Dentro do experimento, o braço B recebe um atraso artificial de 2.000 ms na resposta do servidor. Métrica primária: taxa de adição ao carrinho, base de 8,00 por cento. Métricas de guardrail: receita por visitante e taxa de erro. Duração planejada: 13.219 visitantes por braço, o que dá cerca de 13 dias com metade do tráfego.

Resultado. Depois de 13 dias: 11.000 visitantes no controle com 880 adições, e 11.000 no braço atrasado com 774 adições. 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 8,00 por cento contra 7,04 por cento, menos 12,0 por cento relativo, valor-p de 0,0067 e o veredito de que o controle vence, ou seja, o atraso realmente machucou. Sem o arredondamento da tela, a taxa da variação é 7,0364 por cento, a diferença absoluta é de menos 0,9636 ponto percentual, ou menos 12,05 por cento relativo, o z vale menos 2,7103, o valor-p é 0,006723 e o intervalo de confiança vai de menos 1,6604 a menos 0,2669 ponto percentual.

A extrapolação. Dois segundos são 20 blocos de 100 ms. Sob aproximação linear:

Esse intervalo é a parte honesta do resultado. O ponto central fica perto dos 0,6 por cento que o Bing mediu em receita, e isso é uma coincidência conveniente do exemplo, não uma confirmação independente: os números deste cenário foram escolhidos justamente nessa vizinhança para deixar a mecânica visível. O que o seu teste vai devolver é o seu número, e a chance de ele ser bem diferente é alta.

O que fazer com ele. Se 100 ms valem 0,6023 por cento da taxa de adição ao carrinho, e se essa taxa se traduzir proporcionalmente em conversão, tirar 300 ms do caminho crítico vale algo em torno de 1,8 por cento relativo de conversão, ou 0,043 ponto percentual sobre a base de 2,40 por cento. A R$ 280.800 por 0,1 ponto ao ano, isso são aproximadamente R$ 121.000 por ano. Esse número não é uma medição, é uma projeção em cima de duas premissas declaradas (linearidade e proporcionalidade entre carrinho e conversão), e o relatório precisa dizer isso com todas as letras.

O erro a não cometer. Rodar o teste de lentidão, achar significância, e depois escrever no relatório “confirmamos que 100 ms valem 0,6 por cento”. Você mediu 2 segundos. O resto é extrapolação, e a calculadora de impacto de velocidade serve exatamente para separar o que foi medido do que foi projetado.

Core Web Vitals: o que os limites significam e o que eles não significam

Quando o teste não cabe nem no desenho invertido, sobra usar limites publicados como guardrail em vez de como resultado. Segundo a documentação do web.dev, as três métricas estáveis e seus limites de “bom” são:

métrica	o que mede	limite de “bom”
LCP (Largest Contentful Paint)	carregamento	ocorrer em até 2,5 segundos
INP (Interaction to Next Paint)	interatividade	200 milissegundos ou menos
CLS (Cumulative Layout Shift)	estabilidade visual	0,1 ou menos

Dois detalhes que mudam a leitura: a avaliação é feita no percentil 75 dos carregamentos, separadamente para mobile e desktop, e os dados de campo vêm do Chrome User Experience Report, que coleta medição real anonimizada de usuários. O INP virou métrica estável em 2024, no lugar do FID.

Sobre ranqueamento, o Google é mais contido do que a indústria de SEO costuma repetir. A documentação de experiência da página afirma que não existe um sinal único, que as Core Web Vitals são usadas pelos sistemas de ranqueamento, e que a busca sempre procura mostrar o conteúdo mais relevante mesmo quando a experiência da página é ruim. Traduzindo para decisão: velocidade é um critério de desempate, não um substituto para relevância. Essa mesma fronteira aparece em CRO x SEO.

Há também um alerta antigo e ainda válido sobre métricas de carregamento. Kohavi e coautores registram, citando Steve Souders, que o tempo até o evento de carregamento da janela tem deficiências sérias em páginas modernas: uma página da Amazon renderizava a parte visível em 2,0 segundos enquanto o evento de carregamento disparava aos 5,2 segundos, e o Gmail fazia o oposto, com o evento aos 3,3 segundos e o conteúdo visível só aos 4,8 segundos. A métrica que você escolhe para “velocidade” muda o que você está otimizando, o que é uma forma de viés de instrumentação.

Como montar o programa quando nada disso cabe

Para sites em que nem o experimento de lentidão fecha, a resposta honesta não é inventar medição, é mudar o tipo de decisão. Três caminhos, em ordem de preferência:

1. Trate velocidade como higiene, não como experimento. Estabeleça os limites de Core Web Vitals como guardrail permanente, com alerta quando o percentil 75 sair da faixa. Isso não prova receita, mas evita regressão silenciosa, e é o que métricas de guardrail fazem.
2. Meça velocidade como custo dentro de outros testes. Todo teste A/B de recurso novo deve carregar tempo de resposta como guardrail. Quando um recurso ganha 2 por cento de conversão e atrasa a página em 400 ms, o experimento de lentidão diz quanto desse ganho é dívida.
3. Use o valor esperado para decidir sem medir. Se otimizar imagens custa dois dias de trabalho e o intervalo plausível de ganho vai de 0 a 1,5 por cento relativo, o cálculo do valor da informação normalmente diz para simplesmente fazer, sem teste nenhum. Teste é caro; otimização de imagem é barata e reversível.

Para sites de tráfego baixo, esse raciocínio se generaliza, e o blog trata dele em CRO para sites de baixo tráfego.

Como aplicar isso na prática

1. Nunca cite número de velocidade de terceiro como se fosse do seu site. Cite com a fonte e com o contexto (“no Bing, cada 100 ms valeu 0,6 por cento de receita”).
2. Antes de propor um teste de velocidade, faça a conta de tráfego. Se o resultado for maior que 60 dias, o teste não vai acontecer, e é melhor saber antes.
3. Inverta o experimento quando precisar de um número próprio. Atrase de propósito, com um atraso grande, em uma fração do tráfego, por pouco tempo.
4. Rode pelo menos dois níveis de atraso. Sem isso, a extrapolação linear é fé, não método. Foi assim que o Bing validou a linearidade.
5. Escolha uma métrica frequente como primária e declare que ela é substituta. Ganho de sensibilidade não pode virar troca silenciosa do que o negócio quer.
6. Separe o que está no caminho crítico do que não está. O experimento do painel direito do Bing mostra que atrasar o que carrega depois pode custar zero.
7. Registre a inclinação medida e a data. Ela vale para o site de hoje, com o público de hoje, no ponto de velocidade de hoje.
8. Acompanhe o efeito depois que o experimento acaba. Brutlag observou que quem passou pelo atraso de 400 ms fez 0,21 por cento menos buscas em média nas cinco semanas seguintes ao fim da injeção de atraso. Degradação deixa rastro.

Erros comuns

• Usar a mesma conta de tamanho de amostra de um teste de botão. O efeito de velocidade é uma ordem de grandeza menor, e a conta muda com o quadrado disso. A régua é a de efeito mínimo detectável.
• Concluir que velocidade não importa porque o teste deu nulo. Nulo com poder baixo não diz nada. Sem poder calculado, o resultado é só ausência de evidência.
• Extrapolar de 2 segundos para 50 milissegundos. A aproximação linear foi verificada numa faixa, não em todas.
• Medir velocidade só em laboratório. Ferramenta sintética mede uma máquina; o percentil 75 de campo mede o seu público, e é o que conta na avaliação de Core Web Vitals.
• Tratar Core Web Vitals como promessa de ranqueamento. O Google diz explicitamente que não há sinal único e que relevância vem antes.
• Rodar o teste de lentidão em 100 por cento do tráfego. Você está prejudicando gente de propósito. Fração pequena, tempo curto, guardrail de receita ligado.
• Esquecer que o navegador do usuário é parte do experimento. Um atraso no servidor atinge todo mundo igualmente; uma otimização de JavaScript atinge muito mais quem tem aparelho fraco, e isso vira efeito heterogêneo por segmento.

Faça isso automático na Donnu

O que trava um programa de velocidade quase nunca é a instrumentação de performance, que todo mundo já tem. É a falta de um registro de qual leitura de inclinação está valendo hoje e de quando ela foi medida. Sem isso, cada discussão sobre performance recomeça do zero, e o número mais citado na reunião acaba sendo o do Bing, que não é do seu site.

A Donnu guarda a configuração de cada experimento no momento em que ele é criado, com a métrica primária declarada, as métricas de guardrail e o histórico congelado por experimento. Isso é o que permite voltar meses depois e responder “quando medimos a inclinação de velocidade, e com qual atraso?”, que é a pergunta que separa um programa de performance de uma opinião recorrente.

A recomendação mais barata deste guia: coloque tempo de resposta como guardrail em todos os seus testes A/B, mesmo os que não têm nada a ver com performance. O custo é zero e, na primeira vez que um recurso novo ganhar conversão e atrasar a página, você vai ter os dois números lado a lado em vez de um só. A calculadora de impacto de velocidade na conversão transforma a inclinação medida em reais por ano.

Referências

• Kohavi, R., Deng, A., Longbotham, R. e Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014, Nova York. Fonte do experimento de lentidão do Bing que atrasou 10 por cento dos usuários em 100 ms e outros 10 por cento em 250 ms por duas semanas, mostrando que cada 100 ms de ganho melhora a receita em 0,6 por cento; da estimativa de que 250 ms de atraso no servidor impactam a receita em cerca de 1,5 por cento e o CTR em 0,25 por cento; do registro de que 500 ms impactariam a receita em cerca de 3 por cento e não em 20 por cento; das três razões para duvidar da atribuição por velocidade no caso dos 30 resultados do Google; do experimento do painel direito, em que atrasar em 250 ms elementos carregados após o evento de carregamento da janela não produziu impacto detectável apesar de quase 20 milhões de usuários; da recomendação do desenho de lentidão como melhor forma de isolar performance; da confirmação empírica de que a aproximação linear é razoável no Bing; da menção ao dado de 100 ms e 1 por cento de vendas na Amazon, atribuído a Greg Linden; e das deficiências do tempo até o evento de carregamento, com os exemplos da Amazon (parte visível em 2,0 segundos contra evento aos 5,2 segundos) e do Gmail (evento aos 3,3 segundos contra conteúdo visível aos 4,8 segundos). exp-platform.com.
• Brutlag, J. Speed Matters. Google Research, 23 de junho de 2009. Fonte do experimento que atrasou a página de resultados em 100 a 400 ms e mediu queda de 0,2 a 0,6 por cento no número de buscas por usuário, com a decomposição por braço (0,22 por cento nas semanas 1 a 3 e 0,36 por cento nas semanas 4 a 6 para o atraso de 200 ms; 0,44 por cento e depois 0,76 por cento para o atraso de 400 ms) e do efeito residual de 0,21 por cento menos buscas nas cinco semanas posteriores ao fim da injeção de atraso no grupo de 400 ms. research.google.
• web.dev. Web Vitals. Documentação de referência das Core Web Vitals. Fonte dos limites de “bom” usados neste guia: LCP em até 2,5 segundos, INP em 200 milissegundos ou menos e CLS em 0,1 ou menos; da avaliação no percentil 75 dos carregamentos, separadamente para mobile e desktop; da coleta de dados de campo anonimizados pelo Chrome User Experience Report; e do registro de que o INP se tornou métrica estável em 2024, no lugar do FID. web.dev.
• Google Search Central. Understanding page experience in Google Search results. Fonte das afirmações oficiais de que não existe um sinal único de experiência da página, de que as Core Web Vitals são usadas pelos sistemas de ranqueamento, e de que a busca sempre procura mostrar o conteúdo mais relevante mesmo quando a experiência da página é ruim. developers.google.com.

Leia também: Métricas de guardrail · Métrica substituta · Efeito mínimo detectável · CRO para sites de baixo tráfego · Lei de Twyman · Calculadora de impacto de velocidade · Read in English