A página lenta que importa não é a homepage

Resumo

Quando o chefe diz que o site está lento, o instinto é começar a comprimir imagens e pedir desculpas à página inicial. A jogada mais útil é decidir qual página realmente vale a pena acelerar primeiro. Este artigo percorre um cenário único: uma pequena equipe de marketing que precisa "corrigir a velocidade" de um site B2B de médio porte. Ele aborda a medição dos Core Web Vitals com dados de campo, a escolha de páginas com base no impacto para os negócios e a adição de dados estruturados somente após as correções baratas. A recompensa é um plano curto e defensável que faz sentido para um chefe não técnico.

A página mais lenta do seu site não é a que o PageSpeed Insights aponta. É a página que o seu chefe nunca abriu — a que está ligada a uma campanha paga, ou escondida em uma seção de produto esquecida — e é ela que realmente determina se o orçamento deste mês produz algo. Quando alguém sênior diz "o site está lento, conserte", não precisa de um projeto de velocidade do site. Precisa de um exercício de priorização.

Considere um cenário que muitos de nós já vivemos. Você é todo o time de marketing de uma empresa de software B2B de médio porte. O site tem uma página inicial, um blog, um centro de ajuda e cinco landing pages ligadas a campanhas de anúncios específicas. Seu chefe leu um artigo sobre Core Web Vitals ou ouviu uma reclamação de cliente. A instrução é clara: deixe mais rápido.

A forma como você responde na próxima hora decide se você vai passar o próximo mês comprimindo imagens ou fazendo um trabalho que muda os números que importam.

Comece pela página que gera dinheiro, não pela que envergonha

O princípio: o trabalho de velocidade tem um retorno, e esse retorno depende do tráfego e do valor de conversão. Uma página com pouco tráfego, mas alta conversão, pode ser mais importante para o negócio do que a homepage, mesmo sendo mais lenta.

Então, o primeiro passo é fazer uma lista de páginas a partir do analytics, não do sitemap. Quais páginas recebem dinheiro na forma de cliques de anúncios? Quais páginas não são tocadas desde o lançamento? Nesse cenário, a landing page mais importante — a que está por trás de um anúncio de pesquisa pago que está no ar há dois meses — foi criada com capturas de tela grandes e não otimizadas. A homepage, em comparação, já havia sido otimizada por uma agência um ano atrás.

Você não conserta a homepage primeiro. Você conserta a página que gera dinheiro. Isso não é uma escolha técnica, é uma escolha de negócio. Se uma auditoria técnica completa parece a resposta certa, resista por um momento. Auditorias produzem uma lista; elas não dizem por qual item começar. Uma auditoria técnica de SEO bem definida é uma ferramenta de decisão, não uma resposta de pânico.

Frequentemente, você vai descobrir que um pequeno número de páginas gera a maior parte do tráfego e das conversões; o resto é informativo ou vestigial. Isso não é motivo para ignorar para sempre as páginas informativas lentas. É um motivo para colocá-las em sequência depois das páginas que têm uma linha direta com a receita. A homepage pode ser a mais lenta de todas, mas se o objetivo do negócio é gerar leads, uma visita à homepage é apenas um ponto de partida — a landing page é onde alguém de fato converte.

Divida "rápido" em "medido" e "sentido"

O segundo passo é separar o que os testes de desempenho dizem sobre a sua página do que os usuários reais experimentam. A documentação dos Core Web Vitals do Google lista três métricas que contam para o ranking de busca: Largest Contentful Paint (carregamento), Interaction to Next Paint (responsividade) e Cumulative Layout Shift (estabilidade visual). Elas importam porque rastreiam momentos que afetam se alguém consegue de fato usar a página.

No cenário, você abre a landing page em um testador de desempenho e obtém uma pontuação razoável. Mas quando você compara isso com os dados de campo no Google Search Console — que refletem as experiências reais dos visitantes — a página acaba sendo frequentemente lenta. Esse é o sinal que importa. Os testes de laboratório ainda são úteis após uma mudança, para comparar antes e depois. Mas os dados de campo são a verdade objetiva para as pessoas que clicaram no seu anúncio a partir de uma variedade de dispositivos e conexões.

Em vez disso	Comece com isso	Por quê
Pontuação do PageSpeed como um número único	Dados de campo dos Core Web Vitals	Os dados de campo vêm de usuários reais, não de um servidor de teste
"O site está lento"	Quais páginas apoiam os objetivos do negócio	Páginas rápidas e inúteis não geram leads
Reconstruir o CMS	Comprimir imagens e limpar scripts	Correções de baixo risco trazem a maior parte do benefício

