O que é Cumulative Layout Shift (CLS) e como corrigi-lo

O guia definitivo para encontrar, medir e corrigir o Cumulative Layout Shift do seu site

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03

Cumulative Layout Shift (CLS) em resumo

Cumulative Layout Shift (CLS) é uma Core Web Vital que mede a estabilidade visual de uma página web. Ela quantifica quanto do conteúdo visível se move inesperadamente durante o ciclo de vida da página, usando a fórmula: fração de impacto multiplicada pela fração de distância. Uma boa pontuação de CLS é inferior a 0,1, enquanto pontuações acima de 0,25 são consideradas ruins. Pelo menos 75% das visitas à página devem ter pontuação "boa" para ser aprovada.

Cumulative Layout Shift (CLS) é uma métrica centrada no usuário que mede a estabilidade visual de uma página web. Ela rastreia com que frequência e quanto o conteúdo de uma página se move enquanto carrega. Mudanças de layout podem ser frustrantes para os usuários, pois podem levar a cliques acidentais, formatação quebrada da página e uma experiência geralmente confusa.

Desde 2020, o Cumulative Layout Shift (CLS) é uma das três métricas Core Web Vitals. O CLS representa a parte de estabilidade visual das Core Web Vitals e determina quão estável o conteúdo principal da página web é durante todo o seu ciclo de vida.

Em termos simples: uma boa pontuação de CLS garante uma experiência visualmente estável!

Como Corrigir o Cumulative Layout Shift (CLS)

O que é Cumulative Layout Shift (CLS)?

Cumulative Layout Shift (CLS) representa a parte de "estabilidade visual" das Core Web Vitals. O Cumulative Layout Shift (CLS) mede os movimentos da página conforme o conteúdo é renderizado ou novo conteúdo é exibido na página. Ele calcula uma pontuação com base em quanto da página está se movendo inesperadamente e quão longe ela se move. Essas mudanças de conteúdo são muito irritantes, fazendo você perder seu lugar em um artigo que começou a ler ou, pior ainda, fazendo você clicar no botão errado!

O que é uma boa pontuação de Cumulative Layout Shift (CLS)?

Uma boa pontuação de CLS é qualquer valor entre 0 e 0,1. Se sua pontuação de CLS estiver entre 0,1 e 0,25, ela precisa de melhorias. Qualquer pontuação de CLS acima de 0,25 é considerada ruim. Para passar nas Core Web Vitals para o Cumulative Layout Shift, pelo menos 75% dos seus visitantes precisam ter uma pontuação de CLS "boa".

Importância do CLS no desempenho web e user experience

Cumulative Layout Shift (CLS) está ligado tanto ao desempenho web quanto à user experience porque impacta diretamente o quão estável e previsível uma página web parece enquanto carrega. Veja por que isso importa:

  • UX, engajamento e percepção da marca: Mudanças de layout inesperadas interrompem o fluxo do usuário, tornando mais difícil encontrar informações, clicar em botões e interagir com a página como pretendido. Essa frustração pode levar a experiências ruins onde os usuários abandonam o site completamente. A user experience de um site reflete a marca por trás dele. Mudanças de layout frequentes podem dar a impressão de um site mal projetado ou mantido, interromper o engajamento do usuário e levar à diminuição da interação e potencialmente maiores taxas de rejeição.
  • Acessibilidade: Mudanças de layout podem ser particularmente perturbadoras para usuários com deficiências que dependem de tecnologias assistivas ou leitores de tela. Um layout estável garante que todos possam navegar e interagir com o site de forma eficaz.
  • SEO e Ranking de Busca: As Core Web Vitals são um fator de ranking pequeno, mas significativo no Google. O Google, junto com outros motores de busca, prioriza sites que oferecem uma boa user experience. O CLS é uma das métricas Core Web Vitals que o Google considera ao classificar sites. Otimizar para CLS pode dar ao seu site uma vantagem competitiva nos resultados de busca.

Como o CLS é medido?

O CLS de uma página pode ser medido com a Layout Instability API. A seguir está um uso simples desta API:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Calculando o CLS

O CLS é calculado usando uma fórmula simples, porém elegante:

CLS = sum(impact-fraction * distance-fraction)

A fração de impacto mede quanto do conteúdo visível da página mudou. A fração de distância mede quão longe o conteúdo mudou. Se, por exemplo, 50% da página (quanto) mudou 25% (quão longe) da viewport da página, a pontuação de CLS = 0,50 * 0,25 = 0,125.

