Como escrever melhor CSS com desempenho em mente

No post de hoje, refletiremos sobre as escolhas de código que podemos fazer no CSS para melhorar o desempenho do site. Mas, antes de nos aprofundarmos nessas escolhas, primeiro vamos dar uma olhada mais de perto no fluxo de trabalho de renderização de páginas da Web para nos concentrarmosáreas problemáticas (em termos de desempenho) que podem ser resolvidas via CSS.

Aqui está o fluxo aproximado de operações realizadas pelo navegador após a criação da árvore DOM:

1. Recalcule o estilo (e renderize a criação da árvore). O navegador calcula os estilos a serem aplicados aos elementos na árvore DOM. Uma árvore de renderização é criada posteriormente ao descartar os nós (elementos) da árvore DOM que não devem ser renderizados (elementos com Mostrar nenhum) e aqueles que são (pseudo-elementos).
2. Layout (também conhecido como Reflow). Usando o estilo calculado de antes, o navegador calcula a posição e a geometria de cada elemento na página.
3. Repintar. Depois que o layout é mapeado, os pixels são desenhados na tela.
4. Camadas Compostas. Durante a repintura, a pintura pode ser feita em diferentes camadas de forma autônoma; essas camadas são finalmente combinadas.

Agora vamos continuar com o que podemos fazer nos primeiros três estágios da operação para escrever códigos CSS com melhor desempenho.

1. Reduzir cálculos de estilo

Como mencionado anteriormente, no estágio "Recalculate Style", o navegador calcula os estilos a serem aplicados aos elementos. Para fazer isso, o navegador primeiro descobre todos os seletores no CSS que apontam para um determinado nó de elemento na árvore DOM. Em seguida, ele passa por todas as regras de estilo nesses seletores e decide quais devem ser realmente aplicados ao elemento.

Para evitar cálculos de estilo dispendiosos, reduzir seletores complexos e profundamente aninhados para que seja mais fácil para o navegador descobrir a qual elemento um seletor está se referindo. Isso reduz o tempo computacional.

Outras formas de empregar incluem reduzindo o número de regras de estilo (quando possível), removendo CSS não utilizado e evitando redundância e substituições, para que o navegador não tenha que passar pelo mesmo estilo repetidamente durante os cálculos de estilo.

2. Reduzir Reflows

Reflexões ou alterações de layout em um elemento são processos muito "caros", e podem ser um problema ainda maior quando o elemento que passou pelas mudanças de layout tem uma quantidade significativa de filhos (desde Reflete em cascata pela hierarquia).

Os reflexos são acionados por alterações de layout em um elemento, como alterações nas propriedades geométricas, como altura ou tamanho da fonte, adição ou remoção de classes a elementos, redimensionamento de janela, ativação :flutuar, Alterações do DOM por JavaScript, etc.

Assim como no cálculo de estilo, para reduzir o Reflows, evite seletores complexos e árvores DOM profundas (novamente, isso é para impedir o excesso de cascata de Reflows).

Se você tiver que mudar os estilos de layout de um componente em sua página, segmentar os estilos do elemento que está no mais baixo na hierarquia de elementos que o componente é feito. Isso é para que as alterações de layout não acionem (quase) qualquer outro Reflows.

Se você está animando um elemento que passa por mudanças de layout, tirá-lo do fluxo da página por posicionando-o absoutamente, já que o refluxo em elementos posicionados de maneira absoluta não afetará o restante dos elementos da página.

Para resumir:

• Elementos de destino que são menores na árvore DOM ao fazer alterações de layout
• Escolha elementos absolutamente posicionados para animações de mudança de layout
• Evite animar propriedades de layout sempre que possível

3. Reduzir Reimpressões

Repaint refere-se ao desenho de pixels na tela, e é um processo caro, assim como o Reflow. Repaints pode ser desencadeada por Reflows, rolagem de página, mudanças em propriedades como cor, visibilidade e opacidade.

Para evitar repintes freqüentes e enormes, usar menos das propriedades que causam republicações dispendiosas como sombras.

Se você está animando propriedades de um elemento que pode disparar Repaint direta ou indiretamente, será de grande vantagem se esse elemento estiver em sua própria camada impedindo que o processo de pintura afete o restante da página e acione a aceleração de hardware. Na aceleração de hardware, a GPU assumirá a tarefa de realizar as alterações de animação na camada, economizando o trabalho extra da CPU enquanto acelera o processo..

Em alguns navegadores, opacidade (com um valor inferior a 1) e transformar (valor diferente de Nenhum) são automaticamente promovidos para novas camadas, e a aceleração de hardware é aplicada para animações e transições. Preferir essas propriedades para animações é, portanto, bom.

Para forçar promover um elemento para nova camada e entrar em aceleração de hardware para animação, existem duas técnicas envolvidas:

1. adicionar transform: translate3d (0, 0, 0); para o elemento, enganando o navegador para acionar a aceleração de hardware para animações e transições.
2. Adicione o vai mudar propriedade para o elemento, que informa o navegador das propriedades que provavelmente serão alteradas no elemento no futuro. Nota: Sara Soueidan tem um artigo aprofundado e super-útil sobre isso no site Dev.Opera.

Para resumir:

• Evite estilos caros que causam Repaints
• Busque promoção de camadas e aceleração de hardware para animações e transições pesadas.

Tome nota

(1) Então, até agora, nós não tocamos na redução do tamanho do arquivo CSS. Mencionamos que a redução nas regras de estilo (e elementos DOM) melhora significativamente o desempenho quanto o navegador terá que trabalhar Menos no processo de computação dos estilos. Como conseqüência dessa redução de código, escrevendo melhores seletores e a exclusão de CSS não utilizado, o tamanho do arquivo diminuirá automaticamente.

(2) Também é aconselhável não faça muitas mudanças consequentes nos estilos de um elemento em JavaScript. Em vez disso, adicione uma classe ao elemento (usando JavaScript) que contém os novos estilos para fazer essas alterações - isso evita os Reflux desnecessários.

(3) Você vai querer evitar o Thrashing de Layout também (Reflows síncronos forçados) que surgem devido ao acesso e modificação das propriedades de Layout de elementos usando JavaScript. Leia mais sobre como isso mata o desempenho aqui.