Skip to main content
Únase a nosotros en TDX, en San Francisco, o en Salesforce+ los días 5 y 6 de marzo en la conferencia para desarrolladores sobre la era de agentes de IA. Registrarse ahora.

Identificar problemas de rendimiento en la aplicación Bad Bunch

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Describir varias maneras de regular el rendimiento.
  • Utilizar Performance Monitor (Monitor de rendimiento) para localizar los problemas con nodos DOM.

Llamadas de eventos demasiado costosas

En la unidad anterior, resolvimos un problema con un componente web Lightning que no rendía bien porque el código estaba mal ubicado en un bucle. Veamos otro ejemplo de error y cómo solucionarlo.

  1. Con la aplicación Bad Bunch abierta, seleccione Example 2: Scroll List (Ejemplo 2: desplazarse por una lista) y espere a que la página se cargue completamente.
  2. En el panel Performance (Rendimiento) de DevTools, haga clic en Registro para empezar a grabar un perfil.
  3. Desplácese por la lista hasta Scroll This List! (¡Desplácese por esta lista).
    Ejemplo 2: desplazarse por una lista después de desplazarse hasta el final.
    Lo normal es que vaya un poco lento o se atasque.
  4. En el panel Performance (Rendimiento), haga clic en Stop (Detener) para finalizar la grabación y dejar que se compilen los datos.
    Panel Performance (Rendimiento) con llamadas a muchos eventos.
    Consulte en la sección Main (Principal) todos los eventos de JavaScript a los que se está llamando. Observe también los pequeños triángulos rojos.
    Panel Performance (Rendimiento) con un evento resaltado.
    El triángulo rojo es la forma que tiene Chrome de indicar que un proceso ha tardado demasiado.
  5. Desplácese hacia abajo por la pila de llamadas y haga clic en un evento onScroll para ver los detalles en la ficha Summary (Resumen).
    Panel Summary (Resumen) con la información del evento resaltada y un vínculo a la función del código.
    Observe que esto procede de nuestro código, el método onScroll del archivo example2_ScrollList.js. De la línea 87, para ser más exactos.
  6. En el panel Summary (Resumen), haga clic en el vínculo del archivo example2_ScrollList.js para ir al panel Sources (Orígenes) donde se ve el código.
    El panel Sources (Orígenes) donde se ve el archivo example2_ScrollList.js con marcas de tiempo junto a los números de línea.
    Mire la línea 82: li.style.background = ‘#edede’;.

    Cada vez que nos desplazamos, agregamos estilo mediante código. Esto es algo que se debería gestionar de otra forma. Sobrecarga demasiado el evento. Hay seudoclases CSS (Cascading Style Sheets) como tr:nth-child(even) y tr:nth-child(odd) para este fin. Siempre será más rápido emplear un enfoque de CSS que usar JavaScript.

    Otro problema es que no hay una herramienta de retraso (de tipo "debounce") para impedir que el evento se active tan a menudo. Si se agrega una escucha a un evento de desplazamiento, esta se activará millones de veces. Si el evento ejecuta operaciones demasiado costosas, esto es todavía peor. Compruebe la sección Resources (Recursos) para obtener más información.
Nota

En Chrome, el evento de desplazamiento se activa una vez por fotograma durante el desplazamiento, es decir, una vez cada 16,7 ms en una pantalla de 60 f/s. Safari los activa incluso con más rapidez (algo que, de hecho, hace que no se cumplan las especificaciones).

