Solucionar problemas red

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

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

Solución de problemas de red de componentes web Lightning

El rendimiento, es decir, lo rápido que funciona un sitio, depende de muchos factores: los recursos del servidor, los recursos del cliente, la velocidad del navegador, etc. Muchos sitios solo tienen el tiempo de carga de las páginas para medir el rendimiento. En Salesforce, cuando medimos el rendimiento de Lightning, nos centramos en la experiencia del usuario. El tiempo de carga de página de la experiencia (EPT) es una métrica de rendimiento que ha definido Salesforce para medir cuánto tarda encargarse una página y estar lista para que un usuario interactúe con ella sin problemas.

La solución de problemas con el rendimiento de componentes web Lightning puede tener numerosas variantes. La métrica EPT es un indicador general del rendimiento de una página. Si quiere profundizar aún más en problemas de rendimiento, debe tener en cuenta tres áreas principales.

• El rendimiento de la red
• El rendimiento del navegador
• La complejidad y el nivel de personalización de la página

En este módulo, vamos a centrarnos en el rendimiento de la red y del navegador, sobre todo en la memoria del navegador.

Antes de comenzar

La mayoría de navegadores incluyen herramientas para desarrolladores con funciones similares. En este módulo nos centraremos en las herramientas de Chrome.

Se presupone que tiene configurado un entorno de desarrollo de Salesforce DX y que tiene experiencia utilizándolo para desarrollar componentes web Lightning e implementarlos en una organización. Si todavía no está familiarizado con este proceso, complete el proyecto Inicio rápido: Lightning Web Components antes de continuar con el módulo.

Para este módulo es necesario que tenga los conocimientos sobre Chrome DevTools que se presentan en la ruta Solución de problemas de red de componentes web Lightning. De hecho, si acaba de completar esas insignias, el Playground debería estar preparado con el código de GitHub necesario para este módulo. Siga estos pasos para confirmar que tiene el código más reciente de GitHub.

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

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

2. Pulse Control + Mayús + P (en Windows) o Comando + Mayús + P (en macOS) para abrir la Paleta de comandos.
3. Escriba git.
4. Seleccione Git: Pull.
5. En el directorio force-app/main/default, abra el directorio permissionsets.
6. Compruebe que está presente 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 código fuente en la organización).
9. Haga clic en View (Ver) | Terminal (Terminal).
10. Asigne el conjunto de permisos Bad Net Full Access (Acceso total a Bad Net) al usuario predeterminado mediante la ejecución del siguiente comando en el terminal:
    sf org assign permset --name Bad_Net_Full_Access.
11. Pase a la sección Empezar con un navegador vacío.

Configurar un entorno de solución de problemas

En primer lugar, si todavía no ha completado el módulo Solucionar problemas de components web Lightning, necesita configurar un Trailhead Playground con algunos components web Lightning y prepararlo para la solución de problemas de este módulo.

¿Listo para practicar con Lightning Web Components

No existe un reto práctico en este módulo, pero puede practicar los pasos en su Trailhead Playground. Haga lo siguiente para acceder a su Playground. Primero, asegúrese de iniciar 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. Si, por el contrario, quiere crear un nuevo Playground, haga clic en Create Playground (Crear Playground).

Activar el modo de depuración

Con este paso, la solución de problemas con el código es mucho más sencilla. Al tener activado el modo de depuración en la organización, el código no se minifica. De esta forma, los nombres de variables se conservan, así como la estructura general del código, por lo que es mucho más sencillo solucionar problemas.

1. En Setup (Configuración), escriba 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 descritas en el repositorio readme de GitHub.
2. En Visual Studio Code, asigne el conjunto de permisos Bad Net Full Access (Acceso total a Bad Net) al usuario predeterminado mediante la ejecución del siguiente comando en el terminal.
   sf org assign permset --name Bad_Net_Full_Access.

Ahora, su entorno está listo para solucionar problemas con Chrome DevTools.

Empezar con un navegador vacío

1. Abra un navegador Chrome.
2. Haga clic en la opción para personalizar y controlar Google Chrome () y seleccione Nueva ventana de incógnito. De esta forma, se asegura de que Chrome se ejecutará desde cero sin extensiones instaladas. Las extensiones pueden generar incoherencias a la hora de medir el rendimiento.
3. Abra su Trailhead Playground.
4. Asegúrese de que el modo de depuración esté activado para su usuario y que se muestra la métrica EPT debajo del banner del modo de depuración.
   
   

   También puede ver la métrica EPT con este sufijo de URL: ?eptVisible=1.

Solucionar problemas con un componente de respuesta lenta

1. Desde App Launcher (Iniciador de aplicación, ) del Trailhead Playground, busque y abra Bad Network.
2. En la aplicación Bad Network, haga clic en +1 para intentar aumentar el número varias veces.
   Esto tarda demasiado. Vamos a usar la ficha Performance (Rendimiento) de DevTools para empezar con la solución de problemas.
3. Haga clic con el botón derecho en la ventana del navegador y seleccione Inspeccionar (o haga clic en F12) para abrir DevTools.
4. Haga clic en el icono para personalizar y controlar DevTools () y seleccione el lado en el que quiere que se acoplen las herramientas. Undock into separate window (Anclar en otra ventana), Dock to left (Anclar a la izquierda), Dock to bottom (Anclara en la parte inferior) o Dock to right (Anclar a la derecha). En las imágenes de este módulo, DevTools está en una ventana independiente.

   

   Al tener DevTools en una ventana independiente, podrá acceder mejor a todos los datos durante la solución de problemas.

