Skip to main content
Únase a nosotros en TDX, San Francisco o en Salesforce+ del 5 al 6 de marzo en la conferencia de desarrolladores para la era del agente de la IA. Regístrese ahora.

Identificar problemas de desempeño en la aplicación Bad Bunch

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Demostrar diferentes formas de regular el desempeño.
  • Usar el monitor de desempeño para ubicar problemas del nodo DOM.

Llamadas de evento demasiado costosas

En la unidad anterior, solucionamos problemas de un componente web Lightning con mal desempeño y mala ubicación del código en un bucle. Veamos otro mal ejemplo y la forma de solucionar el problema.

  1. Con la aplicación Bad Bunch abierta, seleccione Example 2: Scroll List (Ejemplo 2: Desplácese por la lista) y espere que la página se cargue por completo.
  2. En el panel DevTools Performance (Desempeño de DevTools), haga clic en Registro para empezar a registrar un perfil.
  3. Ahora desplácese por la lista en Scroll This List! (Desplazarse por la lista).
    Example 2: Scroll List (Ejemplo 2: Desplácese por la lista) con la lista desplazada hacia abajo.
    Debería ser un poco lento o entrecortado.
  4. En el panel Performance (Desempeño), haga clic en Stop (Detener) para finalizar el registro y permitir que se compilen los datos.
    Panel Performance (Desempeño) mostrando múltiples eventos llamados.
    Busque en la sección Main (Principal) todos los eventos de JavaScript que se están llamando. Observe los pequeños triángulos rojos.
    Panel Performance (Desempeño) con un evento resaltado.
    Es la forma que tiene Chrome de indicar que el proceso podría estar tardando demasiado.
  5. Baje por la pila de llamadas y haga clic en los eventos onScroll para obtener los detalles en la ficha Summary (Resumen).
    Panel Summary (Resumen) con los detalles del evento resaltado y un vínculo a la función en el código.
    Como verá, provienen de nuestro código, el método onScroll en el archivo example2_ScrollList.js. En la línea 87, para ser precisos.
  6. En el panel Summary (Resumen), haga clic en el vínculo a example2_ScrollList.js para ir al panel Sources (Fuentes) y visualizar el código.
    Fuentes mostrando el archivo example2_ScrollList.js con marcas de tiempo junto a los números de línea.
    Observe la línea 82: li.style.background = ‘#edede’;.

    Con cada desplazamiento, agregamos estilos con código. Esto es algo que se debería manejar de otra manera. Le agrega demasiada sobrecarga al evento. Existen pseudoclases de CSS (hojas de estilo en cascada), como tr:nth-child(even) y tr:nth-child(odd) para este propósito en particular. Un enfoque de CSS siempre será más rápido que usar JavaScript.

    Otro problema que hay aquí es la falta de un controlador de frecuencia de eventos para evitar que el evento se active tan a menudo. Agregar un agente de escucha a un evento de desplazamiento generará la activación de una enorme cantidad. Si ese evento realiza operaciones costosas, es peor aún. Consulte la sección Recursos para obtener más información al respecto.
Nota

En Chrome, el evento de desplazamiento se activa una vez por marco durante el desplazamiento; es decir, una vez cada 16.7 ms en una pantalla de 60 FPS. En Safari se activa más rápido todavía (lo cual no respeta la especificación).

Representación de estilos recalculados

  1. Con la aplicación Bad Bunch abierta, seleccione Example 3: Input Fields (Ejemplo 3: Campos de entrada).
    Para este ejemplo, es probable que necesite regular la CPU.
  2. En Capture Settings (Configuración de captura) (), para CPU, seleccione 4x slowdown si quiere mostrar un navegador más lento.
    Panel Performance (Desempeño) mostrando la CPU configurada en 4x slowdown (Reducir la velocidad 4 veces) con un indicador de advertencia junto a la ficha Performance (Desempeño) y un ícono Capture Settings (Configuración de captura) color rojo.
    Observe el ícono de advertencia junto a Performance (Desempeño) y el ícono rojo de Capture Settings (Configuración de captura) configurados como recordatorios de que la pantalla está regulada. La regulación se relaciona con las capacidades de su computadora. Por ejemplo, la opción 4x slowdown (Reducir la velocidad 4 veces) hace que su CPU funcione 4 veces más lento que su capacidad habitual.
  3. En el panel DevTools Performance (Desempeño de DevTools), haga clic en Registro.
  4. Para empezar, escriba Input #1 (Entrada n.º 1).
    Example 3: Input Fields (Ejemplo 3: Campos de entrada) con el comienzo de escritura en Input #1 (Entrada n.º 1).
    Es una experiencia compleja, para nada fluida.
  5. Comience a escribir en Input #2 (Entrada n.º 2). Mucho más fluido.
  6. En el panel Performance (Desempeño), haga clic en Stop (Detener) para finalizar el registro y permitir que se compilen los datos.
    Panel Performance (Desempeño) mostrando múltiples eventos llamados con mucho color morado visualizado en la sección del gráfico de CPU.
    El gráfico de CPU muestra mucho en color púrpura. Si consultamos la ficha Summary (Resumen), vemos que el color morado indica Rendering (Representación). Gran parte del tiempo se destina a la representación. También hay muchos triángulos de color rojo.
    Ampliemos solo una pequeña sección. Sin embargo, primero, desactivemos la regulación de la CPU.
  7. En Capture Settings (Configuración de captura) (), desactive la regulación de la CPU.
    Recomendamos desactivar toda regulación en cuanto termine de usarla, ya que continúa ejecutándose incluso cuando ya se detuvo el registro.
  8. Haga clic y arrastre el mouse por una sección pequeña del gráfico de CPU.
    Panel Performance (Desempeño) mostrando la vista ampliada de una sección de eventos que muestra un bloqueo grande morado Recalculate Style (Recalcular estilo).
    Observe el bloque grande Recalculate Style (Recalcular estilo). Algo está ocasionando un nuevo cálculo costoso de los estilos CSS.
  9. Haga clic en uno de los eventos onSlowInput para obtener los detalles en el panel Summary (Resumen).
    Panel Summary (Resumen) con el vínculo hacia example3_InputFields.js.
  10. En el panel Summary (Resumen), haga clic en el vínculo example3_InputFields.js para abrirlo en el panel Sources (Fuentes).
    Panel Sources (Fuentes) mostrando exampe3_InputFields.js con los métodos onSlowInput onFastInput y de bloqueo.
    El método onSlowInput hace una llamada al método de bloqueo. El método de bloqueo representa unos cuantos elementos div de tamaños aleatorios que hacen que los estilos se tengan que recalcular. Eso es un problema.
    El método onFastInput, línea 166, es llamado desde el campo Input #2 (Entrada n.º 2). También realiza una llamada a la llamada de bloqueo, pero solo después de pasar por el controlador de frecuencia de eventos. Esto muestra cómo ayuda ese controlador. La práctica recomendada sería usar el controlador de frecuencia de eventos y actualizar el método de bloqueo para evitar ocasionar el nuevo cálculo.

