Core Web Vitals: o que move realmente os números
Os Core Web Vitals são três medições de campo sobre como uma página se sente: quanto demora a aparecer o conteúdo principal, quanto ele salta durante o carregamento, e com que rapidez a página responde ao toque.
Este guia cobre o que cada métrica mede, as causas concretas de más pontuações, e as correções que movem dados de campo em vez de moverem apenas pontuações de laboratório.
O que as três métricas medem#
Cada uma tem um limiar de «bom» e um pequeno conjunto de causas habituais. Note que o número que conta para posicionamento são os dados de campo de visitantes reais, não uma pontuação obtida no seu portátil.
| Métrica | Bom | Mede | Causa habitual de má pontuação |
|---|---|---|---|
| LCP | Abaixo de 2,5 s | Tempo até desenhar o maior elemento visível | Imagem principal por otimizar, servidor lento, CSS bloqueante |
| CLS | Abaixo de 0,1 | Quanto a disposição salta ao carregar | Imagens sem dimensões, banners inseridos, tipos que chegam tarde |
| INP | Abaixo de 200 ms | Rapidez de resposta à interação | Tarefas longas de JavaScript a bloquear a thread principal |
As ferramentas de laboratório medem um carregamento numa máquina. Os dados de campo são o percentil 75 de visitas reais, incluindo telemóveis antigos em redes más — precisamente os visitantes que desistem mais depressa.
Corrigir o LCP#
O LCP é quase sempre uma imagem ou um título bloqueado por outra coisa. Percorra estes pontos por ordem; os dois primeiros resolvem a maioria dos sites.
- Identifique qual é realmente o elemento LCP nos dados de campo. Otimizar a imagem errada é o desperdício mais comum.
- Nunca carregue a imagem do LCP de forma diferida. Dê-lhe fetchpriority="high".
- Sirva-a em formato moderno, no tamanho em que é apresentada, com srcset para ecrãs menores.
- Pré-carregue o tipo de letra do texto do LCP e use font-display: swap.
- Retire CSS e JavaScript bloqueantes do head; incorpore o CSS crítico se a página for pequena.
- Reduza o Time to First Byte com cache e CDN — nenhum trabalho de front-end compensa um servidor lento.
- Corte scripts de terceiros do caminho crítico. Cada um é uma resolução de DNS, uma ligação e um ficheiro imprevisível.
Corrigir o CLS#
O salto de disposição é quase inteiramente evitável e as correções são baratas. É também a métrica que os visitantes mais sentem, porque é o que os faz tocar na coisa errada.
- Defina width e height em todas as imagens e vídeos para o navegador reservar espaço.
- Reserve espaço para anúncios, incorporações e iframes com um contentor de proporção fixa.
- Nunca insira conteúdo por cima de conteúdo existente depois do carregamento — o aviso de cookies deve ficar em baixo ou em sobreposição.
- Ajuste as métricas do tipo de recurso ao tipo web, ou use size-adjust, para que a troca não reorganize a página.
- Evite animar propriedades de disposição. Anime transform e opacity, que não forçam recálculo.
- Dê min-height às secções carregadas dinamicamente para não expandirem a partir do zero.
Corrigir o INP#
O INP substituiu o First Input Delay e é mais difícil, porque mede todas as interações da visita e não apenas a primeira. Mau INP é quase sempre JavaScript a mais na thread principal.
| Causa | Correção |
|---|---|
| Pacote grande processado ao carregar | Dividir código; carregar só o que a página usa |
| Tarefas longas acima de 50 ms | Partir o trabalho e devolver a thread |
| Manipuladores de eventos caros | Aplicar debounce e tirar trabalho pesado do caminho de interação |
| Etiquetas de terceiros pesadas | Carregar após interação, ou remover — verifique o que cada uma dá |
| DOM grande, acima de 10 000 nós | Virtualizar listas longas; simplificar aninhamento profundo |
| Leituras e escritas alternadas no layout | Agrupar leituras e escritas em vez de alternar |
Em sites de conteúdo, a intervenção mais valiosa no INP costuma ser remover JavaScript em vez de o otimizar. Pergunte o que cada script traz; os gestores de etiquetas acumulam scripts que ninguém se lembra de ter acrescentado.
Perguntas frequentes
Quanto pesam os Core Web Vitals no posicionamento?
São um sinal real mas modesto, que funciona mais como desempate do que como substituto de relevância. Uma página rápida sobre o assunto errado não vence uma página mais lenta que responde à pergunta. O argumento mais forte para os corrigir é comportamental: páginas lentas e instáveis perdem visitantes antes de o posicionamento sequer entrar em jogo.
Porque tenho boa pontuação no Lighthouse e maus dados de campo?
Porque o Lighthouse simula um carregamento na sua máquina e com a sua ligação, e os dados de campo são o percentil 75 de visitas reais — incluindo telemóveis de três anos em redes congestionadas. Quando os dois se contradizem, os dados de campo é que contam. Use o laboratório para diagnosticar, não para pontuar.
Tenho de corrigir as três métricas?
Corrija as que estão a falhar, pela ordem do que os seus visitantes sentem. O CLS costuma ser o mais barato de resolver e o mais irritante para quem usa, por isso é um bom ponto de partida. O LCP tem o maior efeito sobre se as pessoas esperam. O INP pesa mais em sites interativos e menos em artigos estáticos.
Quanto tempo até as melhorias aparecerem?
Os dados de campo são uma janela deslizante de 28 dias, por isso movimento significativo demora cerca de quatro semanas depois de a correção chegar a todos os visitantes. Não avalie uma alteração ao fim de três dias. Verifique de imediato os valores de laboratório para confirmar que a correção fez o que esperava.
core web vitalslcpclsinpvelocidade páginadesempenho web
