If any such uncertainties materialize or if any of the assumptions proved incorrect, the results of, inc. This content contains forward-looking statements that involve risks, uncertainties, and assumptions. We are looking forward to hearing your feedback! Sign up for the pre-release and try it out today using this link.
Performance improvements for Joined Reports. Performance improvements on groupings and filters in the report builder. For guidance, check out the performance best practices document. You may have additional opportunities for optimization and building more efficient reports. Though these are overall improvements, performance also depends on your network and the type of reports you have. The DB time is dependent on individual reports and needs to be tuned on a case-by-case basis. Is there something I can do to further enhance performance? With the optimizations, this time has been reduced to approximately 3 seconds. 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. Some customers might see variations – Safe Harbor). The optimizations have reduced the UI time by approximately 50% (as seen in our internal orgs. We explored profiling with internal Salesforce orgs to understand interaction performance for customers and estimate benefits from our changes. The overall experienced page time (EPT) is a combination of database time, API-only time, and UI time.ĮPT: 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.ĭB Time: Database Time is the total time spent by user processes that are actively working on or waiting for database calls. Aha! What else is going on behind the scenes?Īs 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. #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. Hence, improving rendering performance in the Lightning report builder. 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. #2: Front End Performance Improvements: With Spring ‘20, we added the ability to “Disable Preview” when building reports. 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. #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. It’s a multi-faceted approach to solve this problem. But behind the scene, API calls were still being made, report data was still being fetched, and React was still processing the incoming data. SALESFORCE REPORT BUILDER UPDATE
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.Without additional feedback, the report builder just seems slow.
Blocked Actions: When “update preview” is on and a change is made, a spinner shows up in the report view.
Unresponsiveness: Rendering the results of queries makes the UI unresponsive, which can make the report building process much slower. 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. 
We dug deep and conducted a bunch of customer interviews.
0 kommentar(er)
