Solução de problemas comuns de desempenho

Os usuários esperam páginas interativas e suaves. Cada estágio no pipeline de pixels representa uma oportunidade de introduzir o jank (interrupções da renderização). Saiba mais sobre ferramentas e estratégias para identificar e corrigir problemas comuns que atrasam o desempenho do runtime.

Resumo

  • Não escreva JavaScript que force o navegador a recalcular o layout. Separe as funções de leitura e gravação e execute as leituras primeiro.

  • Não complique demais seu CSS. Use menos CSS e mantenha seus seletores CSS simples.

  • Evite o layout o máximo possível. Escolha CSS que não dispara o layout.

  • A pintura pode levar mais tempo do que qualquer outra atividade de renderização. Cuidado com gargalos de tinta.

JavaScript

Os cálculos javaScript, especialmente os que disparam alterações visuais extensas, podem atrasar o desempenho do aplicativo. Não deixe que JavaScript mal cronometrado ou de longa duração interfira nas interações do usuário.

JavaScript: Ferramentas

Faça uma gravação na ferramenta Desempenho e procure eventos suspeitomente longos Evaluate Script .

Se você notar um pouco de jank (interrupções de renderização) em seu JavaScript, talvez seja necessário levar sua análise para o próximo nível e coletar um perfil de CPU JavaScript. Os perfis de CPU mostram onde o runtime é gasto dentro das funções de sua página. Saiba como criar perfis de CPU no runtime do JavaScript.

JavaScript: Problemas

A tabela a seguir descreve alguns problemas comuns do JavaScript e possíveis soluções.

Problema Exemplo Solução
Manipuladores de entrada caros que afetam a resposta ou a animação. Toque, rolagem de paralaxe. Deixe que o navegador manipule toque e role ou associe o ouvinte o mais tarde possível. Consulte Manipuladores de Entrada Caros na lista de verificação de desempenho do runtime de Paul Lewis.
JavaScript mal cronometrado afetando resposta, animação, carga. O usuário rola logo após o carregamento da página, setTimeout/setInterval. Otimizar o runtime do JavaScript: use requestAnimationFrame, espalhe a manipulação do DOM em quadros, use Web Workers.
JavaScript de execução longa afetando a resposta. O evento DOMContentLoaded para enquanto está inundado com o trabalho JS. Mova o trabalho computacional puro para os Web Workers. Se você precisar de acesso do DOM, use requestAnimationFrame.
Scripts de lixo que afetam a resposta ou a animação. A coleta de lixo pode acontecer em qualquer lugar. Escreva scripts menos lixo. Consulte Coleta de Lixo em Animação na lista de verificação de desempenho do runtime de Paul Lewis.

Estilo

As alterações de estilo são dispendiosamente, especialmente se essas alterações afetarem mais de um elemento no DOM. Sempre que você aplica estilos a um elemento, o navegador descobre o impacto em todos os elementos relacionados, recalcula o layout e repinta.

Estilo: Ferramentas

Faça uma gravação na ferramenta Desempenho . Verifique a gravação de eventos grandes Recalculate Style (exibidos em roxo).

Selecione um Recalculate Style evento para exibir mais informações sobre ele no painel Detalhes . Se as alterações de estilo estiverem demorando muito, isso será um sucesso de desempenho. Se os cálculos de estilo estiverem afetando um grande número de elementos, essa será outra área com espaço para melhorias.

Estilo de recálculo longo

Para reduzir o impacto dos Recalculate Style eventos, minimize o uso de propriedades CSS que disparam layout, pintura e composição. Essas propriedades têm o maior impacto no desempenho de renderização. Para obter mais informações, consulte Manter Compositor-Only Propriedades e Gerenciar Contagem de Camadas

Estilo: Problemas

A tabela a seguir descreve alguns problemas de estilo comuns e possíveis soluções.

Problema Exemplo Solução
Cálculos de estilo caros que afetam a resposta ou a animação. Qualquer propriedade CSS que altere a geometria de um elemento, como a largura, altura ou posição; o navegador verifica todos os outros elementos e recalcula o layout. Evitar CSS que dispara layouts
Seletores complexos que afetam a resposta ou a animação. Seletores aninhados forçam o navegador a saber tudo sobre todos os outros elementos, incluindo pais e filhos. Referencie um elemento no CSS com apenas uma classe.

