Reflow do Navegador: O que o Desencadeia e Como Afeta os Core Web Vitals

O que é o reflow do navegador?

O reflow é o que acontece quando o navegador recalcula a posição e o tamanho dos elementos na página. Sempre que você altera o DOM ou modifica uma propriedade CSS que afeta o layout, o navegador precisa descobrir onde tudo se encaixa novamente. Esse cálculo bloqueia a thread principal. Nada mais acontece até que seja concluído.

Um único reflow em uma página simples leva microssegundos. Mas acione centenas deles durante uma interação do usuário e você terá centenas de milissegundos de tempo de thread principal bloqueado. Isso é o suficiente para falhar no Interaction to Next Paint.

Última revisão por Arjen Karel em março de 2026

O pipeline de renderização

Para entender por que o reflow é custoso, você precisa saber como o navegador renderiza uma página. Toda alteração visual passa por até cinco estágios:

JavaScript → Style → Layout → Paint → Composite

O JavaScript (ou CSS) aciona uma alteração visual. O navegador recalcula quais estilos se aplicam. Em seguida, ele executa o layout (reflow) para computar a geometria. Depois, ele pinta (paints) os pixels. Finalmente, ele compõe (composites) as camadas juntas.

Nem toda alteração atinge os cinco estágios. Essa é a percepção chave. Altere width ou height e você acionará todo o pipeline. Altere background-color e você pulará o layout inteiramente (apenas paint + composite). Altere transform ou opacity e você pulará tanto o layout quanto o paint, indo direto para o composite. O guia de performance de renderização do web.dev cobre esse pipeline em detalhes.

Alterações apenas de composite são baratas. Alterações de layout não são. A 60fps, o navegador tem 16.66ms por frame para fazer tudo. Após a sobrecarga do navegador, você tem cerca de 10ms para o seu código. Gaste isso em reflow e você terá jank.

O que desencadeia o reflow

Duas categorias de coisas causam reflow: alterações que invalidam o layout atual e leituras em JavaScript que forçam o navegador a calcular o layout imediatamente.

Propriedades CSS que desencadeiam layout

Alterar qualquer uma dessas propriedades força o navegador a fazer o reflow:

• Dimensões: width, height, padding, border, min-height, max-width
• Posição: top, right, bottom, left, margin
• Modo de layout: display, float, position, flex, grid
• Texto: font-size, font-family, font-weight, line-height, text-align, white-space
• Conteúdo: overflow, word-wrap

Propriedades como color, background-color, visibility e box-shadow desencadeiam um repaint, mas não um reflow. Propriedades como transform, opacity e filter não desencadeiam nenhum dos dois. Estas são as propriedades que você deseja para animações e transições.

Propriedades JavaScript que forçam layout síncrono

Aqui é onde se torna custoso. Certas propriedades JavaScript forçam o navegador a calcular o layout agora mesmo, de forma síncrona, bloqueando o seu script. Paul Irish mantém uma lista abrangente (mais de 5.000 estrelas no GitHub). As mais comuns:

• offsetWidth, offsetHeight, offsetTop, offsetLeft
• clientWidth, clientHeight, clientTop, clientLeft
• scrollWidth, scrollHeight, scrollTop, scrollLeft
• getBoundingClientRect()
• getComputedStyle()
• innerText (sim, ler innerText força o layout)
• focus()
• scrollIntoView()

Ler qualquer uma destas após alterar uma propriedade de layout força um reflow síncrono. O navegador não pode retornar o valor sem calcular o layout primeiro. O Chrome DevTools sinaliza reflows forçados que excedem 30ms como um gargalo de performance.

Layout thrashing: o padrão a evitar

O layout thrashing acontece quando o seu código alterna entre a leitura e a escrita de propriedades de layout em um loop. Cada leitura força um reflow porque a escrita anterior invalidou o layout. Vejo esse padrão constantemente em scripts de carrossel, plugins de sanfona e códigos de analytics que medem as posições dos elementos.

// RUIM: força o reflow a cada iteração
for (const el of elements) {
  el.style.width = box.offsetWidth + 'px'; // leitura + escrita = reflow forçado
}

Cada iteração lê offsetWidth (forçando o layout) e então escreve style.width (invalidando o layout). Com 100 elementos, isso significa 100 reflows forçados em vez de um.

// BOM: agrupe a leitura, depois agrupe as escritas
const width = box.offsetWidth; // leitura única
for (const el of elements) {
  el.style.width = width + 'px'; // apenas escritas, sem reflows forçados
}

Uma leitura, um reflow, pronto. O guia do web.dev sobre layout thrashing mostra esse padrão em detalhes. Se você precisar ler os tamanhos de elementos individuais, colete todas as leituras primeiro e depois faça todas as escritas.

Detectando reflow forçado no Chrome DevTools

Abra o painel Performance e grave um trace. Os reflows forçados aparecem como blocos roxos de "Layout" no flame chart. Se o Chrome detectar um layout síncrono forçado, ele adicionará um aviso em triângulo vermelho. Passe o mouse sobre ele e você verá exatamente qual linha de JavaScript desencadeou o reflow.

