Antes de contratar um redesenho para resolver a lentidão de um site B2B, identifique onde a espera acontece, em quais páginas e sob quais condições. Compare observações de uso com medições técnicas e peça um teste que confirme a causa provável. Uma nota baixa pode orientar a investigação, mas não define, sozinha, o tamanho da reforma necessária.
Este roteiro ajuda quem acompanha marketing ou produto a preparar uma conversa objetiva com a equipe técnica. O resultado esperado é uma decisão entre corrigir um recurso, ajustar uma integração ou investigar uma limitação mais ampla da estrutura.
Troque “o site está lento” por uma situação reproduzível
Escolha uma tarefa comercial importante: abrir a página de um serviço, consultar um case ou iniciar um pedido de diagnóstico. Registre a URL, o dispositivo, a conexão e o ponto em que a pessoa percebe a demora.
Separe três situações que costumam aparecer na mesma reclamação:
- O conteúdo principal demora a aparecer.
- A página aparece, mas um botão ou menu demora a responder.
- Os elementos mudam de lugar enquanto a pessoa tenta usar a página.
Há ainda uma quarta situação: o formulário responde ao clique, porém a confirmação demora porque depende de outro serviço. Essa espera precisa ser investigada no fluxo de envio, mesmo que a navegação esteja rápida.
Evite começar apenas pela página inicial. Uma campanha pode levar diretamente a uma página de serviço com recursos diferentes. Selecione entradas relevantes e mantenha a lista curta o suficiente para repetir a conferência depois da mudança.
Leia duas evidências diferentes no PageSpeed
O PageSpeed Insights reúne dados de usuários reais, quando disponíveis, e um teste de laboratório com Lighthouse. Os primeiros mostram experiências observadas; o segundo ajuda a reproduzir e diagnosticar problemas em condições controladas. Os resultados podem divergir.
Confira se o painel de experiência real está mostrando a URL analisada ou a origem, que agrega páginas do site. Quando falta amostra da página, a ferramenta pode apresentar essa visão mais ampla. Ausência de dados reais não comprova desempenho bom nem ruim.
Salve o relatório com data, endereço e modalidade, celular ou computador. Anote também qual parte corresponde ao teste de laboratório. Comparar uma nota móvel com outra de computador, ou uma página com toda a origem, pode criar uma melhora aparente sem uma comparação válida.
Use o relatório para formular perguntas. Se o problema ocorre ao abrir um menu depois de navegar, uma medição concentrada na carga inicial pode não reproduzir a situação. Leve a sequência de ações à equipe, além da captura da nota.
Escolha o sinal que corresponde à reclamação
Os Core Web Vitals acompanham carregamento, resposta a interações e estabilidade visual. Os limites recomendados para uma experiência boa são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, avaliados no percentil 75, separando celular e computador. Esse percentil indica o valor abaixo do qual estão 75% das observações.
LCP ajuda a examinar quando o maior bloco de conteúdo visível aparece. INP trata da resposta visual às interações. CLS acompanha mudanças inesperadas na posição dos elementos. Nenhum desses indicadores informa, por si só, se a oferta foi compreendida ou se o contato virou uma oportunidade.
A definição de INP termina na próxima apresentação visual após a interação. Portanto, um botão mostrar rapidamente “Enviando” não comprova que o servidor já recebeu o formulário. Meça a confirmação dessa tarefa separadamente, seguindo o percurso de conversão do site B2B.
Não tente transformar todo problema em uma única nota. O diagnóstico melhora quando a observação, o indicador e a tarefa descrevem a mesma dificuldade.
Peça a causa provável, não uma lista de otimizações
Para cada problema prioritário, peça uma explicação verificável: qual recurso ou etapa contribui para a espera, qual evidência sustenta essa hipótese e que mudança permitiria testá-la?
O guia de otimização de LCP divide a espera em componentes como tempo até o primeiro byte da resposta, atraso até iniciar o recurso, duração do download e atraso até exibir o elemento. Essa divisão mostra por que reduzir o tamanho de uma imagem pode ser insuficiente quando ela começa a carregar tarde ou permanece oculta.
Em vez de aprovar “otimizar todas as imagens”, peça que a equipe identifique o elemento observado na página afetada. Se a hipótese envolver um script externo, teste seu efeito em ambiente controlado e confirme a função que ele atende antes de removê-lo.
Um recurso de atendimento, medição ou acessibilidade pode ter uma responsabilidade importante. A investigação deve esclarecer como preservar essa função. Desativar componentes indiscriminadamente pode melhorar um relatório e prejudicar o trabalho do visitante.
Faça um teste pequeno antes de ampliar a reforma
Considere um exemplo hipotético: a página de um serviço demora a mostrar sua imagem principal no celular. O relatório indica que o arquivo é solicitado tarde. A equipe suspeita que uma configuração de carregamento adiado, adequada a imagens fora da tela, foi aplicada também à imagem de abertura.
Um teste delimitado seria ajustar essa configuração em uma cópia autorizada, mantendo texto, layout e demais recursos. A equipe compararia a mesma página sob condições equivalentes e verificaria se a solicitação passou a começar antes.
Se a espera continuar, o resultado enfraquece a hipótese ou revela outra etapa do problema. Se diminuir, há evidência para considerar uma correção localizada. Em nenhum dos casos o teste demonstra automaticamente aumento de vendas.
Registre a alteração exata e evite misturar troca de hospedagem, novo layout e remoção de scripts no mesmo experimento. Quando tudo muda junto, fica difícil entender qual decisão resolveu a espera e qual introduziu uma falha.
Combine o aceite antes da implementação
Uma ficha de diagnóstico pode conter:
- Situação: página, dispositivo e tarefa afetada.
- Evidência: observação e relatório que mostram a dificuldade.
- Hipótese: explicação ainda sujeita a teste.
- Intervenção: mudança delimitada e responsável pela execução.
- Conferência: condições de comparação e tarefas que precisam continuar funcionando.
- Decisão: aplicar, investigar novamente ou ampliar o escopo, com justificativa.
Depois da correção, repita o teste e percorra a tarefa completa. Abra links, use o menu e confira o envio autorizado com dados demonstrativos. Melhorar o carregamento sem perceber que um formulário deixou de funcionar seria uma troca ruim.
Para dados reais do PageSpeed, considere que a janela cobre os 28 dias anteriores e é atualizada diariamente, conforme sua documentação. O histórico ainda pode misturar experiências anteriores e posteriores à mudança. Use a verificação técnica imediata para confirmar a implementação e acompanhe os dados de campo à medida que o período se renova.
Decida o escopo com o diagnóstico em mãos
Uma correção localizada faz sentido quando a causa está delimitada e a estrutura permite tratá-la sem prejudicar outras tarefas. Uma revisão mais ampla pode ser necessária quando os mesmos limites aparecem em várias páginas e os ajustes disponíveis não resolvem o uso prioritário. A equipe deve demonstrar essa restrição, em vez de deduzi-la da aparência antiga do site.
Se a solução exigir mudança de plataforma, leve o diagnóstico para o plano de migração do site. Preserve caminhos comerciais e critérios de recebimento dos contatos durante a troca.
A próxima conversa com o fornecedor pode começar com uma página, uma dificuldade reproduzível e uma pergunta: “Que evidência precisamos para decidir se basta corrigir este ponto?”. Essa preparação ajuda a contratar uma intervenção proporcional ao problema e a reconhecer quando ela realmente funcionou.
Referências
Filipe Ribeiro
Marketing, tecnologia e operação conectados ao que precisa funcionar. Experiência, critérios e fontes tratados com contexto.
Conheça minha atuação
