Solucionar problemas de rede

Objetivos de aprendizagem

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

• Usar o Chrome DevTools para verificar problemas de rede de componentes Web do Lightning.
• Revisar solicitações e respostas no painel Network (Rede).

Solução de problemas de rede em componentes Web do Lightning

O desempenho, ou seja, a rapidez de um site, depende de muitos fatores: recursos do servidor, recursos do cliente, velocidade do navegador e assim por diante. Muitos sites dependem apenas do tempo de carregamento da página para medir o desempenho. Na Salesforce, quando medimos o desempenho do Lightning, focamos no desempenho vivenciado pelo usuário. O tempo de página experimentado (EPT) é uma métrica de desempenho definida pela Salesforce para medir quanto tempo leva para uma página carregar e ficar pronta para um usuário interagir significativamente com ela.

A solução de problemas de desempenho dos componentes Web do Lightning pode levar você em várias direções. O EPT é um indicador de alto nível do desempenho da página. Para analisar mais a fundo os problemas de desempenho, há três áreas principais a considerar.

• Desempenho da rede
• Desempenho do navegador
• Complexidade e personalização da página

Nesse módulo, analisamos o desempenho da rede e do navegador, especificamente a memória do navegador.

Antes de começar

Na maior parte dos navegadores, as ferramentas de desenvolvedor têm caraterísticas semelhantes. Neste módulo, o foco será o Chrome DevTools.

Presumimos que você tem seu ambiente de desenvolvimento Salesforce DX configurado e se sente confortável em usá-lo para criar componentes Web do Lightning e implantá-los em uma organização. Se você ainda não está familiarizado com esse processo, conclua o projeto Início rápido: Componentes Web do Lightning antes de prosseguir no módulo.

Este módulo depende muito de sua experiência com o Chrome DevTools no módulo anterior da trilha Solucionar problemas de componentes Web do Lightning. Na verdade, se tiver acabado de concluir esses emblemas, seu Playground já deverá ter o código do GitHub necessário para o módulo. Siga essas etapas para confirmar se você tem o código mais recente do GitHub.

1. No Visual Studio Code, abra o projeto troubleshoot-lwc.

   Clique em File | Open (Arquivo | Abrir) (macOS) ou File | Open Folder (Arquivo | Abrir pasta) (Windows) e selecione o diretório troubleshoot-lwc.

2. Abra a Command Palette (Paleta de comandos) pressionando Ctrl+Shift+P (Windows) ou Cmd+Shift+P (macOS).
3. Insira git.
4. Selecione Git: Pull.
5. No diretório force-app/main/default, abra o diretório permissionsets.
6. Verifique se o arquivo Bad_Net_Full_Access.permissionset-meta.xml existe.
7. Clique com o botão direito do mouse na pasta default em force-app/main.
8. Selecione SFDX: Deploy Source to Org (SFDX: Implantar origem na organização).
9. Clique em View | Terminal (Exibir | Terminal).
10. Atribua o conjunto de permissões Bad Net Full Access (Acesso total ao Bad Net) ao usuário padrão executando o seguinte comando no terminal:
    sf org assign permset --name Bad_Net_Full_Access
11. Avance para Comece com um navegador limpo abaixo.

Configurar seu ambiente de solução de problemas

Se você ainda não concluiu o módulo Solução de problemas dos componentes Web do Lightning, configure um Trailhead Playground com alguns componentes Web do Lightning e prepare-o para a solução de problemas nesse módulo.

Pronto para praticar com os componentes Web do Lightning?

Não temos um desafio prático neste módulo, mas você pode experimentar as etapas em seu Trailhead Playground. Veja como acessar seu playground. Primeiro, verifique se você está conectado ao Trailhead. Em seguida, clique no avatar do usuário no canto superior direito desta página e selecione Hands-on Orgs (Organizações práticas) na lista suspensa. Clique em Launch (Iniciar) ao lado da organização que você deseja abrir. Ou, se quiser criar um novo playground, clique em Create Playground (Criar playground).

