Calculadora de impacto da velocidade na conversão

Toda apresentação sobre performance web repete a mesma frase: cada segundo custa 7% de conversão. Quase nenhuma mostra a conta, e nenhuma diz o que fazer com o número depois. Esta página faz as duas coisas. Ela parte de um tempo de carregamento e chega em receita, com o modelo aberto e ajustável, e termina no lugar onde a estimativa deveria terminar sempre: no tamanho de amostra necessário para transformar a suposição em fato medido.

Se você já sabe qual ganho de conversão espera e só quer traduzi-lo em dinheiro, a ferramenta certa é outra: a calculadora de impacto da taxa de conversão na receita, que parte de uma variação de taxa já conhecida. Esta aqui resolve o passo anterior, o mais difícil: estimar qual variação de taxa esperar a partir de uma mudança de velocidade.

Como usar

1. Preencha o tráfego mensal, a taxa de conversão atual e o valor médio por conversão do fluxo que você quer acelerar. Use os números de um mesmo período e de uma mesma família de páginas.
2. Informe o LCP atual. Pegue o valor de campo, do relatório de experiência real do Google ou da aba de dados reais do PageSpeed Insights, e não o número de laboratório, que costuma ser mais otimista.
3. Defina o LCP alvo, ou seja, aonde a engenharia consegue chegar. Se não houver estimativa técnica, use 2,5 segundos, que é o limite da faixa boa do Core Web Vitals.
4. Escolha a elasticidade. A moderada, de 7% por segundo, é a referência padrão. Use a conservadora para defender um investimento diante de um financeiro cético e a agressiva apenas como cenário de teto.
5. Leia o resultado de trás para frente: comece pela linha do teste. Se o ganho estimado exige mais visitantes do que você tem, o número serve para priorizar a tarefa, nunca para prometer resultado a alguém.

Como funciona: a fórmula

O modelo é uma elasticidade constante por segundo, aplicada de forma composta sobre a taxa atual:

Onde e é o ganho relativo por segundo economizado (0,07 na elasticidade moderada). A composição, em vez da multiplicação simples por segundos, é o que mantém a conta coerente nos dois sentidos: ganhar dois segundos a 7% vale 1,07 ao quadrado, e o caminho de volta desfaz exatamente o mesmo ganho, o que a versão linear não faz. Duas travas mantêm o modelo honesto: o crédito para em 0,8 segundo, porque abaixo disso não existe evidência pública que sustente a extrapolação, e o ganho total é limitado a 100%, porque velocidade sozinha não dobra a conversão de site nenhum.

Exemplo trabalhado (reproduz o resultado padrão)

Com os valores que já vêm preenchidos: 120.000 visitantes por mês, taxa de 2,2%, ticket de R$ 180, LCP indo de 4,2s para 2,5s e elasticidade moderada de 7% por segundo. Os segundos creditados são 4,2 − 2,5 = 1,7, já que os dois tempos estão acima do piso. O multiplicador é 1,07^1,7, ou seja, e^{1,7 × ln 1,07} = e^0,11502 = 1,12190, um ganho relativo de 12,2%.

A taxa estimada passa de 2,2% para 2,2 × 1,12190 = 2,47%, uma diferença de 0,27 ponto percentual. Em volume, as conversões mensais vão de 120.000 × 0,022 = 2.640 para 2.962, ou seja, 322 conversões a mais por mês. Multiplicando pelo ticket de R$ 180, a receita adicional é de R$ 57.925 por mês e R$ 695.097 por ano.

O cartão do valor de um segundo usa outra conta, mais simples e independente do alvo: a receita atual do fluxo é 2.640 × R$ 180 = R$ 475.200 por mês, e 7% disso são R$ 33.264 por mês, ou R$ 399.168 por ano. É o número que costuma encerrar a discussão sobre prioridade de backlog, porque ele existe mesmo que ninguém aprove projeto nenhum: é o que a lentidão cobra por mês enquanto o assunto fica parado.

Por fim, a linha do teste. Detectar um ganho relativo de 12,2% sobre uma base de 2,2%, a 95% de confiança e 80% de poder, exige 49.759 visitantes por variação. Com 120.000 visitantes por mês divididos em dois grupos, isso dá cerca de 26 dias de teste. É uma boa notícia disfarçada de detalhe técnico: neste cenário o ganho é grande o bastante para ser comprovado, e não apenas alegado.

