Renderização do navegador: de texto a imagens

📖 9min read

A tela que está sendo desenhada não é mágica

Quando comecei o desenvolvimento front-end (Vue.js), pensei no navegador apenas como um ‘quadro para exibir código’. Era natural que se você usasse

, um quadrado aparecesse, e se você usasse color: red, ele ficasse vermelho.

No entanto, meus pensamentos mudaram quando experimentei na prática a animação travada ou a tela tremendo ao rolar (jank). “Por que o mesmo código funciona perfeitamente no Chrome, mas trava no Internet Explorer (IE)?” “Por que minha CPU dispara quando mudo um pouco o estilo com JavaScript?”

Acontece que o navegador não é apenas um porta-retratos. O navegador era um enorme ‘Pintor’ e ‘Arquiteto’ que interpretava o texto (HTML/CSS) que enviamos, calculava matematicamente cada pixel e o imprimia.

Da última vez, entregamos dados com segurança através de estradas irregulares. Desta vez, vamos abrir a caixa de dados (pacote) que chegou e descobrir como o navegador desenha uma imagem chamada tela. Esta é a história final da série Re: Booting CS Basics.

O navegador é um canteiro de obras onde o código é lido, construído e pintado.

A carga chegou, a montagem começa

Em nossa visão de mundo de “centro de logística digital”, o produto (arquivo HTML) já chegou à casa do cliente (navegador). Porém, o que chegou não foi um produto acabado, mas sim um ‘manual de montagem’. A equipe de trabalho chamada motor do navegador (motor de renderização) lê este manual e imediatamente inicia a montagem. Esse processo é chamado de pipeline de renderização.

Etapa 1: Análise do Blueprint (Análise e Árvore DOM)

Lê o texto HTML que chega primeiro e cria um ‘esqueleto’.

Etapa 2: Design de Interiores (Árvore CSSOM)

Em seguida, leia o arquivo CSS e crie ‘regras de estilo’.

Etapa 3: Criar uma ordem de serviço (Render Tree)

Agora combinamos o esqueleto (DOM) e o design (CSSOM). O ponto importante aqui é que apenas ‘coisas que realmente aparecerão na tela’ serão selecionadas.

A árvore de renderização é uma lista final apenas ‘daqueles que podem ser desenhados de verdade’.

[Verificação de código] Refluxo e repintura

Agora é o passo realmente importante. A chave para a otimização do desempenho está aqui. Depois que a árvore de renderização é criada, o navegador executa duas tarefas pesadas.

Vamos sentir a diferença de custo com o código.

const box = document.getElementById('box');

// Case 1: Codigo que provoca layout (Reflow) (caro!)
// Ao mudar tamanho ou posicao, os elementos ao redor precisam ser recalculados.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Codigo que so provoca paint (Repaint) (relativamente barato)
// Posicao igual, so muda a cor. Sem recalculo, so repintar.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Análise:

Na prática, a maioria dos casos de “animação intermitente” ocorre porque propriedades de layout como largura, esquerda e topo são tocadas em tempo real. Neste caso, é necessária uma técnica para pular o cálculo do layout usando propriedades como transform.

Conselhos práticos: não intimide seu navegador

Eu não sabia disso quando estava na faculdade, então manipulei aleatoriamente o DOM com JavaScript. Ao passar pela instrução for, alterei o tamanho e o estilo de cada elemento. Do ponto de vista do navegador, é como ser torturado destruindo e reconstruindo um prédio dezenas de vezes por segundo.

Dicas para garantir o desempenho:

Alterar a localização (Refluir) é uma operação muito mais cara do que alterar a cor (Repintar).

Concluindo a Série 1: Meu CS reiniciado

Com este artigo, a [Re: Booting] CS Basics Series chegou ao fim.

Fizemos uma longa jornada juntos.

No início, era apenas um conhecimento que eu memorizava para conseguir um emprego. Porém, depois de encontrar erros na prática e olhar novamente, CS (engenharia da computação) não era letra morta, mas sim uma base sólida que sustentava meu código.

O trabalho de fundação está concluído. É hora de construir seu próprio castelo em terreno sólido. Na próxima série [Monolith Builder], abordarei a construção de aplicações web usando Spring Boot e Vue.js, que experimentei na prática. Aguardem ansiosamente o processo de transformar a ‘teoria’ em ‘prática’.

Deixe um comentário