Habilitar o Debug Mode (Modo de depuração)

Essa etapa simplifica muito a solução de problemas de código. Com o Modo de depuração habilitado na organização, o código não é minimizado. Assim, os nomes das variáveis permanecem iguais e a estrutura geral do código não é alterada, o que facilita muito a solução de problemas.

1. Em Setup (Configuração), insira Debug Mode (Modo de depuração) na caixa Busca rápida e, em seguida, selecione Debug Mode (Modo de depuração).
2. Marque a caixa ao lado do seu usuário.
3. Clique em Enable (Habilitar).

Puxar os Componentes Web do Lightning do GitHub

1. Conclua as instruções no repositório readme do GitHub.
2. No Visual Studio Code, atribua o conjunto de permissões Bad Net Full Access (Acesso total ao Bad Net) ao usuário padrão executando o seguinte comando no terminal.
   sf org assign permset --name Bad_Net_Full_Access

Seu ambiente já está pronto para solucionar alguns problemas usando o Chrome DevTools.

Começar com um navegador limpo

1. Abra um navegador Chrome.
2. Clique no ícone Customize and control Google Chrome (Personalizar e controlar o Google Chrome) () e selecione New Incognito Window (Nova janela anônima). Isso garantirá que o Chrome seja executado em um estado limpo sem extensões. As extensões podem criar ruído nas medições de desempenho.
3. Abra o Trailhead Playground.
4. Certifique-se de que o Debug Mode (Modo de Depuração) esteja ativado para seu usuário e que o EPT esteja exibido abaixo do banner do modo de depuração.
   
   

   Você também pode exibir o EPT usando o sufixo de URL: ?eptVisible=1.

Solucionar problemas de um componente de resposta lenta

1. No App Launcher (Iniciador de aplicativos) (), no seu playground, encontre e abra o Bad Network.
2. No aplicativo Bad Network, clique em +1 para tentar aumentar o número algumas vezes.
   Está demorando muito para apenas incrementar o número. Vamos usar a guia Performance (Desempenho) do DevTools para começar a solucionar problemas.
3. Clique com o botão direito do mouse na janela do navegador e selecione Inspect (Inspecionar) (ou clique em F12) para abrir o DevTools.
4. Clique no ícone Customize and control DevTools (Personalizar e controlar o DevTools) () e selecione o lado do encaixe que deseja usar: Desencaixar em uma janela separada, Encaixar à esquerda, Encaixar na parte inferior ou Encaixar à direita. (As imagens neste módulo mostram o DevTools desencaixado em uma janela separada.)

   

   Com o DevTools em uma janela separada, você tem melhor acesso a todos os dados durante a solução de problemas.

5. No menu do DevTools selecione a guia Performance (Desempenho).
6. No menu Performance (Desempenho), clique no ícone Record (Gravar) () para iniciar a gravação de um perfil.
7. No aplicativo Bad Network, clique em +1 para aumentar o número novamente.
   Espere até que o número seja atualizado.
8. No painel Performance (Desempenho), clique em Stop (Parar) para terminar a gravação e deixar que o painel Performance (Desempenho) compile e exiba os dados em uma linha de tempo.

Vamos observar os dados de desempenho

1. Observe a longa linha azul no gráfico de linha do tempo NET abaixo dos gráficos FPS e CPU.
   
2. Expanda a seção Network (Rede) (à esquerda). Observe a chamada do Aura começando entre 2000 ms e 2500 ms, alinhada com a linha azul na seção de gráficos de Net.
   
3. Mova o cursor do mouse sobre a chamada do Aura para ver as informações da solicitação.
   

   Observe o carimbo de data/hora (2,90 segundos nesse caso) e o nome da solicitação.

O painel Performance (Desempenho) trouxe-nos até aqui, mostrando a solicitação de rede de longa duração. Para ver mais detalhes, vamos usar o painel Network (Rede).

O painel de rede

