Over the past year, many Salesforce teams have focused on improving Lightning Experience performance. Our teams have been going over performance traces that power all the fantastic workflows that Trailblazers use to drive innovation in businesses worldwide. And there is some good news to report!

With this blog post, we celebrate one year of dedicated focus on improving the user experience for Lightning. We share the improvements that we’ve implemented and give you an outlook on what to expect in 2024.

As we’ve done in previous blog posts in this series, we’ll provide a few deeper dives into certain improvements, demonstrating our principal ideas and motivations. Let’s get started!

Prioritizing both first and subsequent navigations

This section will describe the data that led us to prioritize both first and subsequent navigations. You might be familiar with the distinction already, but in case you need a refresher, you can read about Lightning Experience SPA architecture in the first post in this series, where they are described as full and soft navigations.

According to data, only about 10% of all Lightning page views are those initial page navigations that load the HTML page. The remaining 90% of Lightning page views are navigations within the Salesforce application, i.e., subsequent navigations.

So an average user session might look like this:

When you think of this data at scale, it is natural to want to focus on the subsequent navigations being fast, and that’s exactly what we did previously. The teams were focused on improving the experience after the application had loaded.

Based on this data, past engineering decisions have been made to prioritize subsequent navigations, leading to first navigations taking 4x as long as subsequent navigations.

Our point of view changed when we started looking at complete user sessions, where the session is defined as a series of navigations to complete a specific task.

As it turns out, about half of the sessions never experience subsequent navigations! Too many page load impressions are informed by the first-page load experiences, which are 4x slower than subsequent navigations.

As a result, both first and subsequent navigations need to be prioritized, and first navigations have significantly more ambitious goals. With that prioritization, you’ll feel the impact in every session!

With that clarified, let’s talk about improvements that we’ve achieved already, and other improvements that will be rolling out soon.

2023 achievements, and the plan for 2024

Without further ado — over the last two releases, the Lightning Experience Performance program has achieved a 12% improvement in EPT (Experience Page Time), measured at P75 (25% of navigations would be slower than that value).

The improvements are observable for first and subsequent navigations. According to the data, some customers have seen even more improvements in some specific scenarios.

A 12% page load improvement translates to about a second saved on first navigations. What does that mean for our users?

At Salesforce scale, our users are getting an aggregate productivity gain of 168 years every month — that’s 5.5 years of productivity saved daily!

And the improvements are not stopping there, they are only getting faster.

In about a year from now, the Lightning Experience Performance program expects to to triple those improvements for first page views, reaching 40% total EPT improvement. Subsequent page navigation gains are expected to reach 20% EPT improvement.

Those improvements will be delivered gradually, with meaningful gains every release from Spring ’24 to Spring ’25 — all to support our vision: Lightning-fast Lightning Experience that enables our customers to do their best work.

Here’s how the timeline shared in the previous post looks with the new updates:

Improvements coming soon

As noted in the second post in this series, features are rolling out progressively to make sure that:

• There are no functional or availability regressions
• There are no unexpected performance regressions in other areas
• Performance gains from the changes are matching our expectations

Our code changes for the Spring ’24 release have not been enabled in production yet, and you should be able to observe their positive impact in the coming weeks as they’re progressively enabled.

Highlights of the features that are rolling out include:

• LWC related record
• API cache lifetime increase based on the usage data
• User-agnostic FlexiPages for custom objects
• Serving LWC modules as code (and not comments)
• Prefetch data at routing and predictive data loading
• Targeted optimizations in server code that’s critical to the page flow

Let’s dive deeper into the last two features in this list.

Serving JavaScript modules as code

This feature was briefly introduced in the previous post in the series, and it might be worth going into more detail on its purpose and impact here.

Specifically, this improvement will apply to the component code delivery part of the overall Lightning Experience construction process (detailed in the previous post):

Before this change, JavaScript code was delivered as JavaScript comments and then evaluated on every page load.

