Reduzir o escopo e a complexidade dos cálculos de estilo

Jeremy Wagner

Paul Lewis

JavaScript geralmente aciona mudanças visuais. Às vezes, isso torna mudanças diretamente por meio de manipulações de estilo e, às vezes, por meio de cálculos que resultam em mudanças visuais, como pesquisar ou classificar dados. No momento certo ou JavaScript de longa duração pode ser uma causa comum de problemas de desempenho, e você deve minimizar seu impacto ao máximo.

Cálculo do estilo

Alterar o DOM adicionando e removendo elementos, alterando atributos, classes, ou a reprodução de animações faz com que o navegador recalcule os estilos dos elementos e, em muitos casos, o layout de parte ou de toda a página. Esse processo é chamado cálculo de estilo computado.

O navegador começa a calcular estilos criando um conjunto de seletores correspondentes para determinam quais classes, pseudosseletores e IDs se aplicam a um determinado elemento. Em seguida, ele processa as regras de estilo dos seletores correspondentes e descobre os estilos finais do elemento.

Observação: aproximadamente metade do tempo usado no Blink (o mecanismo de renderização usado no Chromium e navegadores derivados) para calcular o estilo calculado de um elemento é usada para corresponder os seletores, e a outra metade é usada para construir o representação de estilo das regras correspondentes. Rune Lillesveen, Ópera / Invalidação de estilo no Blink

Tempo de recálculo do estilo e latência da interação

Interaction to Next Paint (INP) é um ambiente de execução centrado no usuário. que avalia a capacidade de resposta geral de uma página em relação à entrada do usuário. Mede a latência de interação desde quando o usuário interage com a página até o navegador pinta o próximo frame, mostrando as atualizações visuais correspondentes para na interface do usuário.

Um componente significativo de uma interação é o tempo necessário para pintar a próxima frame. O trabalho de renderização feito para apresentar o próximo frame é composto por várias partes: incluindo o cálculo de estilos de página que ocorrem pouco antes do layout, pintura e e composição do trabalho. Nesta página, nos concentramos nos custos de cálculo de estilo, mas a redução parte da fase de renderização relacionada à interação também reduz seu tamanho latência, inclusive para cálculos de estilo.

Reduza a complexidade dos seus seletores

Simplificar os nomes dos seletores pode ajudar a acelerar o estilo da sua página cálculos. Os seletores mais simples fazem referência a um elemento no CSS com apenas um nome da classe:

.title {
  /* styles */
}

Mas, conforme qualquer projeto cresce, ele provavelmente precisa de CSS mais complexo, e você pode terminar com seletores como estes:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

Para determinar como esses estilos se aplicam à página, o navegador tem que efetivamente pergunte: "Este é um elemento com uma classe title cujo pai é o elemento filho min-nth-plus-1 com uma classe de box?" Descobrir como fazer isso pode levar muito tempo, dependendo do seletor usado como e do navegador em questão. Para simplificar isso, você pode mudar o seletor para ser apenas um nome de classe:

.final-box-title {
  /* styles */
}

Esses nomes de classe de substituição podem parecer estranhos, mas tornam trabalho muito mais simples. Na versão anterior, por exemplo, para o navegador saber um elemento é o último de seu tipo, ele deve primeiro saber tudo sobre todos os outros elementos para determinar se algum elemento posterior que poderia será o nth-last-child. Isso pode ser muito mais caro em termos computacionais do que corresponder um seletor a um elemento apenas porque sua classe corresponde.

Reduzir o número de elementos estilizados

Outra consideração de desempenho e, muitas vezes, mais importante do que o seletor complexidade, é a quantidade de trabalho que precisa acontecer quando um elemento muda.

Em termos gerais, o custo do pior caso do cálculo do estilo dos elementos computados é o número de elementos multiplicado pela contagem do seletor, porque o navegador precisa verificar cada elemento pelo menos uma vez em relação a todos os estilos para ver se ele correspondências.

Observação :costumava acontecer quando você alterava uma classe em um elemento, todos os filhos precisariam que seus estilos computados fossem recalculados. Alguns navegadores em vez disso, mantêm uma pequena coleção de regras exclusivas para cada elemento que causam estilos do elemento sejam recalculados se forem alterados. Isso significa que um elemento pode precisar ser recalculado dependendo de onde ele está na árvore e o que mudou.

Os cálculos de estilo podem visar alguns elementos diretamente em vez de invalidar a página inteira. Em navegadores modernos, isso tende a ser menos problemático, pois o navegador não precisa verificar sempre todos os elementos que as mudanças podem afetar. Por outro lado, os navegadores mais antigos nem sempre são otimizados para essas tarefas. Onde possível, reduza o número de elementos invalidados.

Observação: os cálculos de estilo nos Web Components são um pouco diferentes, porque não cruzam o limite do Shadow DOM por padrão e têm como escopo componentes individuais, não a árvore como um todo. No geral, porém, o mesmo esse conceito ainda se aplica: árvores menores com regras mais simples são processadas de forma eficiente do que árvores maiores, com regras mais complexas.

Meça o custo de recálculo de estilo

Uma maneira de medir o custo dos recálculos de estilo é usar a métrica de desempenho no Chrome DevTools. Faça o seguinte para começar:

1. Abra o DevTools.
2. Acesse a guia Desempenho.
3. Clique em Gravar.
4. Interaja com a página.

Quando a gravação for interrompida, você verá algo parecido com a seguinte imagem:

Um relatório do DevTools mostrando cálculos de estilo.

A faixa no topo é um diagrama de chamas em miniatura que também traça quadros por segundo. Quanto mais perto a atividade estiver do fundo da tira, mais rápido frames são pintados pelo navegador. Se o Flame Chart estiver diminuindo. com barras vermelhas no topo, então há um trabalho que está causando frames de longa duração.

Frames de longa duração na atividade do DevTools resumo.

Frames de longa duração durante uma interação, como a rolagem, precisam ser mais próximos. olhar Se você vir um grande bloco roxo, aumente o zoom na atividade e selecione qualquer trabalho rotulado Recalcular estilo para obter mais informações sobre um trabalho caro de recálculo de estilo.

Um recálculo de estilo de longa duração, que leva apenas mais de 25&nbspms no resumo do DevTools.

Clique no evento para ver a pilha de chamadas. Se o trabalho de renderização foi causado por um interação do usuário, ele chama o JavaScript que acionou a alteração de estilo. Ele também mostra o número de elementos afetados pela mudança, pouco mais de 900 neste caso, e quanto tempo levou o cálculo do estilo. Você pode usar essas informações para começar a tentar encontrar uma correção para seu código.

Usar bloco, elemento, modificador

Abordagens de programação, como BEM (bloco, elemento, modificador) incorporar os benefícios de desempenho correspondentes ao seletor. O BEM recomenda que Tudo tem uma única classe e, quando se precisar de hierarquia, essa hierarquia também é incorporada ao nome da classe:

.list {
  /* Styles */
}

.list__list-item {
  /* Styles */
}

Se você precisar de um modificador, como no exemplo do último filho, adicione-o da seguinte forma: isso:

.list__list-item--last-child {
  /* Styles */
}

O BEM é um bom ponto de partida para organizar seu CSS, tanto a partir de uma estrutura e, devido às simplificações de pesquisa de estilo que ela promove.

Se você não gosta do BEM, há outras formas de abordar seu CSS, mas é avalie o desempenho e a ergonomia deles antes de começar.

Recursos

• Invalidação de estilo no Blink
• BEM (bloco, elemento, modificador)

Imagem principal do Unsplash, por Markus Spiske.