Mudanças de layout esperadas vs. inesperadas

Nem todas as mudanças de layout são ruins, apenas as que você não espera. Quando você clica em um link "carregar mais itens", por exemplo, você esperaria que mais itens aparecessem na página e que o conteúdo da página mudasse.

É por isso que apenas mudanças de layout inesperadas causam contribuição ao CLS. Por exemplo, se um usuário clica em um botão e, em resposta, novo conteúdo é adicionado à página (por exemplo, um menu dropdown), a mudança de layout será excluída do CLS. Para ser preciso: mudanças de layout que ocorrem dentro de 500 milissegundos de interação do usuário serão excluídas dos cálculos.

Sessões de mudança de layout

Quando o CLS foi introduzido pela primeira vez, alguns sites eram injustamente penalizados com uma pontuação de CLS ruim. Por exemplo, uma página que implementa scroll infinito teria o impacto do conteúdo recém-adicionado somado à pontuação total de CLS para cada novo scroll. É por isso que o CLS agora é calculado em sessões. Cada sessão tem uma duração máxima de 5 segundos e um intervalo de 1 segundo entre mudanças de layout. A sessão com a maior pontuação de CLS se tornará a pontuação final de CLS.

Se, por exemplo, durante a primeira sessão a pontuação de CLS é 0,095, na próxima sessão o CLS é 0,15, e na última sessão a pontuação de CLS é 0, a pontuação final de CLS será a maior das três: 0,15.

CLS e as Core Web Vitals

Cumulative Layout Shift (CLS) é uma métrica importante e centrada no usuário para medir a estabilidade visual. O Cumulative Layout Shift (CLS) faz parte das Core Web Vitals junto com o Largest Contentful Paint (LCP) e o Interaction to Next Paint (INP). Juntas, essas três métricas medem desempenho de carregamento, interatividade e estabilidade visual.

Como medir problemas de CLS

1. Use o Lighthouse para encontrar Cumulative Layout Shifts

O método mais fácil para encontrar mudanças de layout é usando o Lighthouse no seu próprio navegador Chrome. Basta executar uma auditoria do Lighthouse clicando com o botão direito em qualquer lugar da página. Em seguida, selecione inspecionar elemento, selecione a aba Lighthouse no console aberto e execute a auditoria.

Os resultados da auditoria mostrarão a pontuação de Cumulative Layout Shift (CLS). Role para baixo até Diagnósticos e expanda as informações de Cumulative Layout Shift para ver quais nós estão causando a mudança de layout.

Para ser honesto, eu nunca uso esse método. A falta de detalhes sobre a distância exata da mudança de layout torna esses resultados mais difíceis de interpretar.

2. Use o CLS Visualizer para encontrar Cumulative Layout Shifts

O CLS Visualizer é uma extensão do Chrome escrita por mim. Com um único clique de botão, todas as mudanças de layout na página são visualizadas. Esta é a primeira solução que uso quando tento determinar uma mudança de layout em uma página. É fácil e dará uma ótima visão geral visual do Cumulative Layout Shift.

3. Use a aba Performance do Chrome para encontrar CLS

De longe, a melhor maneira de depurar uma mudança de layout é através da aba Performance do Chrome. Para abrir a aba de performance, navegue para qualquer página no Chrome e use esta combinação de atalhos:

  • Pressione Ctrl+Shift+I (Abrir Dev Tools)
  • Pressione Ctrl+Shift+E (Iniciar profiling e recarregar página)

Agora inspecione o timeline quadro a quadro passando o mouse sobre o timeline no topo e procure mudanças de layout (mudanças de layout também são coloridas em vermelho na seção Experience da aba Performance).

4. Use ferramentas RUM como Core/Dash

RUM significa Real User Monitoring e os dados de RUM podem fornecer insights valiosos em tempo real sobre as Core Web Vitals. Ferramentas RUM como Core/Dash podem detalhar os Cumulative Layout Shifts em segmentos como navegador, elemento, tipo de navegação, URL específica ou tipo de página. Isso ajudará a identificar e corrigir páginas com desempenho ruim e elementos problemáticos.

Causas comuns de Cumulative Layout Shift e como corrigi-las

A origem de todas as mudanças de layout é basicamente a mesma. Em algum momento, um elemento que foi posicionado acima de outro elemento ocupou mais ou menos espaço do que antes. Isso normalmente se deve a uma ou mais dessas causas:

  • Imagens, iframes ou vídeos sem dimensões explícitas
  • Anúncios carregando tardiamente na viewport
  • Conteúdo injetado dinamicamente
  • Animações CSS usando propriedades que acionam o layout
  • Interações lentas do usuário
  • Fontes web com fallbacks incompatíveis

