Making the Lightning Report Builder faster

Is the Lightning Report Builder not fast enough? We hear you and are making changes!

We’ve been hearing a lot of feedback from our customers that the Lightning report builder is slow. Sometimes it can take a while for the UI to respond after you add or change a column or filter. We understand how frustrating this can be and have been working on ways to make things easier.

With our Spring ’21 release, you can now build reports lightning fast!

We’re adding a ton of performance enhancements to the Lightning report builder for Spring ‘21. You’ll be able to quickly add, delete, and reorder fields and easily perform lots of other actions. On top of that, we’re reintroducing multi-select fields, which was a much-loved feature in Classic. You can now select multiple fields and drag them all into the Lightning report builder while building your report.

That’s good to know. Can you summarize the top issues?

We dug deep and conducted a bunch of customer interviews. Here’s how we categorize the top issues:

1. Inconsistent UI: When a user quickly removes more than one column, drags & drops a column and then removes another, or double-clicks or presses Enter on a field, the column panel doesn’t show the newly added column until the results of a query from the backend are rendered.
2. Unresponsiveness: Rendering the results of queries makes the UI unresponsive, which can make the report building process much slower.
3. Blocked Actions: When “update preview” is on and a change is made, a spinner shows up in the report view. Without additional feedback, the report builder just seems slow.
4. Unnecessary API Calls: In Spring ‘20, we added the ability to disable preview to reduce the need to update the report table on each action. But behind the scene, API calls were still being made, report data was still being fetched, and React was still processing the incoming data.

Ok. So, what’s the high level solution?

It’s a multi-faceted approach to solve this problem. This diagram explains it best.

#1: Async Report Builder: Currently, after you perform any action in the report builder, the entire UI is blocked until the query results are back and rendered. The async approach will allow users to continue to interact with the Lightning report builder and show a valid representation of the data even while queries are handled in the backend.

#2: Front End Performance Improvements: With Spring ‘20, we added the ability to “Disable Preview” when building reports. Now as part of phase 2 of Disable Preview 2.0, we are making this even faster by removing the need to retrieve report results on the server-side, subsequently reducing the amount of the data the frontend will need to process. Hence, improving rendering performance in the Lightning report builder.

#3: Multi-Select Fields: Similar to Classic, we’re giving users the ability to multi-select fields and then drag them all to the report.

Aha! What else is going on behind the scenes?

As part of our performance studies, we picked some customer orgs and analyzed how much time it took to load the report builder, load the app, run reports, execute scripts, and render the report. The overall experienced page time (EPT) is a combination of database time, API-only time, and UI time.

EPT: Experienced Page Time is a performance metric that measures how long it takes for a page to load into a state where the user can have a meaningful interaction.

DB Time: Database Time is the total time spent by user processes that are actively working on or waiting for database calls.

We explored profiling with internal Salesforce orgs to understand interaction performance for customers and estimate benefits from our changes. The optimizations have reduced the UI time by approximately 50% (as seen in our internal orgs. Some customers might see variations – Safe Harbor). Lightning report builder interactions such as add/delete column took about 6 seconds for each user action in preview disabled mode in a sub-par CPU machine. With the optimizations, this time has been reduced to approximately 3 seconds.

Is there something I can do to further enhance performance?

The DB time is dependent on individual reports and needs to be tuned on a case-by-case basis. Though these are overall improvements, performance also depends on your network and the type of reports you have. You may have additional opportunities for optimization and building more efficient reports. For guidance, check out the performance best practices document.

Great. This is exciting. What’s Next?

• Performance improvements on groupings and filters in the report builder
• Performance improvements for Joined Reports
• Content Delivery Network for Reports

Sign up for the pre-release and try it out today using this link. We are looking forward to hearing your feedback!

*Forward-looking statement

This content contains forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proved incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make.

Any unreleased services or features referenced in this document or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Written by