Solucionar problemas de red

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Usar Chrome DevTools para comprobar los problemas de red de los componentes web Lightning.
• Revisar las solicitudes y las respuestas en el panel de red.

Solución de problemas de red en componentes web Lightning

El desempeño, es decir, la rapidez del sitio, depende de muchos factores: los recursos del servidor, los recursos de los clientes, la velocidad del navegador, etc. Muchos sitios dependen únicamente del tiempo de carga de las páginas para medir el desempeño. En Salesforce, cuando medimos el desempeño de Lightning, nos centramos en la experiencia de desempeño del usuario. El tiempo de carga transcurrido (EPT) es una métrica de desempeño que Salesforce definió para medir cuánto tarda una página en cargarse y estar lista para que un usuario interactúe con ella de manera efectiva.

Solucionar los problemas de desempeño de los componentes web Lightning puede llevarlo hacia varias direcciones. EPT es un indicador de alto nivel del desempeño de las páginas. Para profundizar en los problemas de desempeño, hay tres áreas principales a tener en cuenta.

• Desempeño de la red
• Desempeño del navegador
• Personalización y complejidad de la página

En este módulo, observamos el desempeño de la red y el desempeño del navegador, específicamente la memoria del navegador.

Antes de comenzar

Las funciones de las herramientas para desarrolladores son similares en la mayoría de los navegadores. En este módulo, nos centramos en Chrome DevTools.

Suponemos que su entorno de desarrollo de Salesforce DX está configurado y que está cómodo utilizándolo para crear componentes web Lightning e implementarlos en una organización. Si todavía no está familiarizado con este proceso, complete el proyecto Inicio rápido: Componentes web Lightning antes de continuar en este módulo.

Este módulo depende en gran medida de su experiencia con Chrome DevTools de módulos anteriores en la ruta Solucionar problemas en los componentes web Lightning. De hecho, si recién completó esas insignias, su zona de pruebas ya debería tener el código de GitHub que se necesita para este módulo. Siga estos pasos para confirmar que tiene el código de GitHub más reciente.

1. En Visual Studio Code, abra el proyecto troubleshoot-lwc.

   Haga clic en File | Open (Archivo | Abrir) (macOS) o File | Open Folder (Archivo | Abrir carpeta) (Windows) y seleccione el directorio troubleshoot-lwc.

2. Abra la paleta de comandos. Para ello, pulse Ctrl+Mayús+P (Windows) o Cmd+Mayús+P (macOS).
3. Introduzca git.
4. Seleccione Git: Pull (Extraer).
5. En el directorio force-app/main/default, abra el directorio permissionsets.
6. Verifique que exista el archivo Bad_Net_Full_Access.permissionset-meta.xml.
7. Haga clic con el botón derecho en la carpeta default en force-app/main.
8. Seleccione SFDX: Deploy Source to Org (SFDX: Implementar fuente en la organización).
9. Haga clic en View | Terminal (Ver | Terminal).
10. Asigne el conjunto de permisos Bad Net Full Access al usuario predeterminado. Para ello, debe ejecutar este comando en el terminal:
    sf org assign permset --name Bad_Net_Full_Access
11. Pase a la sección Comenzar con un navegador limpio a continuación.

Configurar el entorno de solución de problemas

En primer lugar, si todavía no completó el módulo Solución de problemas en los componentes web Lightning, debe configurar un Trailhead Playground con algunos componentes web Lightning y prepararlo para solucionar problemas en este módulo.

¿Todo listo para pasar a la práctica con los componentes web Lightning?

No existe un reto práctico en este módulo, pero puede probar los pasos en su Trailhead Playground. Así es como debe acceder a su zona de pruebas. En primer lugar, asegúrese de que inició sesión en Trailhead. A continuación, haga clic en su avatar de usuario de la esquina superior derecha de esta página y seleccione Hands-on Orgs (Organizaciones de prácticas) desde el menú desplegable. Haga clic en Launch (Iniciar) junto a la organización que desea abrir. O bien si quiere crear una nueva zona de pruebas, haga clic en Create Playground (Crear Playground).