Os três modelos no mesmo cenário

A tabela abaixo mantém tudo constante e troca só a elasticidade, para deixar visível o quanto a escolha do modelo domina o resultado final.

Da mais conservadora para a mais agressiva o resultado se multiplica por quatro, com os mesmos dados de entrada. Por isso a regra de uso é simples: apresente sempre a faixa, nunca um número solitário. Um business case que abre com a versão conservadora e menciona a agressiva como teto sobrevive à pergunta difícil da reunião; um que abre com a agressiva perde a credibilidade inteira quando alguém pergunta de onde veio o número.

O que cada segundo vale, na elasticidade moderada

Repare que o efeito é composto, não linear: quatro segundos não valem quatro vezes o valor de um. Isso importa na hora de fatiar o projeto, porque a primeira metade da otimização quase sempre é mais barata que a segunda, enquanto o retorno das duas é parecido. Cortar de 6s para 4s costuma custar um décimo do esforço de cortar de 3s para 2s, e entrega um ganho maior.

Por que LCP e não tempo de carregamento

O modelo pede LCP porque essa é a métrica que se aproxima do que o visitante percebe. Tempo total de carregamento inclui coisas que ninguém espera, como pixels de rastreamento e scripts que sobem depois da tela pronta, e por isso costuma exagerar o problema. A faixa oficial do Core Web Vitals é a régua a usar: até 2,5 segundos é bom, entre 2,5 e 4 segundos precisa melhorar, e acima de 4 segundos é ruim. A ferramenta classifica o seu tempo atual e o alvo por essa mesma régua, logo abaixo do resultado.

Use sempre o dado de campo, coletado de visitantes reais, e não o de laboratório. A diferença entre os dois costuma ser de segundos inteiros, porque o laboratório roda em rede estável, sem extensões e sem a cauda de aparelhos antigos que existe no seu público real. Business case construído sobre número de laboratório superestima o quanto já se está bem e subestima o tamanho do problema.

Como interpretar e onde este modelo engana

O primeiro limite é o mais importante: correlação não é causa. Os estudos que sustentam qualquer elasticidade de velocidade comparam sites e sessões rápidas com lentas, e site rápido tende a ser site com equipe de engenharia melhor, produto mais cuidado e tráfego mais qualificado. Existe também um efeito de seleção dentro do mesmo site, porque sessões lentas concentram aparelhos antigos, redes ruins e regiões mais pobres, que já converteriam menos por outros motivos. O efeito puramente causal da velocidade é menor do que o observado, e é por isso que a elasticidade conservadora existe.

O segundo é que a resposta não é uniforme entre públicos. Em fluxos de alta intenção, como o retorno de um cliente antigo para recomprar, a tolerância à lentidão é bem maior. Em descoberta e tráfego pago frio, ela é menor: quem chegou de anúncio abandona rápido porque não tinha investido nada na visita. Se o seu tráfego é majoritariamente de intenção alta, use a elasticidade conservadora.

O terceiro é a média que esconde a cauda. LCP médio de 4,2 segundos pode significar metade do público em 2 segundos e metade em 6, e é a segunda metade que carrega quase todo o prejuízo. Antes de estimar ganho médio, olhe o percentil 75 por dispositivo, que é justamente o corte que o Google usa. Muitas vezes o projeto certo não é acelerar o site inteiro, e sim consertar o pior segmento, quase sempre celular em rede móvel. Para dimensionar essa diferença, a calculadora de gap mobile versus desktop é o complemento natural desta página.

O quarto é o teto. Depois que o LCP entra na faixa boa, o retorno cai rápido, e o esforço de engenharia sobe. Sair de 5s para 2,5s costuma ser o projeto de maior retorno da lista; sair de 2,0s para 1,5s raramente paga o próprio custo, e é onde muito time bom gasta trimestre inteiro por orgulho de nota, não por resultado.

O que fazer com o número

