Browser Reflow: O que o aciona e como afeta os Core Web Vitals

O que é browser reflow?

Reflow é o que acontece quando o navegador recalcula a posição e o tamanho dos elementos na página. Toda vez que você altera o DOM ou modifica uma propriedade CSS que afeta o layout, o navegador precisa descobrir onde tudo deve ficar novamente. Esse cálculo bloqueia a thread principal. Nada mais acontece até que ele termine.

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

Revisado pela última vez por Arjen Karel em março de 2026

O pipeline de renderização

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

JavaScript → Style → Layout → Paint → Composite

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

Nem toda alteração atinge todos os cinco estágios. Esse é o insight principal. Altere width ou height e você acionará o pipeline completo. Altere background-color e você ignorará totalmente o layout (apenas paint + composite). Altere transform ou opacity e você ignorará 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 com reflow e você terá travamentos (jank).

O que aciona o reflow

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

Propriedades CSS que acionam o 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 acionam um repaint, mas não um reflow. Propriedades como transform, opacity e filter não acionam 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 que as coisas ficam caras. Certas propriedades de JavaScript forçam o navegador a calcular o layout agora mesmo, de forma síncrona, bloqueando seu script. Paul Irish mantém uma lista abrangente (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 ser evitado

O layout thrashing acontece quando 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 acordeão e códigos de analytics que medem as posições dos elementos.

// RUIM: força o reflow em 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, em seguida, escreve em style.width (invalidando o layout). Com 100 elementos, são 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, em seguida, faça todas as escritas.

Detectando reflow forçado no Chrome DevTools

Abra o painel de Performance e grave um trace. 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 de triângulo vermelho. Passe o mouse sobre ele e você verá exatamente qual linha de JavaScript acionou o reflow.

O Console também registra um aviso: "Forced reflow while executing JavaScript took Xms". Qualquer valor acima de 30ms é um problema. Já vi sites onde um único manipulador de eventos de rolagem aciona 40ms de trabalho de layout em 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 acionar 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, páginas que agrupam leituras e escritas no 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 cada elemento que usa essa fonte. Em uma página com muito texto, esse reflow pode atrasar o LCP em 100ms ou mais.

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 carrega, o navegador faz o reflow da página para acomodar o tamanho real.

Cumulative Layout Shift (CLS)

O reflow em si não causa CLS. O CLS acontece quando elementos visíveis se moveem após o usuário vê-los. Mas o reflow de conteúdo carregado tardiamente (anúncios injetados, imagens sem tamanho definido, 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. Fazer a transição de height ou margin causa um reflow em cada frame de animação.

Prevenindo o reflow com CSS moderno

Animações apenas de composite

Anime transform e opacity em vez de width, height, top, ou left. Elas são executadas na thread do compositor da GPU e ignoram totalmente o layout. 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 desnecessário de layout em cada frame.

CSS containment

A propriedade contain informa ao navegador que os elementos internos 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 daquela 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 levará. O containment limita o raio de explosão.

content-visibility

O content-visibility: auto informa ao navegador para ignorar os cálculos de layout, paint e style para elementos que estão fora da tela. Quando o Google testou isso em uma demonstração 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 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 evita o reflow quando o recurso carrega.
3. Anime apenas com transform e opacity. Elas ignoram 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 a seções abaixo da dobra (below-the-fold). Isso ignora o layout para conteúdo fora da tela.
6. Prefira flexbox em vez de floats. O layout flexbox é aproximadamente 4x mais rápido do que o layout float para o mesmo número de elementos.
7. Faça o yield para a thread principal entre operações pesadas no DOM para manter a página responsiva.
8. Faça o defer de scripts que modificam o DOM até que a renderização inicial seja concluída.

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