Skip to main content

Identify Performance Issues in the Bad Bunch App

Learning Objectives

After completing this unit, you’ll be able to:

  • Demonstrate different ways to throttle the performance.
  • Use the Performance monitor to locate DOM node issues.

Excessively Expensive Event Calls

In the previous unit, we troubleshooted a poorly performing Lightning web component with bad placement of code in a loop. Let’s take a look at another bad example and how to troubleshoot it.

  1. With the Bad Bunch app open, select Example 2: Scroll List and wait for the page to load completely.
  2. In the DevTools Performance panel, click Record to start a profile recording.
  3. Now scroll the list under Scroll This List!

    Example 2: Scroll List with the list scrolled down.

    It should seem a bit slow or jerky.

  4. In the Performance panel, click Stop to end the recording and let it compile the data.

    Performance panel showing multiple events called.

    Look in the Main section at all those JavaScript events getting called. And notice all the little red triangles.

    Performance panel with an event highlighted.

    The red triangle is Chrome’s way of saying this may have taken too long.

  5. Move down the call stack and click one of the onScroll events to get the details in the Summary tab.

    Summary panel with the highlighted event details and link to the function in the code.

    Notice this is coming from our code, the onScroll method in the example2_ScrollList.js file. On line 87, to be exact.

  6. In the Summary panel, click the link to example2_ScrollList.js to go to the Sources panel with the code displayed.

    Sources displaying the example2_ScrollList.js file with timestamps next to the line numbers.

    Look at line 82: = ‘#edede’;.

    We are adding styling with code with every scroll. This is something that should be handled a different way. It adds a lot of overhead to the event. There are CSS (Cascading Style Sheets) pseudo-classes like tr:nth-child(even) and tr:nth-child(odd) for this exact purpose. A CSS approach will always be faster than using JavaScript.

    Another issue here is the lack of a debouncer to keep the event from firing so often. Adding a listener to a scroll event will cause it to fire a ton. If that event is doing expensive operations, it is even worse. Check the Resources for more info on this.



    In Chrome, the scroll event fires once per frame during scrolling, that is, once every 16.7ms on a 60FPS screen. Safari fires even faster (which actually violates the spec).

Rendering Recalculated Styles

  1. With the Bad Bunch app open, select Example 3: Input Fields.

    For this example, you may need to throttle the CPU.

  2. In Capture Settings (), for CPU, select 4x slowdown to demonstrate a slower browser.

    Performance panel showing CPU set to 4x slowdown with a warning indicator next to the Performance tab and a red Capture Settings icon.

    Notice the warning icon next to Performance and the red Capture Settings icon set as reminders that the screen is throttled. Throttling is relative to your computer’s capabilities. For example, the 4x slowdown option makes your CPU operate 4 times slower than its usual ability.

  3. In the DevTools Performance panel, click Record.
  4. Start typing in Input #1.

    Example 3: Input Fields with text being typed into Input #1.

    A jarring experience, not smooth at all.

  5. Start typing in Input #2. Much smoother.
  6. In the Performance panel, click Stop to end the recording and let it compile the data.

    Performance panel showing multiple events called with a lot of purple displayed in the CPU chart section.

    The CPU chart displays a lot of purple. Checking in the Summary tab shows that purple represents Rendering. A majority of the time is going to Rendering. There’s a lot of red triangles too.

    Let’s zoom in on just a small section. But first, let’s turn off the CPU throttling.

  7. In Capture Settings (), turn the CPU throttling off.

    It’s a good practice to turn off any throttling as soon as you are done using it since it continues to throttle even when the recording has stopped.

  8. Click and drag your mouse through a small section of the CPU chart.

    Performance panel showing a zoomed-in section of the events displaying a large purple Recalculate Style block.

    Look at the large Recalculate Style block. Something is causing an expensive recalculation of the CSS styles.

  9. Click one of the onSlowInput events to get the details in the Summary panel.

    Summary panel with link to example3_InputFields.js.

  10. In the Summary panel, click the example3_InputFields.js link to open it in the Sources panel.

    Sources panel displaying exampe3_InputFields.js with the onSlowInput onFastInput, and block methods.

    The onSlowInput method makes a call to the block method. The block method is rendering a bunch of divs with randomized sizes causing the styles to be recalculated. That’s a problem.

    The onFastInput method, line 166, is called from Input #2 field. It also makes a call to the block call but only after it is debounced. This shows how debounce helps. The best practice would be to use the debounce and update the block method to not cause the recalculation.

DOM Node Explosion

This next example can cause your browser to freeze. You can use the Task Manager mentioned in the first unit to start over.

  1. With the Bad Bunch app open, select Example 4: Table tab.

    If your browser freezes, use the Chrome Task Manager to End Process and start over.

    Example 4: Table displayed with lots of data in a table.

    That’s a lot of data, but it should load quicker. Let’s record a profile as the page loads.

  2. Click Example 3: Input Fields to move off this tab.
  3. In the DevTools Performance panel, click Record.
  4. Now click Example 4: Table.
    Wait for it to load.
  5. In the Performance panel, click Stop to end the recording and let it compile the data.

    Performance panel showing profile recording.

    If you take multiple profile recordings, switch between recordings in the Performance menu.

    Performance panel menu showing multiple recordings.

    Scrolling down in the Main section call stack will lead to a renderedCallback event that looks like it ran multiple times but actually ran once.

  6. Click the renderedCallback event to get the details in the Summary panel.

    Event renderedCallback is highlighted and its details are displayed in the Summary tab.

  7. In the Summary panel, click the example4_Table.js link to open it in the Sources panel.

    Sources panel displaying exampe4_Table.js with the renderedCallback method.

    There is a lot going on in this method. Digging in reveals that there’s a bunch of divs being created. Let’s look at another way to see this.

  8. Back on the Example 4: Table tab, right click in one of the table cells and select Inspect.

    The Elements panel in DevTools opens to display the HTML markup of the table cell.

    DevTools Elements panel showing a massive div tree.

    Now that’s a bunch of div tags. And that is just one of the table cells.

    Let’s use the Performance monitor for a better way to look at this.

  9. In DevTools, click Customize and control DevTools to expand the menu. Then click More tools and then Performance monitor.

    Menu tree from Customize and control DevTools showing More tools and Performance monitor links.

    The Performance monitor appears at the bottom of DevTools. The Performance monitor shows a real-time view of various aspects of a page’s load or runtime performance like CPU usage, JavaScript heap size, the total number of DOM nodes, and so on.

    DevTools with the Performance monitor open.

    Take a look at the DOM Nodes! Over 400k nodes. Let’s see what this looks like on page load.

  10. In the Performance monitor unselect JS heap size and JS event listeners.
  11. Reload the page and watch the DOM nodes increase.

This is a possible issue for information-heavy pages. Not just data tables. This can become an issue with how Lightning Web Components are built and wired up. Components within components within components or components that dynamically generate other components or large numbers of HTML tags can add a lot of DOM nodes to the layout.

We have explored several ways of looking for performance issues with Lightning Web Components and even just Lightning pages in general. You now have new tools for your toolbelt and are better equipped to tackle performance problems.


Keep learning for
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities