A nota do PageSpeed caiu, o cliente reclamou do celular e a primeira reação foi instalar uma ferramenta de otimização. Antes de mudar várias configurações, descubra qual tarefa está lenta e o que as medições mostram. Um arquivo pesado pode ser parte do problema, mas também há atrasos de servidor, recursos de terceiros e conteúdo que aparece fora de ordem. Um diagnóstico pequeno e repetível ajuda a escolher a primeira mudança e verificar se ela realmente melhorou a experiência.
Defina a página, o sintoma e a comparação
“O site está lento” reúne situações diferentes. A tela demora a mostrar o conteúdo principal? O menu demora a responder? A página salta enquanto você tenta clicar? Peça ao cliente endereço, aparelho, momento e ação realizada. Tente reproduzir a experiência, sem concluir que a reclamação é inválida porque o site abriu rapidamente na sua conexão.
Escolha páginas representativas: inicial, serviço importante e contato, por exemplo. Registre a versão publicada e as condições observadas. Evite comparar uma página de galeria com uma página quase vazia como se fossem a mesma tarefa. O diagnóstico precisa acompanhar o conteúdo que o visitante realmente encontra.
A documentação do PageSpeed Insights distingue dados de campo, quando disponíveis, e testes de laboratório. Os primeiros representam experiências reais agregadas em uma janela anterior de 28 dias. Os segundos executam uma avaliação simulada. Uma correção feita hoje pode aparecer no teste de laboratório antes de ficar refletida integralmente nos dados de campo.
Confira ainda se o relatório de campo corresponde à página ou à origem inteira. Quando faltam amostras suficientes, pode não haver dados reais disponíveis. Isso não significa que a página seja rápida ou lenta. Significa que você precisa reconhecer a limitação e trabalhar com as outras evidências.
Faça algumas execuções comparáveis para perceber a variação. Use o mesmo endereço e o mesmo tipo de avaliação, registrando os resultados em vez de escolher somente a melhor nota. Essa repetição não produz uma pesquisa estatística completa, mas ajuda a evitar conclusões baseadas em um teste excepcional.
Leia o problema que aparece por trás da pontuação
A pontuação resume diferentes aspectos e pode variar. Para decidir uma ação, olhe também as métricas, os elementos destacados e o que você observou navegando. Um carregamento visual demorado e um clique que não responde pedem investigações diferentes. Não adote a regra de que qualquer resultado ruim se resolve reduzindo fotos.
O LCP se relaciona à apresentação do maior conteúdo visível na área inicial, que pode ser imagem ou texto. O INP observa a resposta às interações nos dados pertinentes. O CLS se relaciona a mudanças inesperadas de posição. Esses indicadores ajudam a nomear problemas, mas o relatório não explica sozinho toda a causa.
Imagine um site fictício de fotografia. A imagem principal demora a aparecer, enquanto a galeria inferior continua carregando. O relatório destaca essa imagem na análise do carregamento. Uma hipótese é que seu peso ou sua prioridade estejam contribuindo. Já um botão que responde lentamente depois da página pronta pode envolver execução de código, exigindo outra investigação.
Liste hipóteses em ordem de evidência e de risco da mudança. “A imagem principal usa um arquivo muito maior que o necessário” pode ser verificada. “A hospedagem é ruim” exige informações adicionais. Começar por uma alteração compreensível e reversível permite aprender algo, em vez de acumular configurações que ninguém consegue explicar.
Se os recursos relevantes não estão sob seu controle, prepare um pedido técnico ao fornecedor. Inclua endereço, relatório, horário, comportamento e alteração recente. Não prometa acesso a cache, servidor ou código em uma plataforma gerenciada sem conferir as possibilidades do serviço.
O quadro ajuda a escolher a próxima investigação. As hipóteses precisam de evidência; não são diagnósticos automáticos.
| Sintoma observado | Hipótese inicial | O que verificar antes de mudar |
|---|---|---|
| Imagem principal demora | Arquivo ou descoberta tardia | Recurso efetivo e prioridade de carregamento |
| Botão responde com atraso | Trabalho de código na interação | Tarefa, aparelho e scripts envolvidos |
| Conteúdo empurra o botão | Espaço não reservado | Elemento que desloca o layout |
| Laboratório melhorou; campo não | Janela histórica ou recorte distinto | Datas, URL, origem e amostra |
Guarde o relatório anterior e o arquivo publicado antes de substituir a imagem. Depois da mudança, confira se cache ou transformação automática ainda entregam a versão antiga. Sem essa confirmação, você pode comparar duas medições da mesma página e atribuir a variação a uma alteração que o navegador não recebeu. Se o arquivo novo está ativo e o sintoma persiste, revise a hipótese em vez de comprimir repetidamente. O gargalo pode estar antes da transferência da imagem ou em outra parte do caminho de renderização.
Trate a imagem certa com uma sequência de verificação
Comece identificando o arquivo realmente entregue ao navegador e como ele aparece na página. A imagem enviada ao painel pode ser transformada automaticamente pelo serviço. Por outro lado, reduzir sua largura visual no editor pode não reduzir o arquivo transferido. A documentação do web.dev sobre desempenho de imagens ajuda a reconhecer o papel do tamanho e da entrega desses recursos.
No exemplo fictício, a foto original tem quatro mil pixels de largura e aproximadamente três megabytes. Você prepara uma versão adequada ao espaço e aos dispositivos previstos, preserva o original e testa outra combinação de dimensões, formato e compressão. Uma opção chega a 220 kilobytes. Esses números são ilustrativos, não uma meta universal para todas as imagens.
A comparação precisa incluir qualidade. Observe detalhes, gradientes, textos que eventualmente existam na imagem e recorte no celular. Uma fotografia de trabalho pode perder informação importante se a compressão for agressiva. Se houver transparência ou outro requisito visual, confira a compatibilidade do formato escolhido com o resultado necessário e com a plataforma.
- Guarde o original e identifique qual versão será publicada.
- Escolha dimensões segundo o uso real e a forma de entrega do serviço.
- Compare formatos e compressão com inspeção visual.
- Substitua a imagem em uma versão que possa ser conferida.
- Verifique no site publicado se o arquivo novo está sendo utilizado.
- Repita o teste e confira a navegação, não apenas o tamanho do arquivo.
Não envie imagens privadas de clientes a qualquer compressor online. Avalie a ferramenta, os dados envolvidos e a autorização necessária. Para demonstrações, use arquivos próprios ou licenciados sem informação sensível. A conveniência da otimização não elimina responsabilidades sobre o conteúdo.
Evite soluções automáticas que atrasam o que deveria aparecer primeiro
Carregar imagens sob demanda pode ajudar em partes que só serão vistas depois, mas aplicar a mesma regra indiscriminadamente pode prejudicar a imagem principal. O guia do web.dev para otimizar LCP alerta contra o carregamento tardio da imagem responsável por esse indicador. Verifique o elemento efetivo e os controles disponíveis antes de ativar opções em lote.
Também observe se a página reserva espaço para as imagens. Quando o conteúdo chega e empurra o botão que a pessoa tentava acionar, o problema afeta o uso. A orientação sobre CLS apresenta causas e formas de reduzir mudanças inesperadas de layout. A solução precisa ser aplicada ao componente correto, não apenas à foto mais pesada.
No site fictício, a nova imagem ficou menor, mas o espaço da galeria continua mudando durante o carregamento. Você registra dois problemas distintos: o primeiro teve uma melhoria verificada; o segundo ainda precisa de correção. Evite declarar “desempenho resolvido” porque um único número melhorou.
Recursos externos também merecem inventário: vídeos incorporados, mapas, animações e scripts comerciais podem participar do carregamento. Antes de remover algo, confirme sua finalidade e quem autorizou a inclusão. Um formulário ou medidor contratado não deve desaparecer apenas para elevar a nota. Avalie alternativas e teste o efeito junto da necessidade do negócio.
Não ative várias ferramentas de cache ou modificação de scripts ao mesmo tempo sem entender a combinação. Alterações desse tipo podem afetar funções. Trabalhe em ambiente apropriado, preserve uma forma de recuperação e encaminhe o que exceder seu conhecimento. Uma otimização que interrompe os contatos não é uma entrega bem-sucedida.
Compare antes e depois e entregue uma conclusão proporcional
Suponha que três testes de laboratório, no cenário fictício, tenham mostrado LCP de 5,8, 6,0 e 6,2 segundos. Depois de uma alteração, os resultados foram 4,0, 4,1 e 4,2 segundos. Você pode registrar a diferença observada nessa sequência comparável. Não pode afirmar que todos os visitantes passaram a ver exatamente 4,1 segundos nem que a mudança aumentou vendas.
Confira também as outras métricas e a tarefa principal. Uma melhoria em carregamento não deve esconder uma piora de estabilidade ou um botão quebrado. Repita o formulário e a navegação que fazem parte da entrega. Se houve uma mudança adicional entre os testes, registre-a para não atribuir todo o efeito à imagem.
O relatório ao cliente pode ser curto: sintoma, evidências, alteração realizada, resultados comparáveis e pendências. Diga quando não houve dados de campo suficientes ou quando a investigação depende do fornecedor. Essa precisão é mais útil que uma captura da melhor pontuação acompanhada de uma promessa de velocidade absoluta.
Por fim, transforme a correção em orientação de publicação. Combine como preparar novas imagens e quais recursos precisam de avaliação antes de entrar. Repita medições quando o conteúdo ou a estrutura mudar de forma relevante. O objetivo é manter tarefas utilizáveis e detectar regressões, sem transformar a busca por uma nota perfeita em trabalho sem fim.