Layout

Layout (ou refluxo no Firefox) é o processo pelo qual o navegador calcula as posições e os tamanhos de todos os elementos em uma página. O modelo de layout da Web significa que um elemento pode afetar outros; por exemplo, a largura do <body> elemento normalmente afeta as larguras de qualquer elemento filho, e assim por diante, todo o caminho para cima e para baixo da árvore. O processo pode estar bastante envolvido para o navegador.

Como regra geral, se você pedir um valor geométrico de volta do DOM antes que um quadro seja concluído, você se encontrará com "layouts síncronos forçados", o que pode ser um grande gargalo de desempenho se repetido com frequência ou executado para uma árvore DOM grande.

Layout: Ferramentas

O painel Desempenho identifica quando uma página causa layouts síncronos forçados. Esses Layout eventos são marcados com barras vermelhas.

Layout síncrono forçado

"Surra de layout" é uma repetição de condições de layout síncronas forçadas. Isso ocorre quando o JavaScript grava e lê do DOM repetidamente, o que força o navegador a recalcular o layout repetidamente. Para identificar a falha de layout, procure um padrão de vários avisos de layout síncrono forçados. Consulte a figura anterior.

Layout: Problemas

A tabela a seguir descreve alguns problemas de layout comuns e possíveis soluções.

Problema Exemplo Solução
Layout síncrono forçado que afeta a resposta ou a animação. Forçar o navegador a executar o layout anteriormente no pipeline de pixels, resultando em etapas repetidas no processo de renderização. Em lote, seu estilo lê primeiro e, em seguida, grava todas as gravações.
A surra de layout que afeta a resposta ou a animação. Um loop que coloca o navegador em um ciclo de leitura-gravação-leitura-gravação, forçando o navegador a recalcular o layout repetidamente. Operações de gravação em lote automaticamente usando a biblioteca FastDom.

Pintura e composição

A pintura é o processo de preenchimento de pixels. Geralmente, é a parte mais cara do processo de renderização. Se você notou que sua página não está funcionando como projetada de forma alguma, é provável que você tenha problemas de pintura.

A composição é onde as partes pintadas da página são montadas para exibição na tela. Na maioria das vezes, se você se ater a propriedades somente compositor e evitar a pintura completamente, você deve observar uma grande melhoria no desempenho, mas você precisa watch para contagens excessivas de camadas.

Pintura e composição: Ferramentas

Para descobrir quanto tempo a pintura leva ou com que frequência a pintura ocorre:

  1. Em DevTools, na ferramenta Desempenho , clique no botão Capturar configurações (o ícone e selecione a caixa de seleção Habilitar instrumentação de renderização avançada .

  2. Faça uma gravação.

Se a maior parte do tempo de renderização for gasto pintando, você terá problemas de pintura. Para obter mais informações, consulte Ativar a instrumentação de renderização avançada na referência de recursos de desempenho.

Pintura e composição: problemas

A tabela a seguir descreve alguns problemas comuns de pintura e composição e possíveis soluções.

Problema Exemplo Solução
Pinte tempestades que afetam a resposta ou a animação. Áreas de pintura grandes ou pinturas caras que afetam a resposta ou animação. Evite tinta, promova elementos que estão se movendo para sua própria camada, use transformações e opacidade.
Explosões de camada que afetam animações. A superpromoção de muitos elementos com translateZ(0) afeta muito o desempenho da animação. Promova para camadas com moderação e somente quando você sabe que oferece melhorias tangíveis.

Observação

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Google e usadas de acordo com os termos descritos na Licença Pública Creative Commons Atribuição 4.0 Internacional. A página original é encontrada aqui e é de autoria de Kayce Basques (Technical Writer, Chrome DevTools & Lighthouse) e Meggin Kearney (Technical Writer).

Licença Creative Commons Este trabalho é licenciado sob uma Licença Internacional de Atribuição do Creative Commons 4.0.