Página lenta perde duas vezes: quem clicou no seu anúncio desiste antes de comprar, e o Google demora mais pra crawlear ou enxergar o conteúdo que depende de script. PageSpeed Insights e o relatório de Core Web Vitals do Search Console medem as duas coisas de graça.
- Core Web Vitals do Google: LCP bom até 2,5s, INP até 200ms, CLS até 0,1, medidos no percentil 75 mobile e desktop.
- A experiência na página de destino é um dos três fatores do Índice de Qualidade do Google Ads, ao lado do CTR esperado e da relevância do anúncio.
- Servidor lento reduz o limite de capacidade de rastreamento do Google; conteúdo preso em JavaScript pode nunca ser visto por robôs que não executam script.
- PageSpeed Insights e o relatório de Core Web Vitals do Search Console medem os dois problemas sem custo.
Página lenta cobra duas vezes de quem já roda Google Ads numa página de review ou de vendas. A pessoa que clicou no seu anúncio e pagou pelo clique desiste antes de ver a oferta inteira. E, se a lentidão vem do servidor respondendo devagar ou de conteúdo que só aparece depois de rodar um script, o Google também demora mais pra visitar e enxergar o que tem na página. São duas perdas diferentes, mas costumam sair da mesma página mal montada, e dá pra medir cada uma delas numa ferramenta gratuita do próprio Google.
Aqui o assunto é o que acontece dentro da página, depois que a pessoa já clicou. Campanha, orçamento e lance ficam com você.
O que conta como página lenta pro Google?
O Google mede a velocidade de uma página por três métricas chamadas Core Web Vitals, descritas na documentação oficial do web.dev. A primeira é o LCP, o tempo até o maior bloco de conteúdo visível aparecer na tela, bom até 2,5 segundos. A segunda é o INP, o tempo de resposta depois de um clique ou toque, bom em 200 milissegundos ou menos. A terceira é o CLS, uma nota de estabilidade visual (o quanto os elementos da página pulam de lugar enquanto carrega), boa em 0,1 ou menos.
Numa página de review, o LCP costuma ser a foto do produto ou o bloco de prova logo no topo. O INP aparece no botão de comprar ou no acordeão de perguntas frequentes, o elemento que a pessoa toca esperando resposta na hora. O CLS é o que mais engana: banner, selo de garantia ou vídeo que carrega um instante depois e empurra o texto pra baixo bem quando a pessoa ia clicar em alguma coisa.
O Google recomenda medir essas três métricas no percentil 75 dos carregamentos, separando o resultado de celular do de computador. Não adianta a página abrir rápido pra você no notebook de casa. O número que importa é o que a maioria das pessoas sente no celular, com a conexão que elas realmente têm.
Carregar rápido garante aparecer em primeiro lugar?
Não. A própria documentação de experiência de página do Google diz que não existe um único sinal de experiência que decida o ranqueamento. As Core Web Vitals entram como um dos sinais usados pelos sistemas de busca, mas uma pontuação perfeita nelas não garante posição no topo. O Google chega a dizer que perseguir nota máxima só por causa de SEO pode não valer o tempo gasto.
Velocidade é piso, não atalho. A página precisa passar dele pra não ser descartada cedo, mas passar não substitui o resto do trabalho de review: prova real, comparação honesta, preço conferido.
Por que a mesma lentidão aparece duas vezes na sua conta?
Quem roda tráfego pago já paga pelo clique antes de saber se a pessoa vai converter. O Índice de Qualidade do Google Ads é formado por três partes, segundo a própria central de ajuda: a taxa de cliques esperada, a relevância do anúncio e a experiência na página de destino, que o Google define como quão relevante e útil é a página pra quem clica no anúncio. Uma página que demora pra mostrar o que importa reduz essa utilidade percebida pela pessoa que acabou de clicar, antes de qualquer cálculo do Google entrar em cena.
O clique é cobrado no instante em que a pessoa toca no anúncio, antes mesmo de a página terminar de abrir. Se a página demora e a pessoa sai antes de ver o preço ou a prova que convenceria ela, esse valor já saiu da sua conta, independentemente do resultado.
É dinheiro gasto numa visita que nunca teve chance real de virar venda.
No lado orgânico, a conta é diferente da conta paga, mas corre em paralelo. A documentação oficial do Google sobre orçamento de rastreamento diz que, se o site desacelera (a latência sobe ou o tempo de resposta aumenta), o limite de capacidade de rastreamento cai, e o Google rastreia a página com menos frequência. Servidor que responde rápido tem o efeito contrário: segundo o próprio Google, "se conseguirmos carregar e renderizar suas páginas mais rápido, talvez consigamos ler mais conteúdo do seu site". Corrigir a lentidão é um ajuste na própria página, e ele melhora os dois lados ao mesmo tempo, sem mexer em orçamento, lance ou estrutura de campanha.
A IA também desiste de página lenta?
De um jeito diferente, sim. A documentação do Google sobre os recursos de IA na busca exige que a página esteja indexada e elegível pra aparecer com um trecho na pesquisa, e recomenda fortemente que o conteúdo importante esteja disponível em forma textual, não só dentro de um script. Essa recomendação encosta direto num problema técnico: o guia do próprio Google sobre JavaScript e SEO explica que uma página pode ficar numa fila de renderização por mais do que alguns segundos antes de o conteúdo gerado por script ser processado.
Quem monta a página dependendo muito de JavaScript tem um problema a mais: nem todos os robôs conseguem executar esse script, segundo o mesmo guia. Se o conteúdo que prova que a sua review é real, como o preço, a comparação ou o depoimento, só aparece depois que o script roda, alguns desses robôs simplesmente não chegam a ver esse conteúdo.
Esse é um dos motivos pelos quais escrever a página inteira em HTML puro, com o Claude Code montando e entregando o arquivo completo no final, tende a sair na frente. O conteúdo principal já nasce dentro do HTML, sem depender de um script carregando depois pra aparecer.
Isso é parecido com o que já mostramos sobre o status descoberta mas não indexada no Search Console: o Google encontra o endereço da página, mas demora, ou desiste, de decidir se ela entra no índice. Um servidor que responde devagar, ou conteúdo que só aparece depois do script rodar, soma mais um motivo pra essa fila andar devagar.
Como descobrir se a sua página está lenta, sem abrir código
Duas ferramentas gratuitas do próprio Google respondem essa pergunta sem precisar entender nada de programação. A primeira é o PageSpeed Insights: você cola o link da sua página e ele devolve uma nota e aponta, campo por campo, qual das três métricas está estourando o limite.
A segunda é o relatório de Core Web Vitals dentro do Search Console, que mostra o histórico real de quem visitou a sua página, não uma simulação. Ele agrupa páginas parecidas e classifica cada grupo em bom, precisa de melhoria ou ruim, separado por celular e computador.
A régua oficial completa: LCP até 2,5 segundos é bom, até 4 segundos precisa de melhoria, acima disso é ruim. INP até 200 milissegundos é bom, até 500 milissegundos precisa de melhoria, acima disso é ruim. CLS até 0,1 é bom, até 0,25 precisa de melhoria, acima disso é ruim. O status do grupo inteiro vira sempre o pior entre as três métricas, então uma única métrica ruim derruba a nota geral da página.
Vale rodar os dois antes de mexer em qualquer coisa. O PageSpeed mostra o problema técnico na hora. O Search Console mostra se esse problema está acontecendo de verdade com quem visita, no aparelho que essa pessoa realmente usa.
O que ajustar primeiro, dando o comando certo pro Claude Code
Nesse comando, o Claude Code não mede a velocidade da sua página. Ele lê o código dela e aponta, com explicação, o que costuma pesar mais numa página de review ou de vendas: imagem grande demais pro tamanho exibido na tela, imagem sem o atributo de largura e altura (o que causa o pulo visual que derruba o CLS), script carregado antes do conteúdo principal, e qualquer bloco de texto ou prova que só aparece depois de rodar JavaScript.
Leia o código completo da minha página de review. Me diga, item por item: (1) quais imagens estão maiores do que o tamanho exibido na tela e podem ser comprimidas ou redimensionadas; (2) quais imagens não têm largura e altura definidas no código, o que causa o conteúdo pulando de lugar enquanto carrega; (3) se existe algum texto, preço ou prova, como depoimento ou comparação, que só aparece depois que um script roda, em vez de já estar escrito no HTML; (4) qualquer script carregado antes do conteúdo principal da página. Pra cada item encontrado, explique por que isso atrasa o carregamento e o que muda se eu corrigir. Não invente uma métrica de velocidade: você não consegue medir isso lendo o código, só apontar o que está escrito nele.
Depois de aplicar os ajustes que o Claude Code apontar, o passo seguinte é voltar pro PageSpeed Insights e conferir se a nota mudou de verdade. É a mesma lógica de qualquer correção de página: dar o comando, entender o porquê de cada ajuste, aplicar, e conferir no navegador antes de considerar resolvido.
Dá pra aprender o resto do caminho, de palavra-chave a schema, dentro do curso SEO para Afiliados. E se quiser ver os outros pontos que travam uma página de afiliado sem que ninguém avise, o hub de SEO para Afiliados reúne todos eles.
Apareça no Google, no Bing e nas IAs
O passo a passo pra fazer isso na sua própria página, dando os comandos pro Claude e entendendo cada peça. Sem escrever código do zero.
Conhecer o SEO para Afiliados
Mais de 15 anos desenvolvendo sites como web designer, hoje focada em SEO para afiliados. Ensina a construir presença no Google, no Bing e nas respostas das IAs dando comandos pro Claude, sem precisar escrever código do zero.