With this change, the need to evaluate literal JavaScript strings has been eliminated and Lightning Experience can now benefit from the much more efficient byte-code caching, background compilation, and component code execution.

Prefetch data at routing and predictive data loading

The next change concerns “Prioritize critical data, sooner” opportunity.

To construct a typical Lightning Experience record home, a series of metadata and data calls are issued in a logical sequence. This sequence forms a logical waterfall as shown in the following dramatically simplified diagram.

Something important became apparent to the Lightning Experience team as they looked into optimization opportunities. For the vast majority of entities (such as Account, Opportunity, Case, etc) the sequence of those calls only depends on the entity and record type, not the specific entity.

What that means in practice is that those calls can be initiated much earlier in the page construction time! Certain customizations can add more calls to construct the page, so this can’t be determined with 100% certainty at routing time just with entity type. With some experimentation, the following approach has demonstrated the most gains:

• At routing, based on the URL, the entity type the user is navigating to can be inferred.
• Given entity type, typical metadata and data for this specific entity of a given type is prefetched (prefetch data at routing).
• If more calls are required – no problem! They’re not prefetched, just delivered when needed (as before).
• Upon successful navigation, the sequence of calls is recorded in a local user cache.
• On the next navigation, given the availability of those entries in the local user cache, those recorded actions are used to predict what requests will be made on the page and to make them ahead of time (predictive data loading)

Here’s how that’d look in practice: prefetch data at routing and additional calls required to construct an entity record home:

After this, here’s how the same sequence will play out for subsequent navigation with predictive data loading:

Conclusion

We can’t wait to get all those improvements delivered to you on top of the 12% page load improvements achieved to this point!

It’s been a privilege to work on improving the Lightning Experience for all of you! Rest assured — our team will continue to push the bar for ever improving performance.

With the first year behind us, there’s a lot to celebrate:

• The Lightning Experience performance improvements program got started and is fully operational
• A detailed plan of improvements, shared in the previous post was created
• Those ideas are being worked on, while the next set of improvements is being evaluated in parallel
• Our gradual rollout process has been validated; it’s been working exactly as designed with minimal negative impact
• A process to read all of your feedback has been established, whether it’s provided in the apps, through IdeaExchange, or elsewhere (thank you for taking the time to share your thoughts!)
• Initial improvements have been delivered, resulting in a decrease of 12% in page load time
• More changes are being rolled out in the next few weeks
• There’s an additional set of work that will be delivered in the coming months

We hope you enjoy reading our posts as much as we enjoy writing them. Stay tuned for more updates coming soon!

Resources

Want to learn more about how our Lightning Experience Performance journey started? Check out the first two blog posts in this series:

• Lightning Experience with Lightning Speed (Are We There Yet?)
• Our Detailed Plan to Improve Lightning Experience Performance

Looking for resources to get started with Lightning Performance? Check out the following Trailhead modules:

• Performance Troubleshooting in Lightning Web Components
• Lightning Experience Performance Optimization

Want to chime in with support for this effort? Consider upvoting this IdeaExchange idea!

Thank you to our contributors

This post would not have happened without contributions from these amazing individuals (listed in alphabetical order): Aaron Burns, Ahmed Ghanem, Andrew Huffman, Benjamin Fry, Binzy Wu, Daniel Takacs, Donna Thomas, Eric Perret, Jose David Rodriguez Velasco, Kevin Hill, Nate Hossner, Nolan Lawson, Onkar Mayenkar and Pierre Marie-Dartus.

About the authors

Bogdan Brinza (he/him) is a Senior Director of Product leading the Web Platform team that enables Lightning Experience. He is passionate about tuning web experiences to be faster. Follow him on GitHub.

Martin Presler-Marshall (he/him) works as a Software Engineering Architect at Salesforce for the Web Platform team. With over two decades of experience on software performance, he focuses mainly on server efficiency and UI performance.