Se você quiser uma referência mais aprofundada para depois, um guia de Core Web Vitals pode explicar cada métrica em detalhes. Mas, por enquanto, você só precisa do suficiente para montar o plano. O segredo é identificar qual das três métricas está de fato causando o problema naquela página específica. Se o texto aparece tarde, veja imagens e resposta do servidor. Se os botões parecem engasgados, veja tarefas longas de JavaScript. Se o layout pula, veja os espaços reservados para anúncios e elementos incorporados. Essa nuance é o que separa uma correção direcionada de uma otimização aleatória.

Corrija as coisas baratas antes das caras

O terceiro princípio: não deixe um projeto de desempenho se transformar em um redesign. A maioria das melhorias que realmente movem a experiência do usuário são pouco glamourosas e baratas.

Olhe para a landing page e aponte os culpados óbvios. As imagens são capturas de tela em resolução total. Há um script de terceiros na página que ninguém consegue mais identificar. Uma fonte web está bloqueando a renderização do texto. Esses são problemas conhecidos.

Em um mundo perfeito, você passaria uma semana reescrevendo a página com um framework moderno. Na prática, você começa com tarefas de meio dia: comprimir imagens, adiar o script não utilizado, pré-carregar a imagem hero. Você pode testar essas mudanças em uma tarde, e elas não exigem um comitê de aprovação.

Ressalva: a velocidade nem sempre é tão simples. Algumas páginas são lentas por causa de um servidor, um banco de dados ou uma dependência de terceiros que você não controla. Mas se você não verificou as correções baratas, ainda não pode justificar a cara. Muitas equipes desperdiçam orçamento em uma reconstrução porque nunca comprimiram as capturas de tela. Há uma humildade aqui que vale a pena manter: uma pontuação de desempenho é um sintoma, não um diagnóstico. As correções baratas são diagnósticas por si mesmas. Depois de comprimir as imagens, você descobre se o gargalo era o seu conteúdo ou a sua infraestrutura.

Adicione dados estruturados enquanto você já está no código

Esta é a camada que surpreende o chefe. Depois de fazer as correções baratas, você já está dentro da página. Esse é o momento certo para adicionar algo que não é velocidade: dados estruturados.

Dados estruturados são marcações que ajudam os mecanismos de busca a entender o que uma página contém. É o mesmo HTML que pode levar a resultados de busca mais ricos e melhor visibilidade — e está se tornando mais relevante à medida que a busca se volta para respostas geradas por IA. Para uma equipe pequena, essa é uma alavanca subutilizada porque não exige escrever conteúdo novo. Você está rotulando o que já existe.

No cenário, você adiciona um schema orientado a serviços à landing page. O tipo exato depende do que a página aborda: uma página de serviço, um artigo, um produto. Você não precisa adicionar todos os tipos de uma vez. Adicionar um com cuidado é melhor do que adicionar dez de qualquer jeito. Nenhum resultado é garantido; o Google decide o que exibir. Mas o risco é baixo e o potencial de ganho é real. Se você quiser se aprofundar, um guia de implementação de dados estruturados cobre os passos práticos.

Traduza as correções em "isso gerou dinheiro?"

A parte difícil não é o trabalho técnico. É a forma como você apresenta para um chefe não técnico.

Seu chefe pediu uma coisa: deixar o site mais rápido. Se você disser "melhoramos o LCP na landing page", pode receber um olhar vazio. Em vez disso, traduza o trabalho em consequências de negócio.

Nesse cenário, a landing page é o destino de uma campanha paga. Cada segundo de espera é um segundo em que um visitante pode sair antes que a chamada para ação apareça. Então você explica: removemos atritos óbvios na página onde o dinheiro é trocado. Você não pode prometer um salto específico no ranking — quem promete está adivinhando — mas pode fazer um argumento razoável e honesto. Você também pode conectar isso ao orçamento que seu chefe já entende. O mesmo gasto com anúncios compra uma visita; a diferença é se essa visita tem a chance de se tornar um lead.

Um relatório mensal simples funciona melhor do que um painel cheio de jargões. Mostre três coisas: qual página você escolheu, qual métrica você mediu e o que você mudou. Se a métrica melhorar, é uma validação. Se não melhorar, você ainda tem um experimento claro para reavaliar. Não persiga uma pontuação única mês a mês; os Core Web Vitals flutuam com a mistura de tráfego, tipos de dispositivo e até região geográfica. Relate a tendência, não o número.

O que fazer na próxima segunda-feira

A lição do cenário: você não conserta "o site". Você conserta uma página específica, com base em dados, e termina com um processo repetível em vez de um projeto único. Quando alguém com poder diz "deixe mais rápido", a resposta mais útil é uma única pergunta de esclarecimento: qual página, e para quem?

Então meça os dados de campo, corrija as coisas baratas, adicione dados estruturados se você já estiver no código e relate em linguagem simples. Os resultados podem não ser dramáticos. Mas você saberá exatamente qual página ficou mais rápida, por que a escolheu e o que fazer em seguida. Esse é um resultado melhor do que um projeto vago que começou com uma pontuação de velocidade e terminou em um redesign que ninguém entendeu.