Salesforce Lightning Experience (LEX) has developed somewhat of a bad reputation in the community for poor page speed load times and general load efficiency.

It’s true, in a direct comparison to Classic, Lightning Experience is more cumbersome and adds unwanted milliseconds to load times.

Lightning Experience itself can bring a number of benefits to storefronts, and there is a good argument for most companies to make the jump from classic to LEX.

However, there needs to be a plan to optimise the additional load weight that comes with the benefits.

A LEX page is the basic unit of execution for LEX Lightning Components, such as Lightning Component pages and Pages.

Optimising Lightning pages

Our core goal here is to try and reduce the additional load weight of Lightning objects, like Opportunities, Cases, Contacts etc. by removing and/or disabling irrelevant fields, page types and customisations.

Page rebuilds

One of the first things we do with any LEX site is to run a set of performance inspections to determine what can be done to optimise the site.

We then go through the site, and identify pages that are likely to slow down performance and hold up requests.

For this process, we use the Page Rebuild tool. This enables us to go through the entire Lightning Experience site, and clean up all the superfluous items from under each object — such as unnecessary classes and fields.

Removing, and segregating VF pages

Anecdotally, we’ve also found that sometimes segregating information into different tabs can help, as a search engine user-agent (or browser) only requires X information to render/deliver X, so why send all packets at once and cause unnecessary load?

By segregating information into different tabs, you’re reducing the number of server requests, and the side benefit is that you’ve got better-organised information that could be used to enhance the UX (user-experience) of pages.

Apex refactoring

Apex refactoring is a set of Apex code transformations that can automatically rewrite Apex code to improve the structure and maintainability of that code.

This can be done to improve LEX page performance by reducing execution time.

To achieve this, you can:

  • Reduce iterations: With Apex refactoring, you can change the internal code structure — preventing looping — while preserving any external behaviour and functionality.
  • Eliminate multi-trigger objects: If there are multiple triggers related to a single object, it will impact page load performance.

As part of Salesforce Commerce Cloud MVPs, that intend to use the LEX framework we recommend using the one object = one trigger rule.

Measuring LEX page load times

When measuring LEX page performance, Salesforce recommends that you exclude Lightning Framework bootstrap processes from your measurements, as when manually testing the browser the refresh/reload process can cause some inaccurate measurements.

As a result, Salesforce recommends you make use of the Lightning Component debug mode, and by adding the URL string of ?eptVisible=1 to your standard page URL.

This will show page load time in a similar fashion to the component debugger.

Using these tools in conjunction with more traditional speed test methods, such as Lighthouse and Dev Tools, can help highlight opportunities and determine obstacles that could hinder both organic search performance and user conversion across your storefront.