Habilitar el Modo de depuración

Este paso hace que solucionar problemas de código sea mucho más fácil. Con el modo de depuración habilitado en la organización, el código no se minimiza. Por lo tanto, los nombres de las variables siguen siendo los mismos y la estructura general del código se mantiene, lo que hace que solucionar problemas sea mucho más fácil.

1. En Setup (Configuración), ingrese Debug Mode (Modo de depuración) en el cuadro Quick Find (Búsqueda rápida) y, a continuación, seleccione Debug Mode (Modo de depuración).
2. Seleccione la casilla junto a su usuario.
3. Haga clic en Enable (Activar).

Obtener los componentes web Lightning desde GitHub

1. Complete las instrucciones en el archivo readme del repositorio de GitHub.
2. En Visual Studio Code, asigne el conjunto de permisos Bad Net Full Access al usuario predeterminado. Para ello, debe ejecutar el siguiente comando en el terminal.
   sf org assign permset --name Bad_Net_Full_Access

Su entorno ahora está listo para solucionar problemas con Chrome DevTools.

Comenzar con un navegador limpio

1. Abra un navegador de Chrome.
2. Haga clic en el ícono Customize and control Google Chrome (Personalizar y controlar Google Chrome) () y seleccione New Incognito Window (Nueva ventana de incógnito). Esto garantiza que Chrome se ejecuta en un estado limpio sin extensiones instaladas. Las extensiones pueden crear ruido en sus mediciones de desempeño.
3. Abra su Trailhead Playground.
4. Asegúrese de que el Debug Mode (Modo de depuración) esté activado para su usuario y que el EPT se muestre debajo del panel Debug Mode (Modo de depuración).
   
   

   También se puede mostrar el EPT usando este sufijo de URL: ?eptVisible=1.

Solución de problemas de componentes con respuesta lenta

1. Desde el Iniciador de aplicación () en su Trailhead Playground, encuentre y abra Bad Network.
2. En la aplicación Bad Network, haga clic en +1 para intentar aumentar el número unas cuantas veces.
   Solo incrementar el número está tardando demasiado. Usemos la ficha Performance (Desempeño) de DevTools para comenzar a solucionar problemas.
3. Haga clic con el botón derecho en la ventana del navegador y seleccione Inspect (Inspeccionar) (o haga clic en F12) para abrir DevTools.
4. Haga clic en el ícono Customize and control DevTools (Personalizar y controlar DevTools) () y seleccione el lado que desea usar para anclar: Undock into separate window (Desanclar en ventana separada), Dock to left (Anclar a la izquierda), Dock to bottom (Anclar en la parte inferior) o Dock to right (Anclar a la derecha). (Las imágenes de este módulo muestran DevTools desanclada en una ventana separada).

   

   Tener DevTools en una ventana separada le permite acceder mejor a todos los datos cuando solucione problemas.

5. En el menú DevTools, seleccione la ficha Performance (Desempeño).
6. En el menú Performance (Desempeño), haga clic en el ícono Record (Registro) () para empezar a registrar un perfil.
7. En la aplicación Bad Network, haga clic en +1 para aumentar el número nuevamente.
   Espere que el número se actualice.
8. En el panel Performance (Desempeño), haga clic en Stop (Detener) para finalizar el registro y permitir que panel de desempeño compile y muestre los datos en una cronología.

Datos de desempeño

1. Observe la larga línea azul en el gráfico de cronología NET debajo de los gráficos FPS y CPU.
   
2. Expanda la sección Network (Red) a la izquierda. Observe la llamada de aura que comienza entre 2000 ms y 2500 ms, alineada con la línea azul en la sección del gráfico de red.
   
3. Pase el cursor sobre la llamada de aura para ver la información de solicitud.
   

   Observe la marca de tiempo (2,90 segundos en este caso) y el nombre de la solicitud.

El panel Performance (Desempeño) nos trajo a este punto mostrándonos la solicitud de red de larga duración. Para obtener más detalles, usaremos el panel Network (Red).

El panel de red

