Skip to main content

Identificar problemas de desempenho no aplicativo Bad Bunch

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

  • Apresentar diversas formas de regular o desempenho.
  • Usar o monitor de desempenho para localizar problemas no nó do DOM.

Chamadas de evento excessivamente caras

Na unidade anterior, solucionamos o problema de um componente Web do Lightning de baixo desempenho com posicionamento incorreto do código em um loop. Vamos dar uma olhada em outro mau exemplo e como solucioná-lo.

  1. Com o aplicativo Bad Bunch aberto, selecione Example 2: Scroll List (Exemplo 2: Rolar pela lista) e espere a página carregar completamente.
  2. No painel Performance (Desempenho) do DevTools, clique em Gravar para iniciar a gravação do perfil.
  3. Agora, role pela lista em Scroll This List! (Role pela lista!)
    Exemplo 2: Scroll List (Rolar pela lista) com a lista rolada para baixo.
    A ação deve estar um pouco lenta ou irregular.
  4. No painel Performance (Desempenho), clique em Stop (Parar) para encerrar a gravação e deixar que os dados sejam compilados.
    Painel Performance (Desempenho) mostrando vários eventos chamados.
    Na seção Main (Principal), observe todos os eventos JavaScript que são chamados. Observe também todos os pequenos triângulos vermelhos.
    Painel Performance (Desempenho) com um evento em destaque.
    O triângulo vermelho é a forma que o Chrome encontrou para indicar que a ação pode ter demorado muito tempo.
  5. Desça pela pilha de chamadas e clique em um dos eventos onScroll para ver os detalhes na guia Summary (Resumo).
    Painel Summary (Resumo) com os detalhes do evento destacados e o link para a função no código.
    Observe que isso vem do nosso código, o método onScroll no arquivo example2_ScrollList.js. Na linha 87, para ser mais exato.
  6. No painel Summary (Resumo), clique no link de example2_ScrollList.js para ir para o painel Sources (Origens) usando o código que é exibido.
    Origens exibindo o arquivo example2_ScrollList.js com carimbos de data/hora ao lado dos números das linhas.
    Observe a linha 82: li.style.background = ‘#edede’;.

    Estamos adicionando estilo com código em cada rolagem. Essa é uma situação que deveria ser tratada de outra forma. Acrescenta muita sobrecarga ao evento. Existem pseudo-classes de CSS (Folhas de estilos em cascatas) como tr:nth-child(even) and tr:nth-child(odd) exatamente para essa finalidade. Uma abordagem de CSS será sempre mais rápida do que usar JavaScript.

    Outro problema aqui é a falta de um debouncer para evitar que o evento seja acionado com tanta frequência. Adicionar um ouvinte a um evento de rolagem fará com que ele seja acionado com muita frequência. Se esse evento estiver realizando operações caras, é ainda pior. Confira a seção Resources (Recursos) para saber mais sobre esse assunto.
Nota

No Chrome, o evento de rolagem é acionado uma vez por quadro durante a rolagem, ou seja, uma vez a cada 16,7ms em uma tela de 60FPS. O Safari é acionado ainda mais rapidamente (o que, na verdade, viola a especificação).

Renderização de estilos recalculados

  1. Com o aplicativo Bad Bunch aberto, selecione Example 3: Input Fields (Exemplo 3: Campos de entrada).
    Para esse exemplo, talvez seja necessário limitar a CPU.
  2. Em Capture Settings (Configurações de captura) (), para CPU, selecione 4x slowdown (Desaceleração de 4x) para demonstrar um navegador mais lento.
    Painel Performance (Desempenho) mostrando a CPU definida como desaceleração de 4x com um indicador de aviso ao lado da guia Performance (Desempenho) e um ícone vermelho de Capture Settings (Configurações de captura).
    Observe o ícone de aviso ao lado de Performance (Desempenho) e o ícone vermelho de Capture Settings (Configurações de captura) definidos como lembretes de que a tela está limitada. A regulagem depende das capacidades do seu computador. Por exemplo, a opção de desaceleração de 4x faz com que sua CPU opere 4 vezes mais devagar do que sua capacidade normal.
  3. No painel Performance (Desempenho) do DevTools, clique em Gravar.
  4. Comece a digitar em Input #1 (Entrada 1).
    Exemplo 3: Campos de entrada com texto sendo digitado no campo Input #1 (Entrada 1).
    Uma experiência desagradável, nada tranquila.
  5. Comece a digitar no campo Input #2 (Entrada 2). Bem mais tranquilo.
  6. No painel Performance (Desempenho), clique em Stop (Parar) para terminar a gravação e deixar que os dados sejam compilados.
    Painel Performance (Desempenho) mostrando vários eventos chamados com muita cor roxa exibida na seção do gráfico da CPU.
    O gráfico da CPU apresenta muitos elementos roxos. A consulta na guia Summary (Resumo) mostra que roxo representa Renderização. A maior parte do tempo é destinado à Renderização. Também há muitos triângulos vermelhos.
    Vamos ampliar apenas uma pequena seção. Mas, primeiro, vamos desativar a regulagem da CPU.
  7. Em Capture Settings (Configurações de captura) (), desative a limitação da CPU.
    É recomendável desativar qualquer limitação assim que você terminar de usá-la, pois ela continua a limitar mesmo quando a gravação é interrompida.
  8. Clique e arraste o cursor do mouse por uma pequena seção do gráfico da CPU.
    Painel Performance (Desempenho) mostrando uma seção ampliada dos eventos que exibem o bloco grande e roxo de Recalculate Style (Recalcular estilo).
    Observe o bloco grande Recalculate Style (Recalcular estilo). Algo está causando um recálculo caro dos estilos CSS.
  9. Clique em um dos eventos onSlowInput para ver os detalhes no painel Summary (Resumo).
    Painel Summary (Resumo) com link para example3_InputFields.js.
  10. No painel Summary (Resumo), clique no link example3_InputFields.js para abri-lo no painel Sources (Origens).
    Painel Sources (Origens) exibindo exampe3_InputFields.js com onSlowInput onFastInput e métodos block.
    O método onSlowInput faz uma chamada para o método block. O método block está renderizando muitos divs com tamanhos aleatórios, fazendo com que os estilos sejam recalculados. Isso é um problema.
    O método onFastInput, linha 166, é chamado no campo Input #2 (Entrada 2). Ele também faz uma chamada para a chamada de bloco, mas somente após ter passado por debouncing. Isso mostra como o método debounce ajuda. A melhor prática seria usar o debounce e atualizar o método block para não causar o recálculo.