CLS causado por imagens, vídeos e iframes

Imagens, vídeos e iframes são os suspeitos habituais quando se trata de Cumulative Layout Shift, pois esses elementos compõem a maioria dos problemas de CLS. Para um guia detalhado sobre esta causa específica, veja como corrigir mudança de layout causada por imagens de dimensionamento automático.

Mudanças de layout causadas por imagens, vídeos ou iframes são sempre causadas por dimensões ausentes. Mais comumente, isso ocorre porque a altura e largura do elemento não estão definidas no HTML. Um padrão comum e bom é definir a largura intrínseca da imagem no HTML e usar estilização para dimensionar automaticamente e conter a imagem no seu contêiner pai.

Defina atributos de largura e altura explícitos

A maneira mais simples e eficaz de prevenir CLS de imagens e iframes é sempre incluir atributos width e height diretamente no HTML. Navegadores modernos usam esses atributos para calcular a proporção antes que o recurso carregue, reservando a quantidade correta de espaço.

<!-- Images: always include width and height -->
<img src="hero.jpg" width="800" height="450" alt="Hero image">

<!-- Iframes: same principle -->
<iframe src="https://example.com/embed"
    width="560" height="315"
    title="Embedded content">
</iframe>

<!-- Videos: always include dimensions -->
<video width="640" height="360" controls>
    <source src="video.mp4" type="video/mp4">
</video>

<style>
img, iframe, video {
    max-width: 100%;
    height: auto;
}
</style>

Use a propriedade CSS aspect-ratio

Para layouts responsivos ou quando dimensões exatas em pixels não estão disponíveis, a propriedade CSS aspect-ratio fornece uma maneira alternativa de reservar espaço. Isso é especialmente útil para contêineres que possuem conteúdo dinâmico ou mídia incorporada.

<style>
/* Reserve space for a 16:9 video container */
.video-wrapper {
    aspect-ratio: 16 / 9;
    width: 100%;
    background: #f0f0f0;
}

/* Reserve space for a square image */
.avatar {
    aspect-ratio: 1 / 1;
    width: 80px;
    object-fit: cover;
}

/* Responsive iframe container */
.embed-container {
    aspect-ratio: 560 / 315;
    width: 100%;
}
.embed-container iframe {
    width: 100%;
    height: 100%;
}
</style>

CLS causado por fontes web

Um Cumulative Layout Shift pode ser causado por fontes web. Fontes web são fontes que não estão instaladas no seu computador ou telefone local, mas são baixadas da internet. Enquanto a fonte web ainda não foi baixada, a página geralmente é renderizada com uma fonte fallback. O tamanho dessa fonte fallback pode diferir da fonte final. Neste exemplo, a fonte fallback é ligeiramente menor que a fonte web final. Para mais informações, veja como garantir que o texto permaneça visível durante o carregamento da fonte web.

Existem vários métodos para corrigir a mudança de layout causada por fontes web. Eles são baseados em duas técnicas:

1. Fazer a fonte fallback corresponder mais de perto à fonte web. A maneira mais eficaz é sobrescrevendo os descritores @font-face.

2. Acelerar as fontes web. Isso as tornará disponíveis para o navegador antes que ele comece a renderizar. Uma maneira comum de fazer isso é hospedar suas fontes web e pré-carregar suas fontes web críticas.

Correspondência de fonte fallback com substituições de métricas

A técnica mais eficaz para eliminar CLS de fontes web é criar uma definição de fonte fallback que corresponda de perto às dimensões da sua fonte web. Usando os descritores size-adjust, ascent-override, descent-override e line-gap-override, você pode fazer a fonte fallback ocupar um espaço quase idêntico. Combinado com font-display: swap, isso garante que o texto fique visível imediatamente com mudança de layout mínima quando a fonte web carrega.

<style>
/* Define a matched fallback font */
@font-face {
    font-family: 'My Font Fallback';
    src: local('Arial');
    size-adjust: 105.2%;
    ascent-override: 93%;
    descent-override: 24%;
    line-gap-override: 0%;
}

/* Use the web font with the matched fallback */
@font-face {
    font-family: 'My Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    font-display: swap;
}

body {
    font-family: 'My Font', 'My Font Fallback', sans-serif;
}
</style>

