Render Tree, Layout, Paint e Reflow, o que Causa Jank

O problema

Tem interface que parece lenta mesmo quando “nada trava de vez”.

O scroll fica estranho. A animacao parece pesada. O clique responde, mas a tela engasga.

Esse tipo de desconforto visual costuma receber um nome prático:

jank

E ele e traiçoeiro porque muita gente tenta explicar do jeito mais curto possível:

• “o React rerenderizou”
• “o CSS esta pesado”
• “o JavaScript bloqueou”

As tres frases podem até tocar no problema.

Mas ainda não explicam o caminho inteiro.

Modelo mental

Para desenhar ou depurar UI no browser, ajuda pensar em quatro camadas:

1. o browser entende a estrutura visual relevante
2. calcula tamanhos e posições
3. pinta pixels
4. compoe o resultado na tela

Em linguagem mais comum:

• render tree
• layout
• paint
• composição

Jank aparece quando esse trabalho fica caro demais para o ritmo esperado da interação.

Quebrando o problema

Render tree não e o DOM inteiro em abstrato

O browser parte da estrutura e dos estilos para entender o que precisa participar da renderização.

Nem todo nodo entra do mesmo jeito.

O importante aqui não e decorar implementação exata.

E entender que existe uma estrutura visual derivada do que precisa aparecer.

Layout calcula geometria

Layout responde perguntas como:

• quanto esse elemento mede?
• onde ele fica?
• o que muda ao redor quando ele cresce?

Quando você altera propriedades que impactam geometria, o browser pode precisar recalcular esse mapa.

Isso pode custar pouco ou muito.

Depende de quantos elementos e relações entram no efeito dominó.

Paint desenha a aparencia

Depois da geometria, o browser pode precisar repintar.

Aqui entram aspectos como:

• cor
• sombra
• borda
• texto
• imagem

Nem toda repintura e terrivel.

Mas pintura frequente e cara demais em area grande também pesa.

Reflow e o apelido da dor de layout

Na conversa prática, muita gente usa reflow para falar do recalculo de layout disparado por mudancas de geometria.

Exemplo de coisa que tende a ser mais sensivel:

• mudar width
• mudar height
• inserir conteúdo que empurra outros elementos
• ler medida do DOM depois de escrever estilo repetidamente

Quando você mistura leitura e escrita do layout sem cuidado, pode forcar o browser a recalcular mais vezes do que precisava.

Exemplo simples

Imagine uma lista animada.

Versão mais cara:

• a cada frame você muda top e height
• depois le offsetHeight
• depois escreve de novo

Esse ciclo tende a forcar trabalho de layout repetido.

Versão mais barata em muitos casos:

• mover com transform
• evitar ler medida toda hora
• agrupar leituras e escritas

Não e que transform resolve toda a vida.

Mas ele costuma evitar parte do trabalho geometrico mais pesado.

Erros comuns

• Culpar framework sem olhar o tipo de mudança visual.
• Tratar qualquer repaint como catastrofe igual.
• Ler medida do DOM logo depois de várias escritas sem perceber o custo.
• Achar que só animacao causa jank.
• Ignorar que JavaScript, layout e paint disputam a mesma janela de fluidez.

Como um senior pensa

Quem tem mais experiência costuma olhar para jank e perguntar:

“O gargalo esta no JavaScript, no layout, na pintura ou na combinação deles?”

Essa pergunta e forte porque evita chute.

Em vez de otimizar no escuro, ela empurra a investigação para a etapa cara de verdade.

O que o entrevistador quer ver

Em entrevista, esse assunto aparece para testar se você entende browser alem do framework.

O avaliador quer ver se você:

• diferencia layout de paint
• entende por que certas mudancas custam mais
• conecta jank a thread principal e renderização
• evita simplificação do tipo “rerender = bug”

Uma resposta forte costuma soar assim:

“Jank aparece quando o browser precisa fazer trabalho visual demais para a janela de tempo da interação. Eu tentaria descobrir se o custo esta em JavaScript, em recalculo de layout, em paint ou numa combinação disso.”

Interface fluida não vem de decorar palavra. Vem de entender que nem toda mudança visual cobra a mesma conta.