Earlier this year, we shared the results from the first year of our journey to improve Lightning Experience performance for all Salesforce customers.

Today, we’re excited to share the most recent results achieved in production. In this post, we’ll highlight several large-scale efforts that converged recently and outline what you should expect later this year.

Without further ado, let’s dive right in!

What we’ve achieved so far in 2024

In our April blog post, we reflected on the program’s anniversary and its achievement of a 12% improvement in Experience Page Time (EPT) for most navigations.

After rolling out more improvements since then, we’re measuring the following results:

• Both first and subsequent navigations are now 25% faster than our March 2023 baseline
  • First navigations are now more than two seconds faster
  • Subsequent navigations are now nearly one second faster
• We continue to be on track to achieve a 40% total EPT improvement for first page views by early next year, through our currently planned efforts

We used our methodology to translate this into productivity gains for Salesforce users, estimating that:

At the Salesforce scale, our users are getting an aggregate of 11 years of productivity saved daily, or about 6 months of productivity gained every hour!

Here’s how the timeline now looks with the new updates:

Improvements coming soon to Lightning Experience

We continue to use progressive rollout to get features to production (as noted in our previous posts). The process has been working as designed for over a year, delivering consistent performance improvements without noticeable impacts on availability.

Highlights of the features that have been rolled out include:

• HTTP/2-enabled feature: We’ve increased the Aura request limit from six to 12, allowing our servers to process more work in parallel.
• HTTP/2-enabled feature: We’ve disabled Aura component bundling.
• User-agnostic FlexiPages: We’ve enabled this for standard objects as a follow-up to custom objects (see the section below for details).
• LWC related record: You might have noticed that this was also present in the previous rollout plans. Our initial rollout attempt identified issues, and upon fixing them, we completed this rollout.

Our other code changes for the Summer ’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. We look forward to rolling out the following features in the next few weeks:

• Predictive Data Loading will be used in more situations:
  • Loading related lists
  • Apex calls
  • Predicting components used by a specific record home
• Further user-specific caching improvements
• Improvements to Aura applications’ critical path
  • Page resolver optimizations
  • Page earlier resolution
• Initial work to optimize the base HTML payload

Let’s dive deeper into our HTTP/2 journey and user-agnostic FlexiPages, both of which were part of our detailed plan to improve Lightning Experience performance shared last year.

Announcing HTTP/2 first-hop availability for all entry points

Over the last decade, various Salesforce engineering and network infrastructure experts considered the opportunity to upgrade load balancers to HTTP/2 in order to get various performance benefits. This, however, turned out to be a true “chicken-or-egg” problem blocking earlier progress:

• Study after study has demonstrated that by itself HTTP/2 doesn’t bring measurable performance benefits and would require major rethinking of data flows in Lightning Experience to extract value
• Major rethinking of data flows in Lightning Experience would require HTTP/2 to prototype and validate potential improvements

Finally, with our Lightning Experience performance effort, we had the right motivation and opportunity for a HTTP/2 upgrade.

Early on, the team identified performance opportunities that would require HTTP/2. As our performance effort matured, that state of HTTP/2 dependency evolved from “nice to have” to “really beneficial to our efforts” to “a critical dependency for most critical features.” What’s even more important is that when you start thinking concurrently, there’s no going back and HTTP/1.1 would be pushed to the limit and it will no longer be able to sustain the new workload.

With this in mind, the Lightning Experience performance team has partnered with the Salesforce Network Infrastructure team to create and realize the plan to upgrade first-party load balancers to HTTP/2. As much as we were excited about the performance opportunities of HTTP/2, the availability and reliability of Salesforce experiences comes first and at Salesforce scale. Our plans had to be robust to prevent any negative impacts, even with a change as massive as an HTTP/2 upgrade. Stay tuned for a more detailed technical post from the team that will describe this journey!

As of this blog post, the upgrade process has been complete in every first-party point of deployment, allowing us to enable features previously exclusive to Hyperforce (since Hyperforce had HTTP/2 ready for us!) to all Salesforce customers.

As part of our commitment to enhancing performance across our ecosystem, we’re pleased to announce that Heroku will soon support HTTP/2 as well. This update will ensure a consistent, high-performance experience for developers working with Salesforce and Heroku, completing our broader HTTP/2 enablement efforts across Salesforce. Developers leveraging both Salesforce and Heroku will benefit from faster loading times, improved performance, and enhanced page responsiveness, all within one unified development environment.

And it’s not just individual features, Lightning Experience has been practically reimagined for a world with HTTP/2. Here are some of the guiding principles and changes we’ve created to rationalize the opportunity for higher concurrency:

• Previously, the framework would prioritize batching to create a few large requests. While this made sense with the limited number of requests allowed in HTTP/1.1, it limits our performance once HTTP/2 is available. For example:
  • Single large requests lead to longer idle time on the client waiting for ALL data to come back, instead of getting data in smaller chunks that can be processed individually and earlier.
  • We missed the opportunity to cache individual requests that change less frequently, specifically when retrieving client-side components. Previously, we would retrieve as many components as possible in a single request, which made caching those requests much more difficult. We now retrieve components separately as a result of dramatically increased cache hit rates for those components.
