Olhe dados reais, não só uma nota verde
Se o Lighthouse mostra 95, mas as pessoas dizem que o site é lento, eu não confio em uma única nota verde. Primeiro olho grupos reais de URL no Search Console e depois acho o culpado no PageSpeed e no DevTools.
O erro que eu eliminaria primeiro: Aplicar lazy-load na imagem hero.
O que preparar e que resultado esperar
- Resultado: Você sabe qual recurso ou script deixa a página lenta e pode verificar a correção com dados de campo, não só com teste de laboratório.
- Abra Search Console → Core Web Vitals e separe Mobile/Desktop. Para a URL problemática, rode PageSpeed Insights.
- Mantenha os dados de origem e os direitos de acesso separados do resultado para poder verificar o que o trabalho de velocidade e Core Web Vitals realmente fez.
- Metas de bom resultado: LCP abaixo de 2,5 s, INP abaixo de 200 ms e CLS abaixo de 0,1. Depois da correção, clique em start validation no Search Console.
Ache o problema principal e corrija um de cada vez
- Encontre a URL problemática
No Search Console abra o grupo do problema e depois a URL específica. Cole no PageSpeed Insights e veja qual é o elemento LCP.
Проверьте: Fica claro o que o usuário espera por mais tempo.
Если не сработало: Verifique a página no Chrome DevTools Performance com perfil mobile.
- Corrija a primeira tela
Comprima a imagem hero, defina dimensões e não aplique lazy-load no visual principal. Adie widgets secundários e scripts de terceiros.
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Técnico consertando um ar-condicionado">Проверьте: O visual principal aparece sem esperar JS pesado.
Если не сработало: Substitua vídeo/animação por um primeiro frame estático no teste.
- Remova saltos e long tasks
Defina width/height para imagens e iframes, reserve espaço para banners, corte JavaScript pesado e quebre long tasks.
Проверьте: Em tela mobile, os elementos não saltam durante o carregamento.
Если не сработало: Desative widgets de terceiros um a um e encontre o culpado.
- Teste um cenário real
No DevTools ative CPU lenta e rede mobile, recarregue a página e grave Performance. Compare antes e depois na mesma URL.
Проверьте: A correção melhorou a métrica necessária, não só a pontuação geral.
Если не сработало: Reverta a última mudança e teste isoladamente.
Corrijo primeiro o elemento LCP
Metas para um bom resultado: LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1. Se o LCP é a imagem hero, não defina `loading=lazy`: coloque dimensões, formato moderno e `fetchpriority=high`. Imagens abaixo da primeira tela, por outro lado, devem carregar de forma lazy.
Para CLS, reserve espaço para imagens, vídeo, iframes, chat e o banner de cookies. Para INP, abra DevTools → Performance e procure long tasks: chats, mapas, sliders e vários widgets de analytics ao mesmo tempo.
<img src="/assets/hero.avif" width="1440" height="900" fetchpriority="high" alt="Equipe trabalhando em um processo">Não confunda o laboratório com usuários reais
Registre URL, dispositivo, fonte de dados, LCP, INP e CLS antes da mudança. Depois da correção, confira de novo PageSpeed e DevTools na mesma URL e espere os dados de campo do Search Console atualizarem. Se você só arruma a nota e deixa um formulário lento ou um botão que salta, o usuário não terá uma experiência melhor.
- Desative widgets de terceiros um a um primeiro.
- Não aplique lazy-load no visual principal.
- Não trate dados mobile e desktop como uma única métrica.
Um teste — um culpado
Primeiro desative um widget de terceiros, meça de novo e registre o resultado. Depois restaure e confira o próximo. Não reescreva o frontend inteiro de uma vez: senão você volta à versão antiga e ainda não sabe a causa.
Para cada grupo de URL armazene `metric`, `device`, `source`, `before`, `after`, `change`, `owner` e `date`. Se o problema principal for um hero pesado, otimize-o; se for INP, corte JavaScript. Não corrija CLS trocando fonte se o salto vem de um espaço de anúncio.
LCP, INP e CLS: o que verificar exatamente
| Critério | Pergunta | Bom sinal |
|---|---|---|
| Entrada | O que exatamente entra no trabalho de velocidade e Core Web Vitals? | Abra Search Console → Core Web Vitals e separe Mobile/Desktop. Para a URL problemática, rode PageSpeed Insights. |
| Ação | O que o sistema tem permissão de fazer sozinho? | Somente ações listadas de antemão, sem acesso a toda a conta |
| Verificação | Como saber que o resultado pode ser aceito? | Metas de bom resultado: LCP abaixo de 2,5 s, INP abaixo de 200 ms e CLS abaixo de 0,1. Depois da correção, clique em start validation no Search Console. |
| Falha | Para onde vai um caso pouco claro? | Compare Field data e Lab data e depois corrija o único recurso mais pesado; não mude CDN, fonte e todo o JavaScript de uma vez. |
O que deve mudar depois da configuração
Você sabe qual recurso ou script deixa a página lenta e pode verificar a correção com dados de campo, não só com teste de laboratório.
Quais acelerações atrapalham a primeira tela por acidente
Aplicar lazy-load na imagem hero.
Corrigir só a nota de laboratório e ignorar dados reais.
Esquecer dimensões de imagens e iframes.
Adicionar mais um widget quando a primeira tela já está sobrecarregada.
Quando velocidade exige trabalho de arquitetura
Você precisa de um especialista se os pontos lentos envolvem CMS, renderização no servidor, um bundle JS grande ou vários sistemas externos.
O que verificar depois da otimização
Por que PageSpeed e Search Console mostram números diferentes?
O PageSpeed combina teste de laboratório com dados de campo disponíveis, enquanto o Search Console usa visitas reais agregadas em um período.
É preciso pontuação 100?
Não. Importam mais o desempenho estável das páginas-chave e boas métricas reais nos dispositivos dos clientes.
O que corrigir primeiro?
O que afeta o conteúdo principal e a primeira tela; depois saltos de layout e long tasks interativas.
Quando o resultado aparece no Search Console?
Dados de campo não atualizam na hora. Um teste de laboratório verifica a mudança imediatamente; o relatório real precisa acumular novas visitas.