Explosão de nós do DOM

O próximo exemplo pode bloquear seu navegador. Você pode usar o Gerenciador de tarefas mencionado na primeira unidade para começar de novo.

  1. Com o aplicativo Bad Bunch aberto, selecione a guia Example 4: Table (Exemplo 4: Tabela).
    Se seu navegador travar, use o Gerenciador de tarefas do Chrome para terminar o processo e recomeçar.
    Exemplo 4: Tabela exibida com muitos dados em uma tabela.
    São muitos dados, mas o carregamento deve ser mais rápido. Vamos gravar um perfil enquanto a página carrega.
  2. Clique em Example 3: Input Fields (Exemplo 3: Campos de entrada) para sair dessa guia.
  3. No painel Performance (Desempenho) do DevTools, clique em Gravar.
  4. Agora, clique em Example 4: Table (Exemplo 4: Tabela).
    Espere o exemplo carregar.
  5. No painel Performance (Desempenho), clique em Stop (Parar) para terminar a gravação e deixar que os dados sejam compilados.
    Painel Performance (Desempenho) mostrando a gravação do perfil.
    Se você fizer várias gravações de perfil, alterne entre as gravações no menu Performance (Desempenho).
    Menu do painel Performance (Desempenho) mostrando várias gravações.
    Rolar para baixo na pilha de chamadas da seção Main (Principal) levará a um evento renderedCallback que parece ter sido executado várias vezes, mas, na verdade, foi executado uma vez.
  6. Clique no evento renderedCallback para ver os detalhes no painel Summary (Resumo).
    O evento renderedCallback está destacado e seus detalhes são exibidos na guia Summary (Resumo).
  7. No painel Summary (Resumo), clique no link example4_Table.js para abri-lo no painel Sources (Origens).
    Painel Sources (Origens) exibindo exampe4_Table.js com o método renderedCallback.
    Há muitas coisas acontecendo nesse método. Uma análise mais aprofundada revela que há muitos divs sendo criados. Vamos considerar outra forma de ver isso.
  8. Na guia Example 4: Table (Exemplo 4: Tabela), clique com o botão direito do mouse em uma das células da tabela e selecione Inspect (Inspecionar).
    O painel Elements (Elementos) no DevTools é aberto e exibe a marcação HTML da célula da tabela.
    Painel Elements (Elementos) no DevTools mostrando uma enorme árvore de divs.
    São muitas marcas div. Essa é apenas uma das células da tabela.
    Vamos usar o Performance monitor (Monitor de desempenho) para analisar melhor essa questão.
  9. Em DevTools, clique em Personalizar e controlar o DevTools para expandir o menu. Em seguida, clique em More tools (Mais ferramentas) e, em seguida, em Performance monitor (Monitor de desempenho).
    Árvore do menu Customize and control DevTools (Personalizar e controlar o DevTools) mostrando os links More tools (Mais ferramentas) e o Monitor de desempenho.
    O Performance monitor (Monitor de desempenho) aparece na parte inferior do DevTools. O Performance monitor (Monitor de desempenho) mostra uma visualização em tempo real de vários aspectos do carregamento de uma página ou do desempenho do tempo de execução, como o uso da CPU, o tamanho de heap do JavaScript, o número total de nós do DOM e assim por diante
    DevTools com o Monitor de desempenho aberto.
    Vamos dar uma olhada nos Nós do DOM! Mais de 400 mil nós. Vamos ver como isso fica no carregamento da página.
  10. No Monitor de desempenho, desfaça a seleção de JS heap size (Tamanho de heap do JS) e JS event listeners (Ouvintes de eventos do JS).
  11. Recarregue a página e observe os nós do DOM aumentarem.

Esse é um problema que pode ocorrer em páginas com muitas informações. Não apenas tabelas de dados. Isso pode se tornar um problema devido à forma como os componentes Web do Lightning são criados e conectados. Componentes dentro de componentes dentro de componentes ou componentes que geram dinamicamente outros componentes ou grandes números de marcas HTML podem adicionar muitos nós do DOM ao layout.

Vimos várias maneiras de detectar problemas de desempenho com Componentes Web do Lightning e até páginas do Lightning em geral. Agora você tem novas ferramentas em seu cinto de utilidade e está mais preparado para lidar com problemas de desempenho.

Recursos

Compartilhe seu feedback do Trailhead usando a Ajuda do Salesforce.

Queremos saber sobre sua experiência com o Trailhead. Agora você pode acessar o novo formulário de feedback, a qualquer momento, no site Ajuda do Salesforce.

Saiba mais Continue compartilhando feedback