<!-- Preload the critical web font for faster loading -->
<link rel="preload" href="/fonts/myfont.woff2"
    as="font" type="font/woff2" crossorigin>

Ferramentas como o Fallback Font Generator podem calcular automaticamente os valores de substituição corretos para o seu par de fontes específico. Para Google Fonts especificamente, hospedar suas fontes dá controle total sobre as declarações font-face e a estratégia de pré-carregamento.

CLS causado por animações CSS

Animações e transições CSS podem acionar mudanças de layout inesperadas quando animam propriedades que afetam o layout dos elementos circundantes. Propriedades como top, left, width, height, margin e padding fazem o navegador recalcular o layout da página inteira, o que resulta em CLS. Para um passo a passo detalhado, veja como corrigir mudança de layout causada por transições CSS.

A solução é usar propriedades CSS compostas como transform e opacity para animações. Essas propriedades são tratadas pelo compositor GPU e não acionam recálculos de layout, portanto produzem zero CLS.

<style>
/* BAD: Animating top/left causes layout shifts */
.slide-in-bad {
    position: relative;
    animation: slide-bad 0.3s ease-out;
}
@keyframes slide-bad {
    from { top: -50px; opacity: 0; }
    to   { top: 0; opacity: 1; }
}

/* GOOD: Animating transform does NOT cause layout shifts */
.slide-in-good {
    animation: slide-good 0.3s ease-out;
}
@keyframes slide-good {
    from { transform: translateY(-50px); opacity: 0; }
    to   { transform: translateY(0); opacity: 1; }
}
</style>

De acordo com o HTTP Archive Web Almanac, 39% das páginas mobile e 42% das páginas desktop têm animações não compostas contribuindo para o CLS. Sempre verifique suas animações para garantir que usem apenas transform e opacity em vez de propriedades que acionam o layout.

Use CSS containment para isolar mudanças de layout

A propriedade CSS contain informa ao navegador que o conteúdo de um elemento é independente do restante da página. Isso limita o escopo dos recálculos de layout e pode evitar que mudanças de layout se propaguem para elementos circundantes.

<style>
/* Isolate ad containers from the rest of the page */
.ad-slot {
    contain: layout style;
    min-height: 250px;
}

/* For off-screen content, use content-visibility */
.below-fold-section {
    content-visibility: auto;
    contain-intrinsic-size: 0 500px;
}
</style>

A declaração contain: layout garante que quaisquer mudanças de tamanho dentro do elemento não acionarão recálculos de layout para elementos fora dele. A propriedade content-visibility: auto vai além, permitindo que o navegador pule completamente a renderização de conteúdo fora da tela, com contain-intrinsic-size fornecendo um tamanho estimado para evitar mudanças de layout quando o conteúdo entra na viewport.

Problemas de CLS causados por interações lentas do usuário

No exemplo abaixo, o botão carregar mais claramente aciona uma mudança de layout. No entanto, a mudança de layout não será adicionada às métricas de CLS. Isso ocorre porque essa mudança de layout é intencional.

O navegador sabe disso porque os elementos agora visíveis têm um atributo chamado "hadRecentInput". Quando isso é definido como true E a mudança de layout acontece dentro de 500 ms do evento de entrada (o clique do botão), a mudança de layout não será reportada pelo navegador.

Garanta que as interações do usuário sejam concluídas em 500ms. Se uma interação demorar mais do que isso, qualquer mudança de layout resultante contará para a pontuação de CLS. Isso é particularmente relevante para requisições AJAX que injetam novo conteúdo. Para dicas sobre otimização de elementos interativos, veja como construir um widget de chat com Core Web Vitals perfeitas.

Problemas de CLS causados por AJAX e conteúdo injetado dinamicamente

AJAX permite que páginas web sejam atualizadas de forma assíncrona trocando dados com um servidor web nos bastidores. Injetar novo conteúdo em qualquer página web pode levar a uma mudança de layout massiva. É por isso que é prudente reservar o espaço que será usado para o novo conteúdo. Você não sabe a altura do novo conteúdo antecipadamente, mas o que pode fazer é estimar.

Por exemplo, se o conteúdo AJAX médio ocupa 50% da tela, é prudente reservar esses 50%. Quando o novo conteúdo acabar ocupando 40 ou 60% da tela, o CLS (50% menos 40% = 10% fração de distância) ainda é muito menor do que uma fração de distância de 50%.

Aqui está um exemplo de como fazer isso:

<style>
   #ajax { height: 400px; }
   #ajax.loaded { height: auto; }
