Lentidão não é um problema único. O servidor pode demorar, a imagem principal começar tarde, um script bloquear a interação ou um banner mover o botão durante o toque. Cada falha pede evidência e correção próprias.
Comece por página, dispositivo e ação importantes. Uma página inicial rápida no desktop não prova rapidez do produto ou pagamento móvel. Testes diferentes podem atribuir uma variação à causa errada.
Escopo desta auditoria
O que pode ser medido
- Desempenho público via PageSpeed Insights, laboratório Lighthouse e métricas CrUX quando fornecidas.
- Estratégia móvel ou desktop, URL medida, oportunidades, diagnósticos e evidências por métrica disponíveis.
O que ela não comprova
- Um teste de laboratório é amostra controlada. Dados de campo podem faltar ou representar toda a origem.
- Local Agent utiliza método local limitado próprio, não Lighthouse hospedado ou CrUX.
Acesso depende do plano e disponibilidade do provedor. Dados ausentes aparecem como indisponíveis, sem medições inventadas.
1. Leia laboratório e campo de modo diferente
Lighthouse executa um cenário repetível de diagnóstico. CrUX agrega experiências reais elegíveis quando há dados suficientes. Público, dispositivos, rede e janelas distintas podem explicar divergências. A documentação do PageSpeed Insights explica ambas as fontes.
Leia a origem de cada métrica: um valor pode vir do campo e outro do laboratório. Confira se os dados descrevem a URL exata ou toda a origem. Falta de campo significa amostra ausente, não reprovação em Core Web Vitals nem ausência de visitantes.
2. Entenda os três Core Web Vitals
| Métrica | O que descreve | Limite bom de referência |
|---|---|---|
| LCP | Exibição do maior elemento visível de conteúdo | 2,5 segundos ou menos |
| INP | Resposta às interações | 200 milissegundos ou menos |
| CLS | Movimento inesperado do layout | 0,1 ou menos |
No campo, os limites se aplicam ao percentil 75 das visitas, separando categorias de dispositivo. Consulte Web Vitals. Um valor de laboratório não comprova aprovação de campo. Time to First Byte e First Contentful Paint ajudam no diagnóstico, mas não são Core Web Vitals adicionais.
3. Relacione sintomas e evidências
As prioridades são ilustrativas. O impacto sobre uma tarefa essencial importa mais que o título de um diagnóstico.
| Sintoma | Prioridade contextual | Evidência |
|---|---|---|
| Conteúdo principal aparece tarde | Alta se atrasa entender a oferta | Elemento LCP, resposta e requisições |
| Compra responde lentamente | Alta para conversão | Traço de interação e tarefas longas |
| Conteúdo se move sob o ponteiro | Alta se provoca ações acidentais | Elementos deslocados e dimensões reservadas |
| Script grande sem uso | Média até medir custo real | Bytes, execução e utilização |
Estimativa de economia não é garantia. Sugestões podem sobrepor custos; recurso pesado pode ser necessário. Confirme o gargalo antes de excluir funções ou trocar infraestrutura.
4. Corrija o componente que gera o atraso
Conteúdo tardio: encontre primeiro o elemento LCP. Se o servidor demora, investigue backend e cache. Se a imagem principal é descoberta tarde, deixe-a acessível cedo no documento e evite carregamento preguiçoso dessa imagem inicial. Sirva tamanho apropriado. O guia LCP separa as fases.
Interação lenta: procure manipuladores caros, renderização síncrona e trabalho de terceiros. Divida tarefas longas e reduza trabalho desnecessário. Total Blocking Time ajuda no laboratório, mas não é INP. Use o guia INP com uma gravação real de interação.
Movimento: reserve espaço para imagens, incorporações e banners antes que cheguem. A solução depende do elemento que se desloca e da causa.
5. Compare antes e depois com controle
- Registre URL, estratégia, momento e fonte.
- Aplique mudança coerente ligada ao gargalo observado.
- Repita testes comparáveis e avalie tendência, não o melhor resultado.
- Confira visualmente e conclua a interação principal.
- Verifique outro modelo que compartilhe o componente.
- Observe campo depois: uma janela agregada não reflete um lançamento imediatamente.
Guarde diagnóstico, não só captura da nota. Se uma imagem carrega mais rápido mas desloca o layout, a correção está incompleta. Confira telas estreitas e conteúdo tardio, como avisos de cookies, fontes e widgets.
6. Reconheça os limites do teste
Uma navegação não exercita todos os estados de uma aplicação complexa. A página pode carregar rápido e reagir mal após longa edição. Laboratório pode usar consentimento, conta ou conteúdo diferentes do cliente real.
Sitelemetry informa estratégia e fontes disponíveis. Local Agent verifica entrega local por outro método limitado; não compare sua nota diretamente com Lighthouse público. Se PageSpeed estiver indisponível, resolva ou repita a medição em vez de interpretar o campo vazio como zero. As provas devem mostrar o que realmente executou.
7. Inclua velocidade no trabalho do produto
Defina orçamentos para modelos e ações sob seu controle: peso de imagens, scripts de terceiros e processamento do cliente. Ao adicionar chat, analítica ou animação, teste antes e depois em vez de presumir custo zero.
Preserve funcionamento, acessibilidade e velocidade juntos. Um formulário estável que comunica progresso vale mais que uma boa nota obtida escondendo conteúdo. Priorize a página móvel comercial, execute o teste disponível e escreva uma tarefa com aceitação mensurável. Associe acessibilidade e integrações se o mesmo componente afeta as três áreas.
Perguntas frequentes
Por que duas execuções dão notas diferentes?
Rede, carga, cache e variabilidade do laboratório influenciam. Compare mesma URL e dispositivo em vários testes equivalentes e observe métricas.
Sem CrUX significa site lento?
Não. Faltam dados de campo elegíveis para o escopo. Use laboratório para diagnóstico sem declarar aprovação ou reprovação de campo.
TBT é igual a INP?
Não. TBT diagnostica trabalho bloqueante em laboratório; INP descreve resposta durante interações dos usuários.
Fontes e leituras
- Google: sobre PageSpeed Insightsdevelopers.google.com
- web.dev: Web Vitalsweb.dev
- web.dev: otimizar Largest Contentful Paintweb.dev
- web.dev: otimizar Interaction to Next Paintweb.dev
Preparado pela equipe Sitelemetry e conferido com o escopo do produto e as fontes primárias citadas. Os exemplos são ilustrativos, salvo quando um caso observado é identificado.