• Use a estimativa para priorizar, comparando o ganho anual com o custo do projeto e com as outras tarefas da fila.
• Apresente sempre a faixa, do conservador ao agressivo, e diga qual você usa como base.
• Se a linha do teste indicar prazo viável, rode o teste e substitua a estimativa pelo dado real. Ganho medido vale mais que ganho previsto em qualquer discussão futura de orçamento.
• Se o teste não couber no seu tráfego, meça o antes e depois com cuidado, comparando janelas equivalentes de semana e de mix de canal, e assuma explicitamente que o resultado tem contaminação de sazonalidade.
• Registre o LCP junto do resultado de todo teste que você rodar. Sem isso, uma regressão de performance no meio de um experimento vira mistério permanente.

Perguntas frequentes

Quanto a velocidade do site afeta a conversão?

A referência mais citada do mercado é de 7% de queda relativa na conversão por segundo a mais de carregamento, número popularizado por estudos da Akamai. Existem leituras mais conservadoras, perto de 3% por segundo, e leituras bem mais agressivas, acima de 12% por segundo, que saem de curvas observacionais como a da Portent. A calculadora deixa você escolher qual usar porque a diferença entre elas muda o resultado em várias vezes, e fingir que existe um número único é o erro mais comum das planilhas de business case.

O que é LCP e por que a calculadora usa esse tempo?

LCP é o Largest Contentful Paint, a métrica do Core Web Vitals que marca quando o maior elemento visível da página termina de aparecer. Ela é a melhor aproximação disponível do momento em que o visitante sente que a página carregou, e é a que o Google publica por URL no relatório de experiência real. Por isso ela vale mais que tempo total de carregamento ou que o número sintético de uma ferramenta de laboratório: o que muda comportamento é o tempo percebido, não o instante em que o último script terminou.

Esse ganho de conversão é garantido?

Não, e nenhuma calculadora de impacto de velocidade pode prometer isso. As elasticidades públicas vêm de estudos observacionais, onde site rápido também costuma ser site mais bem cuidado, com melhor produto, melhor checkout e melhor tráfego. Parte do efeito medido pertence a essas outras causas. O que a estimativa entrega é uma ordem de grandeza para priorizar trabalho, e é por isso que a ferramenta mostra junto quantos visitantes seriam necessários para provar o mesmo ganho num teste controlado.

Por que o modelo para de contar abaixo de 0,8 segundo?

Porque a evidência pública some ali. Quase todos os estudos comparam faixas de 1 a 5 segundos ou mais, e extrapolar a mesma elasticidade para 300 milissegundos produz números de fantasia. O piso de 0,8 segundo é uma trava honesta: melhorar de 1,0s para 0,3s credita apenas 0,2s de ganho no modelo, e a ferramenta avisa quando parte da melhora ficou sob esse piso. O ganho real abaixo de um segundo existe, mas é pequeno demais para ser estimado com as elasticidades de mercado.

Como provar o ganho de velocidade num teste A/B?

Divida o tráfego entre a versão atual e a versão otimizada da mesma página e meça a conversão dos dois grupos, exatamente como em qualquer teste. O detalhe que derruba a maioria das tentativas é o tamanho de amostra: com os valores padrão desta página, o ganho estimado de 12,2% exige cerca de 49.759 visitantes por variação para ser detectado a 95% de confiança e 80% de poder, o que dá aproximadamente 26 dias. Se a sua conta der meses, o ganho estimado é pequeno demais para o seu tráfego e o resultado serve para priorizar, não para comprovar.

Vale mais otimizar a velocidade ou a própria página?

Compare os dois pela mesma régua, que é o que esta calculadora permite. Velocidade costuma render ganhos de um dígito percentual e tem teto: depois que o LCP entra na faixa boa do Core Web Vitals, cada décimo a mais custa muito e devolve pouco. Mudanças de oferta, prova e clareza da página costumam ter potencial maior e teto mais alto, mas também falham com mais frequência. A leitura prática é: tire a página da faixa ruim primeiro, porque lentidão grave envenena qualquer teste que você fizer depois, e só então dispute os pontos percentuais no conteúdo.

Continue

Se o próximo passo é provar o ganho, comece pela calculadora de tamanho de amostra e pela calculadora de duração de teste. Se a dúvida é onde o funil perde mais gente antes de qualquer otimização técnica, use a calculadora de funil. E para o contexto completo de priorização, o guia de otimização de conversão e o guia de otimização de checkout mostram onde velocidade entra na fila das coisas que movem taxa.