Existe uma conversa que quase todo dono de site já teve com um desenvolvedor e saiu insatisfeito. “Seu site está lento.” “Tá, mas quanto isso me custa?” E aí vem a resposta que não convence ninguém: “melhora a experiência”. Experiência é abstrato. Boleto é concreto. Enquanto a lentidão não vira número em reais, ela sempre fica no fim da lista de prioridades — atrás do banner novo e da promoção do mês.
Este post é para fechar essa lacuna. Velocidade de site tem, sim, ligação medida com receita — e dá para estimar quanto a sua lentidão custa por mês num modelo simples. Também vamos separar o que de fato move a agulha (as métricas que o usuário sente) do teatro da nota bonita do PageSpeed. Porque otimizar para o número errado é gastar energia sem ver dinheiro.
Velocidade e conversão: o que os dados mostram
Core Web Vitals são as três métricas com que o Google mede a experiência real de uso de uma página: velocidade de carregamento, resposta à interação e estabilidade visual. Elas existem porque a experiência de carregamento tem efeito direto e mensurável sobre quem compra.
O dado mais citado — e legítimo — vem do estudo Milliseconds Make Millions, conduzido pela Deloitte a pedido do Google. Foram 37 marcas de varejo, turismo e luxo, e mais de 30 milhões de sessões mobile analisadas. O resultado é desconfortável de tão pequeno o gatilho:
| Setor | Ganho com apenas 0,1s mais rápido (mobile) |
|---|---|
| Varejo | +8,4% de conversão, +9,2% no ticket médio |
| Turismo | +10,1% de conversão, +1,9% no ticket médio |
| Luxo | +40,1% na progressão para “adicionar ao carrinho” |
Leia de novo: um décimo de segundo. Não um segundo, não cinco. A lentidão do seu site não precisa ser gritante para custar dinheiro — ela drena conversão em silêncio, um milissegundo de cada vez.
Quanto a sua lentidão custa por mês
Você não precisa do estudo da Deloitte para estimar o seu caso. Precisa de três números que já tem no analytics e de uma conta de guardanapo:
- Visitantes/mês na página que importa (ex.: 40.000).
- Taxa de conversão atual (ex.: 2% → 800 conversões).
- Valor médio por conversão (ex.: R$ 150 → R$ 120.000/mês).
Agora suponha, de forma conservadora, que corrigir a lentidão recupere 5% da conversão — bem abaixo dos 8,4% do varejo no estudo. Isso significa 40 conversões a mais por mês, ou R$ 6.000 mensais. R$ 72 mil por ano deixados na mesa. E esse é o cenário tímido.
O objetivo do modelo não é precisão de laboratório — é tirar a performance do campo do “abstrato” e colocá-la no campo do “isso paga o projeto de otimização em duas semanas”. Quando a conversa vira número, a priorização muda sozinha. É a mesma lógica que aplicamos ao ligar produto e receita em performance web e conversão: decisão técnica justificada por dinheiro, não por gosto.
As três métricas que o usuário sente
Desde março de 2024, o Google consolidou os Core Web Vitals em três métricas — e trocou uma delas. O antigo FID saiu; entrou o INP, que mede a resposta à interação de forma muito mais completa (anúncio oficial no web.dev). O trio atual, com as réguas do Google:
| Métrica | O que mede | Bom | Ruim |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Quando o conteúdo principal aparece | ≤ 2,5s | > 4,0s |
| INP (Interaction to Next Paint) | Quão rápido a página responde ao clique/toque | ≤ 200ms | > 500ms |
| CLS (Cumulative Layout Shift) | Estabilidade — o layout “pula”? | ≤ 0,1 | > 0,25 |
Repare que cada uma cobre um momento diferente da frustração real: LCP é a espera para ver, INP é a espera para agir, CLS é aquele susto de clicar no lugar errado porque o botão se moveu. Otimizar performance é atacar esses três incômodos — não perseguir um número único.
LCP: a espera para ver
LCP alto quase sempre tem culpados conhecidos: imagem gigante sem compressão, servidor lento no primeiro byte, ou uma fonte/CSS que bloqueia a renderização. É a métrica mais visível e, em geral, a de melhor retorno para atacar primeiro no e-commerce e em landing pages.
INP: a espera para agir
INP é a métrica nova e a mais ligada a JavaScript pesado. Quando você clica em “adicionar ao carrinho” e nada acontece por meio segundo, é INP ruim — a thread principal está ocupada processando script em vez de responder a você. Sites com muita biblioteca e pouco cuidado sofrem aqui.
CLS: o layout que pula
CLS é o mais barato de corrigir e o mais negligenciado. A causa número um é imagem e anúncio sem dimensão reservada: o conteúdo carrega, empurra o resto para baixo, e o usuário toca no lugar errado. Reservar espaço para mídia resolve a maior parte.
Por que a nota do PageSpeed engana
Aqui está a armadilha que faz times otimizarem a coisa errada: a nota do PageSpeed Insights é um teste de laboratório. Ela simula um dispositivo e uma rede num ambiente controlado. É útil para diagnóstico, mas não é a experiência dos seus usuários.
Os dados que importam de verdade são os de campo — o CrUX (Chrome UX Report), que mede usuários reais, com celulares reais, em redes reais, no percentil 75. E é perfeitamente possível ter:
- Nota 95 no laboratório e reprovar nos Core Web Vitals de campo, porque seus usuários acessam de celular mediano em 4G, não do datacenter do teste.
- Nota 70 e passar de boa no campo, porque a base de usuários usa aparelhos e conexões melhores que o simulado.
A régua real é aplicada ao percentil 75 dos usuários de verdade: a experiência precisa ser boa para a maioria concreta que acessa o seu site, não para a média nem para o laboratório. Perseguir 100 no PageSpeed enquanto o campo continua vermelho é otimizar o painel, não o negócio.
O que realmente move a agulha em stack real
Depois de medir o campo e achar a métrica que falha, o retorno vem de um punhado de causas que se repetem em quase todo projeto:
- Imagens. O maior peso da web. Comprima, use formatos modernos, dimensione para o tamanho exibido e defina largura/altura para não gerar CLS.
- JavaScript em excesso. Cada biblioteca “só por conveniência” custa INP. Menos script, ou script carregado sob demanda, responde mais rápido ao usuário.
- Fontes que bloqueiam. Fonte customizada mal configurada trava a renderização e piora LCP. Carregue com estratégia e defina fallback.
- Servidor lento no primeiro byte. Cache, CDN e um backend que responde rápido cortam a base de todas as métricas.
- Reservar espaço para mídia e anúncio. Corrige CLS quase de graça.
O ponto de disciplina: priorize a página que gera receita. Home, página de produto e checkout primeiro. Otimizar uma página institucional que ninguém converte enquanto o checkout arrasta é gastar esforço longe do dinheiro. Essa lógica de escopo é a mesma que defendemos em MVP do zero à produção — resolver o que move o ponteiro antes de polir o resto.
Vale um alerta sobre atalhos: performance construída às pressas, empilhando plugin de cache e “otimizador mágico” sem entender a causa, costuma cobrar a conta depois. É o mesmo risco de subir código sem cuidado que descrevemos em vibe coding: não suba um projeto de fim de semana — funciona no teste e desmorona sob tráfego real. E cada camada extra que você adiciona para “acelerar” é mais uma coisa que pode quebrar em produção; os riscos de publicar apps em produção valem também para a stack de performance. O ganho sólido vem de atacar a causa — imagem, script, servidor — não de camuflar o sintoma.
E o SEO nisso tudo?
Sim, Core Web Vitals é sinal de ranqueamento do Google. Mas é honesto dizer: não é o sinal mais forte. Conteúdo relevante e autoridade pesam mais. Se o seu site é lento e tem conteúdo fraco, performance não salva o ranqueamento.
O maior retorno da velocidade não está no SEO — está na conversão. Menos abandono na espera, mais páginas por sessão, checkout que completa em vez de travar. O ganho de busca é um bônus agradável, não o motivo. Times que invertem essa ordem otimizam para o robô e esquecem do humano que paga a conta. Vale cruzar essa leitura com a manutenção contínua de sites que discutimos em manutenção WordPress contínua: performance não é projeto único, é higiene recorrente.
Um plano de ataque em quatro passos
Para sair da teoria sem se perder:
- Meça o campo. Abra o Search Console e o CrUX. Descubra qual das três métricas está no vermelho para usuários reais — não confie só na nota do laboratório.
- Calcule o custo. Rode o modelo de guardanapo com seus números. Transforme a lentidão em reais/mês para justificar a prioridade.
- Ataque a causa, na página certa. Comece pela página que gera receita e pela causa dominante (quase sempre imagem ou JavaScript).
- Remeça e monitore. Performance regride com o tempo — cada plugin, script de marketing e imagem nova corrói o ganho. Trate como acompanhamento contínuo.
Se você quer transformar isso em resultado — do diagnóstico de campo à correção na página que fatura — é exatamente o tipo de trabalho que fazemos em desenvolvimento web. A régua nunca é a nota bonita: é a conversão que sobe e a lentidão que para de custar.
Perguntas frequentes
Velocidade do site realmente afeta as vendas?
Sim, e há dados de campo para provar. O estudo “Milliseconds Make Millions”, da Deloitte com o Google, mediu 37 marcas e mais de 30 milhões de sessões: uma melhora de apenas 0,1 segundo no mobile elevou a conversão no varejo em 8,4% e no turismo em 10,1%. Velocidade não é vaidade técnica — é receita.
O que são Core Web Vitals?
São três métricas do Google que medem a experiência real de uso: LCP (velocidade de carregamento do conteúdo principal), INP (resposta à interação do usuário) e CLS (estabilidade visual do layout). Desde março de 2024, o INP substituiu o antigo FID. Elas são medidas com usuários reais, não em laboratório.
Qual é a diferença entre a nota do PageSpeed e os dados de campo?
A nota do PageSpeed Insights vem de um teste de laboratório, num ambiente simulado. Os dados de campo (CrUX) vêm de usuários reais no seu site, com dispositivos e redes de verdade. É possível ter nota 90 no laboratório e falhar nos Core Web Vitals de campo. A experiência real é o que conta para conversão e para busca.
O que é um bom LCP, INP e CLS?
Segundo o Google: LCP bom é até 2,5 segundos; INP bom é até 200 milissegundos; e CLS bom é até 0,1. Acima disso há faixas de “precisa melhorar” e “ruim”. A régua é aplicada ao percentil 75 dos seus usuários reais — ou seja, a experiência precisa ser boa para a maioria, não só na média.
Melhorar a performance ajuda no Google?
Ajuda, mas com peso realista. Os Core Web Vitals são um sinal de ranqueamento, e não o mais forte — conteúdo e relevância pesam mais. Na prática, o maior retorno da performance vem da conversão: menos abandono, mais páginas por sessão e checkout que completa. O ganho de SEO é um bônus, não o motivo principal.
Por onde começo a melhorar a velocidade do meu site?
Comece medindo os dados de campo reais (CrUX/Search Console) para saber qual métrica falha. Depois ataque as causas mais comuns: imagens pesadas e sem dimensão definida, JavaScript em excesso e fontes que travam a renderização. Priorize a página que gera receita — home, produto ou checkout — antes de otimizar o site inteiro.