Renderización de estilos recalculados

  1. Con la aplicación Bad Bunch abierta, seleccione Example 3: Input Fields (Ejemplo 3: campos de entrada).
    En este caso, es posible que necesite regular la CPU.
  2. En Capture Settings (Configuración de captura) (), en CPU, seleccione 4x slowdown (Ralentización x4) para ver el navegador a una velocidad más lenta.
    El panel Performance (Rendimiento) con la CPU establecida en una ralentización x4 y un indicador de advertencia junto a la ficha Performance (Rendimiento), además de un icono rojo en Capture settings (Configuración de captura).
    Observe que el icono de advertencia junto a Performance (Rendimiento) y el icono rojo de Capture settings (Configuración de captura) sirven de recordatorio de que la pantalla se ha regulado. La limitación del ancho de banda depende de las capacidades de su equipo. Por ejemplo, la opción de ralentización x4 hace que la CPU funcione 4 veces más lento de lo normal.
  3. En el panel Performance (Rendimiento) de DevTools, haga clic en Registro.
  4. Empiece a escribir en Input #1 (Entrada 1).
    Ejemplo 3: campos de entrada, donde vemos cómo se escribe texto en Input #1 (Entrada 1).
    Es una experiencia bastante incómoda, nada fluida.
  5. Empiece a escribir en #Input 2 (Entrada 2). Ahora va mucho mejor.
  6. En el panel Performance (Rendimiento), haga clic en Stop (Detener) para finalizar la grabación y dejar que se compilen los datos.
    El panel Performance (Rendimiento) con llamadas a muchos eventos y un montón de morado en la sección del gráfico de la CPU.
    En el gráfico de la CPU se un montón de morado. Al consultar la ficha Summary (Resumen), se ve que el morado representa la renderización. La mayoría del tiempo el proceso va a ser de renderización. También hay muchos triángulos rojos.
    Vamos a ampliar una sección pequeña. Pero primero, vamos a desactivar la regulación de la CPU.
  7. En Capture settings (Configuración de captura, ), desactive la regulación de la CPU.
    La práctica recomendada es desactivar cualquier tipo de regulación en cuanto acabe de usarla porque si no continuará ejecutándose aunque se haya detenido la grabación.
  8. Haga clic y arrastre el ratón por una sección pequeña del gráfico de la CPU.
    Panel Performance (Rendimiento) con una sección ampliada de los eventos donde se ve un gran bloque morado de recálculo de estilo.
    Mire el gran bloque de Recalculate Style (Recalcular estilo). Algo está provocando que haya un recálculo muy costoso de las hojas de estilo CSS.
  9. Haga clic en uno de los eventos onSlowInput para obtener los detalles en el panel Summary (Resumen).
    Panel Summary (Resumen) con un vínculo al archivo example3_InputFields.js.
  10. En el panel Summary (Resumen), haga clic en el vínculo example3_InputFields.js para abrir el archivo en el panel Sources (Orígenes).
    Panel Sources (Orígenes) donde vemos el archivo exampe3_InputFields.js con onSlowInput y onFastInput, así como los métodos del bloque.
    El método onSlowInput realiza una llamada al método del bloque. El método del bloque renderiza un conjunto de componentes "div" con tamaños aleatorios que hacen que los estilos se vuelvan a calcular. Eso es un problema.
    Desde el campo Input #2 (Entrada 2) se llama al método onFastInput de la línea 166. Además, también se realiza una llamada al bloque, pero solo después de que tenga lugar el retraso. Esto demuestra lo útil que es el componente "debounce". La práctica recomendada sería usar el componente y actualizar el método del bloque para que no tenga lugar el recálculo.

Explosión de nodos DOM