O Console também registra um aviso: "Forced reflow while executing JavaScript took Xms". Qualquer coisa acima de 30ms é um problema. Já vi sites onde um único manipulador de eventos de scroll desencadeia 40ms de trabalho de layout a cada frame.

O Lighthouse sinaliza isso também. Procure pelo diagnóstico "Avoid forced reflow" na categoria de Performance.

Como o reflow afeta os Core Web Vitals

Interaction to Next Paint (INP)

O reflow impacta diretamente o INP de duas maneiras. Se um reflow forçado já estiver em execução quando o usuário clicar, o input delay aumentará porque a thread principal está bloqueada. Se o próprio manipulador de clique desencadear trabalho de layout, o processing time aumentará. De qualquer forma, o presentation delay também cresce porque o navegador deve concluir o layout antes de poder pintar a resposta.

O limite "bom" do INP é de 200ms. Um único reflow forçado de 30ms já consome 15% desse orçamento. O layout thrashing em um manipulador de eventos pode facilmente empurrar o INP para além de 500ms.

Em sites monitorados pelo CoreDash, as páginas que agrupam leituras e escritas do DOM mostram pontuações de INP aproximadamente 18% melhores em comparação com páginas com padrões de layout thrashing.

Largest Contentful Paint (LCP)

Durante o carregamento da página, o reflow compete pelo tempo da thread principal. O carregamento de fontes é uma fonte comum disso: quando uma web font chega e substitui o texto de fallback, o navegador faz o reflow de todos os elementos que usam essa fonte. Em uma página com muito texto, esse reflow pode empurrar o LCP 100ms ou mais para trás.

Imagens sem atributos explícitos de width e height causam o mesmo problema. De acordo com o 2025 Web Almanac, 62% das páginas mobile ainda têm pelo menos uma imagem sem dimensões. Quando essa imagem é carregada, o navegador faz o reflow da página para acomodar o tamanho real.

Cumulative Layout Shift (CLS)

O reflow por si só não causa CLS. O CLS acontece quando elementos visíveis se movem depois que o usuário os vê. Mas o reflow de conteúdo de carregamento tardio (anúncios injetados, imagens sem tamanho, elementos inseridos dinamicamente) é o mecanismo por trás da maioria dos layout shifts. Corrija o gatilho do reflow e o layout shift desaparecerá.

As transições CSS que animam propriedades de layout são outra fonte. A transição de height ou margin causa um reflow a cada frame de animação.

Prevenindo reflow com CSS moderno

Animações apenas de composite

Anime transform e opacity em vez de width, height, top ou left. Estes rodam na thread de compositor da GPU e pulam o layout inteiramente. Quer mover um elemento? Use transform: translateX(). Quer redimensioná-lo visualmente? Use transform: scale(). O 2025 Web Almanac descobriu que 40% das páginas mobile ainda usam animações não compostas. Isso significa 40% das páginas fazendo trabalho de layout desnecessário a cada frame.

Contenção CSS

A propriedade contain diz ao navegador que as partes internas de um elemento são independentes do restante da página. Quando algo muda dentro de um elemento contido, o navegador faz o reflow apenas dessa subárvore em vez de todo o documento.

article {
  contain: content;
}

Isso é especialmente útil para páginas com um DOM grande. Quanto mais elementos o navegador tiver que verificar durante o reflow, mais tempo ele levará. A contenção limita o raio de explosão.

content-visibility

O content-visibility: auto diz ao navegador para pular os cálculos de layout, paint e estilo para elementos que estão fora da tela. Quando o Google testou isso em uma demo de blog de viagens, o tempo de renderização caiu de 232ms para 30ms. Uma melhoria de 7x.

.section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

O contain-intrinsic-size fornece ao navegador uma altura de placeholder para que os cálculos da barra de rolagem permaneçam corretos. Essa propriedade se tornou Baseline Newly Available em setembro de 2025, o que significa que funciona em todos os principais navegadores.

Checklist prático

1. Agrupe as leituras do DOM antes das escritas. Nunca alterne entre a leitura de propriedades de layout e a escrita de alterações de estilo.
2. Defina dimensões explícitas em imagens e embeds. Isso previne o reflow quando o recurso é carregado.
3. Anime com transform e opacity apenas. Estes pulam o layout e o paint inteiramente.
4. Use contain: content em seções independentes. Isso limita o reflow à subárvore alterada.
5. Adicione content-visibility: auto às seções below-the-fold. Isso pula o layout para conteúdo fora da tela.
6. Prefira flexbox ao invés de floats. O layout flexbox é cerca de 4x mais rápido do que o layout float para o mesmo número de elementos.
7. Yield para a thread principal entre operações custosas do DOM para manter a página responsiva.
8. Faça defer de scripts que modificam o DOM até depois que a renderização inicial for concluída.

Monitore o impacto real dessas alterações com o Real User Monitoring. Ferramentas de laboratório como o Lighthouse mostram o custo de layout de forma isolada, mas os dados de campo mostram se os seus usuários realmente vivenciam a melhoria.