</style>
<script>
   fetch('/ajax-content')
   .then(response => response.json())
   .then(result => {
      let el = document.getElementById('ajax');
      el.innerHTML = result.html;
      el.classList.add('loaded');
   })
</script>

CLS pós-carregamento: conteúdo dinâmico e elementos de carregamento tardio

Mudanças de layout não acontecem apenas durante o carregamento inicial da página. O CLS pós-carregamento é causado por conteúdo que aparece ou muda de tamanho depois que a página já foi renderizada. Causas comuns incluem:

  • Anúncios de carregamento tardio: Redes de anúncios frequentemente injetam conteúdo segundos após a página ter carregado. Se o espaço do anúncio não tem espaço reservado, o anúncio empurra todo o conteúdo circundante para baixo.
  • Banners de consentimento de cookies: Banners que empurram o conteúdo da página para baixo em vez de sobrepô-lo causam CLS significativo. Use um padrão de sobreposição (position: fixed) ou reserve espaço no topo da página.
  • Conteúdo com lazy-load acima da dobra: Conteúdo carregado via Intersection Observer que estava inicialmente oculto mas aparece na viewport sem espaço reservado.
  • Scripts de teste A/B: Ferramentas de teste que modificam o DOM após a renderização inicial podem causar mudanças inesperadas. Execute modificações de teste A/B no lado do servidor ou dentro do HTML inicial quando possível.
  • Implementações de scroll infinito: Novo conteúdo adicionado ao final de uma lista pode causar mudanças se alterar o layout dos elementos existentes. Garanta que novo conteúdo seja adicionado apenas abaixo da posição atual de scroll.

O modelo de janela de sessão (descrito acima) significa que mesmo mudanças pós-carregamento contam para o CLS se acontecerem dentro da pior sessão. Monitore seus dados de atribuição de CLS no Core/Dash para identificar quais elementos mudam após o carregamento.

Corrigir problemas de CLS causados por anúncios

Anúncios frequentemente carregam significativamente mais tarde na página. Isso torna os Cumulative Layout Shifts causados por anúncios especialmente irritantes. Quando múltiplos anúncios estão carregando na viewport visível, a página simplesmente não fica parada. Para corrigir isso, reserve o espaço para os anúncios, especialmente os anúncios na viewport visível.

<style>
/* Reserve space for rectangle mobile ad */
.ad {
    min-height: 250px;
    background: #dedede;
    contain: layout style;
}
/* Reserve space for banner desktop ad */
@media only screen and (min-width: 600px) {
    .ad { min-height: 90px; }
}
</style>

Estudo de caso: Rakuten 24 e o impacto comercial do CLS

Rakuten 24, uma grande plataforma de e-commerce japonesa, conduziu um estudo detalhado sobre o impacto do Cumulative Layout Shift em suas métricas de negócio. Ao reduzir o CLS em suas páginas de produtos e categorias, a Rakuten 24 alcançou resultados notáveis:

  • Aumento de 53,37% na receita por visitante para usuários que experimentaram CLS baixo comparado àqueles com CLS alto.
  • Aumento de 33,13% na taxa de conversão para o mesmo grupo de CLS melhorado.
  • Diminuição de 15,20% na taxa de rejeição entre visitantes com experiências de página estáveis.

Esses números demonstram que CLS não é meramente uma métrica técnica. A instabilidade visual custa diretamente receita às empresas ao frustrar os usuários durante sua jornada de navegação e compra. Quando elementos mudam inesperadamente, os usuários perdem confiança, clicam errado e abandonam suas sessões. O estudo da Rakuten 24 confirma que investir na otimização de CLS tem um retorno sobre investimento mensurável, particularmente para sites de e-commerce onde cada interação conta.

O que os dados reais de CLS mostram

Dados do CoreDash mostram que o CLS é a Core Web Vital com melhor desempenho, com 92,8% dos carregamentos de página no corewebvitals.io alcançando uma pontuação "boa" e praticamente nenhuma diferença de dispositivo entre mobile e desktop. Tanto desktop (92,8% bom) quanto mobile (92,7% bom) alcançam pontuações de CLS quase perfeitas, com um p75 de 0 em ambos os tipos de dispositivo.

Isso contrasta com métricas como LCP e INP, onde o desempenho mobile é significativamente pior que o desktop. O CLS é excepcionalmente melhor no mobile do que no desktop em toda a web, o que é o inverso de todas as outras Core Web Vitals.

Globalmente, de acordo com o 2025 Web Almanac, o panorama é menos otimista:

  • 72% dos sites alcançam boas pontuações de CLS no geral, enquanto 11% têm CLS ruim.
  • 66% das páginas mobile têm pelo menos uma imagem sem dimensões definidas (abaixo dos 72% em 2022, mas ainda um grande contribuinte para CLS).
  • 39% das páginas mobile têm animações não compostas contribuindo para o CLS.
  • Apenas 11% das páginas pré-carregam fontes web, o que significa que a grande maioria dos sites é vulnerável a mudanças de layout por troca de fontes.

O CLS mostrou melhoria constante ano a ano globalmente, mas os dados revelam que imagens sem dimensões e animações não compostas continuam sendo as duas causas mais comuns. Resolver apenas essas duas questões eliminaria mudanças de layout para uma grande parte da web.

Perguntas frequentes sobre CLS

O que é uma boa pontuação de CLS?

Uma boa pontuação de CLS é 0,1 ou inferior. Pontuações entre 0,1 e 0,25 precisam de melhorias, e pontuações acima de 0,25 são consideradas ruins. Para passar na avaliação das Core Web Vitals, pelo menos 75% das suas visitas de página devem ter uma pontuação de CLS de 0,1 ou melhor. Ao contrário de métricas baseadas em tempo como LCP ou INP, o CLS é uma pontuação sem unidade calculada a partir da fração de impacto e fração de distância das mudanças de layout.

O que causa Cumulative Layout Shift?

As causas mais comuns de CLS são imagens e iframes sem atributos explícitos de largura e altura, fontes web que carregam com dimensões diferentes, conteúdo injetado dinamicamente (anúncios, banners de cookies, barras promocionais), animações CSS que usam propriedades que acionam o layout (top, left, width, height em vez de transform), e scripts de terceiros que carregam tardiamente. De acordo com dados globais, 66% das páginas mobile têm imagens sem dimensões e 39% têm animações não compostas, tornando estas as duas maiores contribuintes para CLS.

Mudanças de layout iniciadas pelo usuário contam para o CLS?

Não, mudanças de layout que ocorrem dentro de 500 milissegundos de uma interação do usuário (clique, toque ou pressionamento de tecla) são excluídas da pontuação de CLS. O navegador marca essas mudanças com uma flag "hadRecentInput" e não as inclui no cálculo. No entanto, se a resposta a uma interação do usuário demorar mais de 500 milissegundos, qualquer mudança de layout que ocorra após essa janela de 500ms contará para o CLS. É por isso que é importante garantir que todas as respostas interativas sejam concluídas rapidamente.

Como o CLS é calculado?

O CLS é calculado usando a fórmula: fração de impacto multiplicada pela fração de distância. A fração de impacto é a porcentagem da viewport que foi afetada pela mudança. A fração de distância é quão longe os elementos se moveram, como porcentagem da viewport. Por exemplo, se 50% da viewport mudou e o conteúdo se moveu 25% da altura da viewport, a pontuação de CLS para essa mudança seria 0,50 * 0,25 = 0,125. O navegador agrupa mudanças em "janelas de sessão" (máximo de 5 segundos, com um intervalo de 1 segundo entre mudanças), e a maior janela de sessão se torna a pontuação final de CLS.

O CLS afeta os rankings de SEO?

Sim, o CLS é uma das três Core Web Vitals que o Google usa como sinal de ranking. Embora o Google tenha afirmado que as Core Web Vitals são um fator de ranking relativamente pequeno comparado à relevância do conteúdo, elas podem ser um desempate entre páginas com qualidade de conteúdo similar. Mais importante, um CLS ruim impacta diretamente o comportamento do usuário: o estudo de caso da Rakuten 24 mostrou uma diferença de 53,37% na receita por visitante entre usuários que experimentaram CLS baixo versus CLS alto. Melhorar o CLS beneficia tanto seus rankings de busca quanto suas taxas de conversão.

Guias relacionados

Explore estes guias detalhados para técnicas específicas de otimização de CLS:

Para uma visão geral completa de todas as métricas Core Web Vitals e estratégias de otimização, visite a visão geral das Core Web Vitals ou use o Checklist Definitivo das Core Web Vitals para auditar seu site.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Pinpoint the route, device, and connection that fails.

CoreDash segments every metric by route, device class, browser, and connection type. Real time data. Not the 28 day average Google gives you.

Explore Segmentation
O que é Cumulative Layout Shift (CLS) e como corrigi-loCore Web Vitals O que é Cumulative Layout Shift (CLS) e como corrigi-lo