• Additionally, we’ve noticed that during critical periods of page construction, data fetching and DOM composition were conflicting with each other, leading to longer delays in processing readily available data and requesting more data. As a result, we prioritized requesting more data as early in page construction as possible (see “Prefetch data at routing and predictive data loading” in the previous post), leading to a significant number of requests early in the page lifecycle, which requires HTTP/2 for the best results.

Call to action: Proxy misconfigurations could lead to much slower performance

As the Salesforce HTTP/2 rollout was complete, we noticed that a small number of customers were not using HTTP/2 despite its availability. Upon further investigation, we root caused this to various proxies on the customer side that forced HTTP/1.1 traffic. This is most likely not desired for customer environments, and is possibly a sign of misconfiguration for those proxies.

Forcing HTTP/1.1 would prevent the Lightning performance improvements we’ve noted above, and we’re recommending that impacted customers revisit proxy configurations to fix this. In order to check if you’re impacted, you can observe the HTTP protocol version (HTTP/1, HTTP/1.1, or H2 for HTTP/2) used for Salesforce navigations in the Chrome DevTools Network tab (or similar developer tools in other browser).

Notably, this incorrect proxy configuration would negatively impact every outbound connection, whether going to first-party load balancers, Hyperforce, Salesforce Edge, or Lightning CDN.

Faster pages resolution with user-agnostic FlexiPages

The next change we’re excited to detail concerns the FlexiPages — and it’s a major one.

FlexiPages are the Salesforce Platform’s way to describe an application page’s composition, layout, and functionality, including rules and customizations for personas and individual users. As an administrator, you would create a page and specify visibility and other rules, and the underlying metadata would be saved as a FlexiPage.

Historically, all the user customization pivots were resolved on the server, leading to multiple copies of the same FlexiPages saved in cache. Not only did that lead to low cache hit rates, but actually getting to the cache was a performance challenge, and resolving the key for a given FlexiPage for each user with all possible pivots was measurably time-consuming.

Considering those findings, the team redesigned user pivots to move the resolution from the server to the client. As a result, user-agnostic FlexiPages were created. “User agnostic” in that context means that FlexiPages in most cases are now stored as a single entity for all users, dramatically reducing the number of FlexiPage copies we store and cache. With that change, the client code is now resolving and handling all per-user customizations, which are no longer hardcoded into the page.

Given the complexity of the underlying change, the team made sure that there is no impact to data integrity and access permissions. If the user didn’t have visibility to particular data before, they still won’t be able to observe that data with the user-agnostic change.

And given the performance focus of that change, the team carefully measured client-side impacts and confirmed every aspect of the performance improvements that they hoped to achieve, including:

• User-agnostic FlexiPages cache keys are dramatically faster to resolve, effectively removing the previous server-side bottleneck
• FlexiPages’ cache hit rate has increased substantially (an order of magnitude better) since now the same copy of the FlexiPages is delivered to all organization users
• Client-side customizations are not decreasing performance for individual users, given that the amount of change for individual users is tiny (versus resolving all the pivots for all organization users every time the page is requested by a user)

However, just creating this capability was not enough to get all the anticipated performance benefits. To take advantage of this, our team has converted all standard entity record homes to be user agnostic, covering Account, Contact, Opportunity, Case, and Lead. The remaining 1,300 standard entity record homes that have been converted to be user-agnostic will be rolling out soon!

And just to recap — earlier, the team had enabled the user-agnostic approach for custom objects, so this will work for both standard and custom objects consistently with no admin changes required!

Overall, this change has led to significantly more efficient FlexiPages, and we’re exploring the next set of improvements that can be built upon this foundation, applying the user-agnostic approach to more problematic areas, as well as tuning caching and resolution of FlexiPages.

Conclusion

We can’t wait to roll out all of the features we’ve described in this post for you to enjoy over the next few weeks!

And to wrap this post up, here are some of the topics that we’re hoping to cover in future posts:

• The next set of features that would get us to our original goal of 40% first page load improvements
• Our efforts to prevent regressions — any gains we achieve are only possible through diligently preventing regressions from eating into our results
• Our vision for the next-level improvements and goals for the next year

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 earlier blog posts in this series:

• Lightning Experience with Lightning Speed (Are We There Yet?)
• Our Detailed Plan to Improve Lightning Experience Performance
• Lightning Experience Performance: First Anniversary, Results, and Outlook

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): Alsontra Daniels, Benjamin Fry, Binzy Wu, Chad Pembleton, Daniel Takacs, Eric Perret, Ethan Clapham, Jose David Rodriguez Velasco, Kevin Hill, Matt Stevens, Matthew Curry, Mayur Enjamoori, Michael Marsh, Mingzhou Nie, Onkar Mayenkar, Roberto Edgar, Sukrutha Bhadouria, Traisa Brockmann, Xiaoxu Gu, 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.

Ahmed Ghanem is a Director of Product on the Web Platform team responsible for data and performance in Lightning Experience. He is passionate about improving performance and efficiency. Follow him on LinkedIn.

Nate Hossner is a Director of Product Management for list views and related lists at Salesforce. His background is in Service Cloud, automation, and user experience.