Explosión del nodo DOM

El siguiente ejemplo puede hacer que el navegador quede inmovilizado. Puede usar el Administrador de tareas mencionado en la primera unidad para volver a empezar.

  1. Con la aplicación Bad Bunch abierta, seleccione la ficha Example 4: Table (Tabla).
    Si el navegador queda inmovilizado, finalice el proceso con el Administrador de tareas de Chrome y empiece de nuevo.
    Example 4: Table (Ejemplo 4: Tabla) visualizado con muchos datos en una tabla.
    Son muchos datos, pero deberían cargarse rápido. Registremos un perfil mientras se carga la página.
  2. Haga clic en Example 3: Input Fields (Ejemplo 3: Campos de entrada) para mover esta ficha.
  3. En el panel DevTools Performance (Desempeño de DevTools), haga clic en Registro.
  4. Ahora, haga clic en Example 4: Table (Ejemplo 4: Tabla).
    Espere que se cargue.
  5. En el panel Performance (Desempeño), haga clic en Stop (Detener) para finalizar el registro y permitir que se compilen los datos.
    Panel Performance (Desempeño) mostrando el registro de perfiles.
    Si registra varios perfiles, puede cambiar entre un registro y otro en el menú Performance (Desempeño).
    Menú del panel Performance (Desempeño) mostrando varios registros.
    Al desplazarse por la pila de llamadas de la sección Main (Principal), parecerá que un evento renderedCallback se ejecutó varias veces, aunque en realidad lo hizo una sola vez.
  6. Haga clic en el evento renderedCallback para obtener los detalles en el panel Summary (Resumen).
    El evento renderedCallback está resaltado y se muestran los detalles en la ficha Summary (Resumen).
  7. En el panel Summary (Resumen), haga clic en el vínculo example4_Table.js para abrirlo en el panel Sources (Fuentes).
    Panel Sources (Fuentes) mostrando exampe4_Table.js con el método renderedCallback.
    Están pasando muchas cosas en este método. Si profundiza descubrirá que se están creando unos cuantos elementos div. Analicemos otra manera de visualizarlo.
  8. Nuevamente en la ficha Example 4: Table (Tabla), haga clic con el botón secundario en una celda de la tabla y seleccione Inspect (Inspeccionar).
    Se abre el panel Elements (Elementos) en DevTools y muestra el marcado HTML de la celda de la tabla.
    Panel DevTools Elements (Elementos DevTools) mostrando un árbol de elementos div enorme.
    Ahora verá muchas etiquetas div. Esa es solo una de las celdas de la tabla.
    Usemos el monitor de desempeño para verlo de una mejor manera.
  9. En DevTools, haga clic en Customize and control DevTools (Personalizar y controlar DevTools) para expandir el menú. Luego, haga clic en More tools (Más herramientas) y en Performance monitor (Monitor de desempeño).
    Árbol de menú de Customize and control DevTools (Personalizar y controlar DevTools) mostrando los vínculos de More tools (Más herramientas) y Performance monitor (Monitor de desempeño).
    Aparecerá en la parte inferior de DevTools. El monitor de desempeño muestra una vista en tiempo real de distintos aspectos del desempeño de carga de una página o del tiempo de ejecución, como el uso de CPU, el tamaño de pila de JavaScript, la cantidad total de nodos DOM y mucho más.
    DevTools con el monitor de desempeño abierto.
    Observe los nodos DOM. Más de 400 000 nodos. Veamos qué aspecto tiene esto al cargar una página.
  10. En el monitor de desempeño, anule la selección de las opciones JS heap size (Tamaño de pila de JS) y JS event listeners (Agentes de escucha de evento de JS).
  11. Vuelva a cargar la página y observe cómo aumenta la cantidad de nodos DOM.

Esto es un posible problema para las páginas que tienen mucha información. No son simples tablas de datos. Esto puede convertirse en un problema según cómo estén desarrollados y conectados los componentes web Lightning. Los componentes dentro de componentes dentro de componentes o los componentes que generan dinámicamente otros componentes o grandes cantidades de etiquetas HTML pueden agregar muchos nodos DOM al formato.

Hemos explorado varias maneras de buscar problemas de desempeño con componentes web Lightning e incluso solo páginas Lightning en general. Ahora cuenta con herramientas nuevas en su lista de herramientas y está mejor equipado para abordar problemas de desempeño.

Recursos

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios