CLS de utilizadores reais (dados de campo)

O que esta verificação faz

Lê o percentil 75 do Cumulative Layout Shift a partir do Chrome User Experience Report — agregado numa janela contínua de 28 dias a partir de utilizadores reais do Chrome que aderiram. O CLS é adimensional; soma o impacto de cada movimento inesperado de layout durante a visita, limitado à janela de 5 segundos com maior atividade.

CLS de campo (p75)	Veredicto
≤ 0,10	Bom
0,10–0,25	Precisa de melhorias
> 0,25	Fraco

Porque é que o CLS de campo é diferente do CLS de laboratório:

• O CLS de laboratório corre uma vez. O Lighthouse carrega a página, espera alguns segundos e soma os deslocamentos.
• O CLS de campo corre durante a visita inteira. Os utilizadores reais fazem scroll, clicam e interagem durante minutos. Cada deslocamento conta — incluindo redes de anúncios que carregam tarde, imagens lazy-loaded, variantes A/B e widgets de recomendação que hidratam após o primeiro paint.

É por isso que o CLS de campo costuma ser pior do que o de laboratório, e por isso é que corrigi-lo exige pensar no percurso completo do utilizador, não apenas nos primeiros 5 segundos.

Porque é importante

O CLS é um dos três Core Web Vitals do Google e um sinal direto de ranking. Um CLS fraco não é só um problema de SEO — é um bug de usabilidade que piora quanto mais tempo o utilizador permanecer:

• Os utilizadores clicam no botão errado quando um anúncio empurra o conteúdo para baixo.
• Os formulários são submetidos com os valores errados quando um banner tardio desloca o layout.
• As taxas de conversão caem mensuravelmente acima de CLS 0,25 (o limiar do Google para “fraco”).

Se o teu CLS de campo é alto mas o de laboratório é bom, a falha está quase sempre em conteúdo que carrega depois do primeiro paint — e as ferramentas de laboratório não esperam o suficiente para o ver.

Como melhorar

1. Reserva espaço para tudo o que é assíncrono. Cada imagem, vídeo, embed, anúncio ou widget que carregue depois do primeiro paint precisa de dimensões explícitas antes de carregar:

<!-- Para imagens, inclui sempre width + height -->
<img src="/photo.jpg" width="600" height="400" alt="..." />

<!-- Para iframes (YouTube, Twitter), envolve num contentor com rácio fixo -->
<div style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/abc" width="100%" height="100%"></iframe>
</div>

<!-- Para slots de anúncios, declara o min-height em CSS antes do SDK carregar -->
<div class="ad-slot" style="min-height: 250px;"></div>

2. Evita injetar conteúdo por cima de conteúdo existente. Se tens mesmo de mostrar um banner de cookies, empurra-o para o fundo da página ou usa uma barra sticky no topo com position: fixed — nunca o injetes no fluxo do documento.

3. Usa font-display: optional (ou swap com um fallback cuidado). Webfonts que chegam tarde fazem o título saltar das métricas do fallback para as métricas da webfont. O descritor CSS size-adjust pode fazer com que o fallback coincida com a altura-x da webfont, tornando a troca invisível:

@font-face {
  font-family: "Inter-Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

4. Define transform em vez de top / left / margin para animações. Animações baseadas em transform não disparam layout, por isso não contribuem para o CLS.

5. Cuidado com tags <script> de ligação tardia que mutam o DOM. Ferramentas de personalização, GTM, Hotjar, Intercom — todos infratores comuns. Se um script de terceiros injeta um elemento acima da dobra depois de a página ter sido renderizada, isso é CLS.

6. Testa com extensões ativadas. As ferramentas de laboratório correm um navegador limpo; os utilizadores reais têm bloqueadores de anúncios que removem os placeholders, deixando layouts colapsados que depois voltam a deslocar-se. Reserva espaço com CSS que sobreviva à manipulação do DOM pelos bloqueadores de anúncios.

Perguntas frequentes

O meu CLS é ótimo em desenvolvimento mas fraco em produção. Porquê?

Produção tem coisas que dev não tem: inventário real de anúncios, variantes A/B reais, widgets de recomendação reais, personalização real. Configura a API do CrUX ou a biblioteca JS web-vitals para medir ao vivo em produção — npm i web-vitals e chama onCLS(reportFn) para registar deslocamentos em direto.

Os deslocamentos de layout por input do utilizador são contados?

Não. O CLS só conta deslocamentos inesperados — qualquer coisa nos 500 ms a seguir a um clique, toque ou tecla do utilizador é excluída. Por isso, um separador que abre um acordeão não conta, mesmo que visivelmente desloque conteúdo.

E os links âncora que fazem a página saltar?

Os scrolls por âncora não são contados como CLS — a especificação exclui qualquer deslocamento que aconteça durante um scroll programático. Se o teu CLS está misteriosamente alto, os saltos por âncora não são a causa.