5. En el menú de DevTools, seleccione la pestaña Performance (Rendimiento).
6. En el menú Performance (Rendimiento), haga clic en el icono Record (Grabar, ) para empezar a grabar un perfil.
7. En la aplicación Bad Network, haga clic en +1 para volver a aumentar el número.
   Espere que el número cambie.
8. En el panel Performance (Rendimiento), haga clic en Stop (Detener) para finalizar la grabación y dejar que se compilen y aparezcan los datos en el panel en forma de línea de tiempo.

Analicemos los datos de rendimiento

1. Observe la larga línea azul en el gráfico de línea de tiempo de la red debajo de los gráficos de FPS y la CPU.
   
2. Expanda la sección Network (Red) a la izquierda. Observe la llamada de Aura que empezó entre los 2000 ms y los 2500 ms, y que coincide con la línea azul de la sección del gráfico de la red.
   
3. Desplace el cursor por la llamada de Aura para ver la información solicitada.
   

   Fíjese en la marca de hora (2,90 segundos en este caso) y en el nombre de la solicitud.

El panel Performance (Rendimiento) nos ha llevado a este momento concreto para mostrarnos la solicitud prolongada de red. Para obtener más información, usaremos el panel Network (Red).

El panel Network (Red)

Al igual que el panel Performance (Rendimiento), el panel Network (Red) contiene numerosas opciones para investigar y solucionar problemas. Solo hablaremos de unas cuantas. Consulte la sección Recursos para profundizar en lo que ofrece el panel Network (Red).

Registro de la red

En Network Log (Registro de la red) del panel Network (Red) se registra toda la actividad de la red.

Cada fila del registro de la red representa un recurso. De forma predeterminada, los recursos aparecen en orden cronológico desde el primero hasta el último. DevTools solo registra la actividad de la red cuando está abierto.

Cada columna contiene información sobre un recurso.

• Name (Nombre): al hacer clic en el nombre del recurso, aparecen sus detalles.
• Status (Estado): código de respuesta HTTP
• Type (Tipo): tipo de recurso
• Initiator (Iniciador): lo que generó la solicitud del recurso
  Al hacer clic en el iniciador, se abre el código fuente correspondiente.
• Time (Tiempo): cuánto tiempo se ejecutó la solicitud
• Waterfall (Evolución): gráfico con las diferentes etapas de la solicitud
  Desplace el cursor para ver un desglose de la solicitud.

Inspeccionar los detalles de una respuesta

1. Seleccione la pestaña Network (Red).
   

   Seleccione el filtro Fetch/XHR (Obtener/XHR) para ver únicamente las solicitudes de tipo XMLHttpRequest (XHR).

2. Haga clic en el nombre de recurso aura.ApexAction.execute=1 para abrir los detalles del recurso.
   Se abren los detalles del recurso y se muestra la pestaña seleccionada anteriormente.
3. Haga clic en la pestaña Response (Respuesta) para ver la respuesta recibida desde el servidor.
   

   La respuesta puede aparecer en un par de formatos distintos. En este caso, es una respuesta JSON grande (JavaScriptObjectNotation).

4. Haga clic en la pestaña Timing (Cronología) para ver un desglose de la actividad de la red.
   

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

5. Haga clic en la pestaña Initiator (Iniciador) para ver la pila de llamadas de solicitud.
   DevTools filtra la vista inicial para mostrar únicamente los elementos (fotogramas) más significativos, como las llamadas de ejecución más largas. Haga clic en el vínculo Show more frames (Mostrar más fotogramas) para ver todos los elementos de la pila de llamadas.
   
   Si observamos la pila, veremos que increaseNum hizo una llamada 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 (Orígenes).
   
   
   

   Los números de línea hacen referencia a las capturas de pantalla. El código puede compilarse con distintos números de línea.

   Los tiempos resaltados en la columna de número de línea del código representan solo el tiempo en el que el navegador estuvo ocupado con la llamada, no la duración de la llamada en sí. Es posible que tenga que desplazarse por la ventana del código para ver el método async longAsyncFecth.
   
   En la línea 84, el método increaseNum(event) llama a longAsyncFetch() con un operador de tipo await. Esto provoca que el código JavaScript tenga que esperar a la respuesta larga. De forma similar, en el método longAsyncFetch() hay una llamada al método apex_generateJSONRecords_default con el operador await para esperar la respuesta antes de seguir.

Ahora sabemos que el motivo por el que se tarda tanto en aumentar el número es que uno de los operadores "await" (o los dos) provoca que el código espere una respuesta. Tenemos que eliminar el operador await para que el proceso se pueda ejecutar en segundo plano, o bien modificar el código Apex para que se ejecute más rápido.

Vamos a analizar a continuación un problema de memoria del navegador en el cliente.

Recursos

• Desarrolladores de Chrome: Inspect network activity (Inspeccionar la actividad de la red)
• MDN Web Docs: await
• MDN Web Docs: Time to first byte (Tiempo de espera hasta el primer byte)