El siguiente ejemplo puede provocar que el navegador se bloquee. Puede usar el Administrador de tareas que mencionamos en la primera unidad para empezar de cero.

  1. Con la aplicación Bad Bunch abierta, seleccione Example 4: Table (Ejemplo 4: tabla).
    Si el navegador se bloquea, utilice el Administrador de tareas de Chrome para finalizar procesos y empezar de nuevo.
    Ejemplo 4: Table (Ejemplo 4: tabla) con muchos datos en una tabla.
    Son muchos datos, pero se deben cargar rápido. Vamos a registrar un perfil mientras se carga la página.
  2. Haga clic en Example 3: Input Fields (Ejemplo 3: campos de entrada) para salir de esta ficha.
  3. En el panel Performance (Rendimiento) de DevTools, haga clic en Registro.
  4. Ahora haga clic en Example 4: Table (Ejemplo 4: tabla).
    Espere a que se cargue.
  5. En el panel Performance (Rendimiento), haga clic en Stop (Detener) para finalizar la grabación y dejar que se compilen los datos.
    Panel Performance (Rendimiento) con la grabación del perfil.
    Si ha realizado distintas grabaciones de perfiles, puede cambiar entre grabaciones desde el menú Performance (Rendimiento).
    Panel Performance (Rendimiento) con múltiples grabaciones.
    Si se desplaza hacia abajo hasta la pila de llamadas de la sección Main (Principal), se ejecutará un evento renderedCallback que parece que se ha ejecutado muchas veces, pero, en realidad, solo se ha ejecutado una.
  6. Haga clic en el evento renderedCallback para obtener los detalles en el panel Summary (Resumen).
    El evento renderedCallback aparece resaltado y se muestran sus detalles en la ficha Summary (Resumen).
  7. En el panel Summary (Resumen), haga clic en el vínculo example4_Table.js para abrir el archivo en el panel Sources (Orígenes).
    Panel Sources (Orígenes) donde vemos el archivo exampe4_Table.js con el método renderedCallback.
    Ocurren muchas cosas en este método. Al investigar, vemos que se están creando un montón de componentes "div". Vamos a ver otra forma de consultarlo.
  8. Vuelva a la ficha Example 4: Table (Ejemplo 4: tabla), haga clic con el botón derecho en una de las celdas de la tabla y seleccione Inspect (Inspeccionar).
    Se abre el panel Elements (Elementos) de DevTools para mostrar el marcado HTML de la celda de la tabla.
    Panel Elements (Elementos) de DevTools donde se ven muchísimos árboles de componentes "div".
    Esas son un montón de etiquetas "div". Y eso solo para una de las celdas de la tabla.
    Vamos a usar Performance monitor (Monitor de rendimiento) para ver mejor todo esto.
  9. En DevTools, haga clic en Personalizar y controlar DevTools para expandir el menú. Luego haga clic en More tools (Más herramientas) y en Performance monitor (Monitor de rendimiento).
    Árbol de menú para personalizar y controlar DevTools donde se ven los vínculos de More tools (Más herramientas) y Performance monitor (Monitor de rendimiento).
    Aparece el monitor de rendimiento en la parte inferior de DevTools. En Performance monitor (Monitor de rendimiento) aparece una vista en tiempo real de distintos aspecto de la carga o el rendimiento del tiempo de ejecución de una página, como el uso de la CPU, el tamaño de la pila de JavaScript, el total de nodos DOM, etc.
    DevTools con el monitor de rendimiento abierto.
    ¡Fíjese en los nodos DOM! Más de 400 000 nodos. Veamos cómo se ve esto cuando se carga la página.
  10. En el monitor de rendimiento, anule la selección del tamaño de la pila de JS y la escucha de eventos de JS.
  11. Vuelva a cargar la página y observe cómo aumentan los nodos DOM.

Este problema suele darse en páginas donde hay mucha información, no solo tablas de datos. Esto puede ser un verdadero problema a la hora de crear y entrelazar componentes web Lightning. Los componentes dentro de otros componentes o los que generan de forma dinámica otros componentes o un gran número de etiquetas HTML pueden agregar muchos nodos DOM al formato.

Hemos visto distintas maneras de buscar problemas de rendimiento con componentes web Lightning e incluso páginas Lightning en general. Ahora tiene nuevas herramientas y está mejor equipado para enfrentarse a problemas de rendimiento.

Recursos

Comparta sus comentarios sobre Trailhead en la Ayuda de Salesforce.

Nos encantaría conocer su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios cuando quiera desde el sitio de la Ayuda de Salesforce.

Más información Continuar para compartir comentarios