Como o painel Performance (Desempenho), o painel Network (Rede) tem muitas opções disponíveis para investigação e solução de problemas. Abordamos apenas algumas aqui. Consulte a seção Resources (Recursos) para se aprofundar no que o painel Network (Rede) tem a oferecer.

Log de rede

O painel Network (Rede) registra todas as atividades da rede no Network Log (Log de rede).

Cada linha do Network Log (Log de rede) representa um recurso. Os recursos são listados cronologicamente, do primeiro ao último, por padrão. O DevTools registra a atividade da rede somente enquanto ela está aberta.

Cada coluna contém informações sobre um recurso.

• Nome: Ao clicar no nome do recurso, os detalhes do recurso serão exibidos
• Status: Código de resposta HTTP
• Tipo: Tipo de recurso
• Iniciador: O que causou a solicitação do recurso
  Clicar no iniciador abre o código-fonte correspondente.
• Duração: Quanto tempo levou para executar a solicitação
• Cascata: Gráfico de diferentes estágios da solicitação
  Mova o cursor do mouse para exibir um detalhamento da solicitação.

Inspecionar detalhes da resposta

1. Selecione a guia Network (Rede).
   

   Selecione o filtro Fetch/XHR para ver apenas solicitações XMLHttpRequest (XHR).

2. Clique no nome do recurso aura.ApexAction.execute=1 para abrir os detalhes do recurso.
   Os detalhes do recurso são abertos e exibem a guia selecionada anteriormente.
3. Clique na guia Response (Resposta) para ver a resposta recebida do servidor.
   

   A resposta pode vir em formatos diferentes. Nesse caso, é uma resposta em formato JSON grande (JavaScriptObjectNotation).

4. Clique na guia Timing para ver um detalhamento da atividade da rede.
   

   Observe o aviso Waiting for server response (Aguardando resposta do servidor) e a barra verde alongada. Isso representa o tempo de espera para o servidor responder: o tempo entre o navegador solicitar uma página e receber o primeiro byte de informações do servidor. Nesse caso, Waiting for server response (Aguardando resposta do servidor) é de 3,83 segundos.

5. Clique na guia Initiator (Iniciador) para exibir a pilha de chamadas da solicitação.
   O DevTools filtra a exibição inicial para mostrar apenas os itens mais significativos (quadros), por exemplo, as chamadas de maior duração. Clique no link Show more frames (Mostrar mais quadros) para ver todos os itens na pilha de chamadas.
   
   Observando a pilha, podemos ver que increaseNum chamou longAsyncFetch no arquivo example1_IncreaseNumber.js.
6. No painel Initiator (Iniciador), clique no link example1_IncreaseNumber.js para abrir o arquivo example1_IncreaseNumber.js no painel Sources (Origens).
   
   
   

   Os números de linha correspondem às capturas de tela. Seu código pode ser compilado com números de linha diferentes.

   Os tempos destacados na coluna de números das linhas do código representam apenas o tempo em que o navegador interagiu com a chamada, não a duração da chamada. Talvez seja necessário rolar pela janela de código para ver o método async longAsyncFetch.
   
   Na linha 84, o método increaseNum(event) chama longAsyncFetch() com um operador await. Isso faz com que o javaScript espere pela resposta longa. Da mesma forma, no método longAsyncFetch() há uma chamada para o método apex_generateJSONRecords_default utilizando await para aguardar a resposta antes de continuar.

Agora sabemos que o motivo de o número demorar tanto para ser incrementado é que um (ou ambos) dos operadores await leva o código a esperar por uma resposta. Precisamos remover o operador await para que o processo possa ser executado em segundo plano ou modificar o código do Apex para ser executado com mais rapidez.

Em seguida, vamos analisar um problema de memória do navegador no lado do cliente.

Recursos

• Desenvolvedores do Chrome: Inspecionar atividade de rede
• Documentos da Web do MDN: await
• Documentos da Web do MDN: Hora até o primeiro byte