Al igual que el panel Performance (desempeño), el panel Network (Red) tiene muchas opciones disponibles para investigar y solucionar problemas. Aquí solo cubrimos algunas. Consulte los Recursos para profundizar más sobre lo que el panel Network (Red) tiene para ofrecer.

Registro de red

El panel Network (Red) registra toda la actividad de red en el registro de red.

Cada fila del registro de red representa un recurso. Los recursos están enumerados cronológicamente de primero a último de forma predeterminada. DevTools registra la actividad de red solo cuando está abierto.

Cada columna contiene información sobre un recurso.

• Name (Nombre): si hace clic en el nombre del recurso, aparecerán los detalles del recurso
• Status (Estado): código de respuesta de HTTP
• Type (Tipo): tipo de recurso
• Initiator (Iniciador): qué generó la solicitud del recurso
  Si hace clic en el iniciador, se abrirá el código fuente correspondiente.
• Time (Tiempo): cuánto tardó en ejecutar la solicitud
• Waterfall (En cascada): gráfico de las distintas etapas de la solicitud
  Pase el cursor sobre la opción para ver un desglose de la solicitud.

Inspeccionar detalles de respuesta

1. Seleccione la ficha Network (Red).
   

   Seleccione el filtro Fetch/XHR para ver solo las solicitudes XMLHttpRequest (XHR).

2. Haga clic en el nombre de recurso aura.ApexAction.execute=1 para abrir los detalles del recurso.
   Los detalles se abren y muestran la ficha que se seleccionó antes.
3. Haga clic en la ficha Response (Respuesta) para ver la respuesta recibida del servidor.
   

   La respuesta puede venir en distintos formatos. En este caso, es una respuesta JSON (JavaScriptObjectNotation) larga.

4. Haga clic en la ficha Timing (Tiempos) para ver un desglose de la actividad de la red.
   

   Observe Waiting for server response (Esperando respuesta del servidor) con la larga barra verde. Eso representa el tiempo de espera de la respuesta del servidor: el tiempo entre que el navegador solicita una página y la recepción del primer byte de información del servidor. En este caso, la espera de respuesta del servidor es 3,83 segundos.

5. Haga clic en la ficha Initiator (Iniciador) para ver la pila de llamadas de solicitud.
   DevTools filtra la vista inicial para mostrar únicamente los elementos más significativos (marcos), por ejemplo, las llamadas de más larga duración. Haga clic en el vínculo Show more frames (Mostrar más marcos) para ver todos los elementos de la pila de llamadas.
   
   Si observamos la pila, podemos ver que increaseNum llamó a longAsyncFetch en el archivo example1_IncreaseNumber.js.
6. En el panel Initiator (Iniciador), haga clic en el vínculo example1_IncreaseNumber.js para abrir el archivo example1_IncreaseNumber.js en el panel Sources (Fuentes).
   
   
   

   Los números de línea hacen referencia a las capturas de pantalla. Es posible que su código se haya compilado con distintos números de línea.

   Los elementos destacados en la columna de número de línea del código representan solo la hora en que el navegador se relacionó con la llamada, no la duración de la llamada. Es posible que tenga que desplazarse por la ventana del código para ver el método async longAsyncFetch.
   
   En la línea 84, el método increaseNum(event) llama a longAsyncFetch() con el operador await. Eso hace que JavaScript tenga que esperar la respuesta larga. De la misma manera, en el método longAsyncFetch() hay una llamada al método apex_generateJSONRecords_default usando await para esperar la respuesta antes de continuar.

Ahora sabemos que el motivo por el cual aumentar el número tarda tanto es que uno de los operadores de espera (o los dos) hacen que el código tenga que esperar la respuesta. Lo que tenemos que hacer es eliminar el operador await para que el proceso se pueda ejecutar en segundo plano o modificar el código de Apex para que se ejecute más rápido.

A continuación, veremos un problema de memoria del navegador del lado del cliente.

Recursos

• Desarrolladores de Chrome: Inspeccionar actividad de red
• Documentos web MDN: await
• Documentos web MDN: Tiempo hasta el primer byte