Introduction to Salesforce Lightning web performance

The journey ahead

This is the third part of a three-part introductory series on performance testing, web page performance and Salesforce Lightning web performance. In this final blog we focus on Salesforce Lightning web page performance. How Salesforce provides a custom metric called EPT, how to use EPT and some hidden gems in Salesforce instrumentation data.

Salesforce Lightning web performance

As was touched on in the second part of this series, Introduction to web page performance, Salesforce Lightning web pages are very complex and provide interesting performance challenges. Some of the challenges with Salesforce Lightning include:

Built as a Single Page Application (SPA). As discussed in the previous blog, there are no standards for performance metrics for SPAs, requiring custom metrics.
Pages are primarily rendered using Aura’s component framework. This framework supports creating infinitely customizable pages.
- Lightning Web Components (LWC) is a second rendering stack executed by the Aura stack
There are limited internal metrics for understanding the performance of each Aura or LWC component.
There is limited information published on how to approach improving component performance.

Dive into Lightning SPA

Files to the max

Using the chrome dev tools you can see all the http traffic made to Salesforce. This is a great way to start diving into how Salesforce web pages work.

The screenshot above shows the initial calls made after logging into a salesforce instance. You should see essentially the same if you log into your salesforce instance. Note this will look different if you login and see the setup screen, which will be discussed in later deep dive blogs.

I am going to first focus on the first 7 files.

one.app – The salesforce lightning pages are a special version of the standard Aura application. You can make you own custom aura app and see a similar set of network calls. This file is approximately 85kB compress or 283kB uncompressed. This breaks down to
- HTML excluding inline CSS and JavaScript – 4%
- Inline CSS – 13%
- Inline JavaScript – 83%. This is primarily the aura configuration values. 60% of this inline JavaScript is the values for aura labels.
app.css – This is the css for all of the core components and three versions of the Salesforce Lightning Design System (SLDS). Note that this is 214kB compress ending up as 1666kB uncompressed.
aura_prod.js – This is the Aura framework. Another 268kB compressed expanding to 856kB uncompressed.
apppart*-4.js – These four files represent app.js. If you create a custom Aura app, you will see just a single file called app.js. This is one way that one.app has some unique differences to custom apps. These files contain services that is used as part of the Aura framework execution, like the aura instrumentation framework, and more significantly a collection of core Aura components. From a performance perspective the most significant thing is that collectively this is over 3.3MB of compressed JavaScript which expands to over 20MB.

Just looking at the size of the files downloaded you see one of the first challenges for performance for Salesforce Lightning. The out of the box (OOTB) experience includes greater than 3.6MB of compressed files. This represents the majority of the files needed but is not the entirety of the required requests.

From the image of the network requests you will notice that there is two different scheme types, http/1.1 and h2. If you are following along at home, you can see that the http/1.1 request are to a domain similar to https://somesubdomain.lightning.force.com. This means that it is going directly back to the Salesforce servers. You will also see that the h2 requests are going to the https://static.lightning.force.com.

Optimization opportunity

These represent two places of optimization that Salesforce provides to your organization.

Salesforce supports CDN via Akamai. This is enabled by default on all new orgs. This feature can be enabled and disabled by your admin. This has a significant improvement on your first page load experience.
Enable support for using Edge Network. This article details the advantages of the edge network. Primarily it can support caching static content and allow for optimized routing back to Salesforce servers. There is another advantage that isn’t discussed in the article and that is Edge supports HTTP 2.

With both CDN and Edge enabled all requests back to Salesforce will be via HTTP 2 which will enable future performance optimizations opportunities.

Component Performance

Component performance is not a metric that Salesforce is providing by default. The only tool that is readily available that will help with understanding component performance is the Salesforce Page Optimizer chrome extension. Note that the addition of an extension will negatively impact your web page performance as there is additional work that has to occur to collect the additional metrics.

In an upcoming deep dive blog I will provide JavaScript that will give you detailed information on a per component basis. In addition, I will be releasing a plugin that will easily allow you to collect this information, while also providing the performance costs of the plugin.

Salesforce published a blog post in 2017 about Lightning component performance best practices. This has some good general guidance on the approach to performant components. This includes:

Only create or listen to events that you need to
Optimize the amount of JavaScript and CSS used
Optimize image sizes
Utilize Salesforce caches such as Lightning Data Service (LDS)
Utilize lazy loading when possible.

There have been a lot of improvements since 2017. Primarily the introduction of LWC has given the best path to improved web page performance. The best practices for Aura generally apply to LWC.

Salesforce Performance Metrics

In the last blog post there was some basic information on the instrumentation that Salesforce sends back to the server for collection. You can see these events if you using Salesforce Event Monitoring API’s or the real time event monitoring features. This page describes some of the formats that you can see in the instrumentation beacon including Lightning Page View, Lightning Interaction and Lightning Performance event types. There is another event type you might see on the first page load is the Lightning Bootstrap event, which give information on the bootstrap process that happens on first page view.

The request for the instrumentation beacon is a JSON object. The primary instrumentation is in the following format.

The topic is always ailtn.
schemaType includes LightningInteraction, LightningPerformance, LightningPageView and LightningBootstrap.
Payload is a string that contains a JSON blob with the relevant information.

An overview of LightningPageView

When you look at the LightningPageView payload there are several really interesting pieces of information.

Experience Page Time (EPT) at the top level of the JSON object. It looks like – “ept”: 3635. This shows that the EPT was 3635 milliseconds.
The attributes node has a number of useful information to help understand the page performance.
- eptDeviation shows true or false. True means that something happened as the page was loading so EPT was impacted.
- eptDeviationReason shows why the framework considered the page load as deviated. This could be that the user navigated away from the browser while it was loading among many reasons.
- browserIdleTime shows how long the browser was idle during EPT. In general, this relates to waiting for network requests to complete before being actioned.
The marks.transportation node has rich information about the http requests that they Aura framework made this includes a lot of useful information, including
- xhrStall time in ms. If this is above zero, this means that there were too many HTTP 1.1 requests, and the browser stalls the outgoing request.
- ttfb is Time to First Byte in ms. This indicates how much time between the request being made and the first byte of the response arriving to the browser.
- responseLength show the number of bytes of data returned in the request.

This information is useful both in the lab and production. In the lab it allows for decisions to be made on any variance that might be caused by changes in network conditions, for example. In production it helps identify issues that might be impacted by new deployments of your org implementation, network or hardware changes or even a Salesforce update.

Caching

Salesforce Lightning takes advantage of multiple caches.

CDN/Edge caching – This was touched on as a optimization opportunity above. These features allow for files, especially static content to be stored closer to your location reducing the time to fetch the content.
Browser based HTTP caching – Utilizing cache header controls GET requests are cached in the browser HTTP cache. This means that calls to get app.css and apppart*-4.js files are cached. Note that the path to these files change and how Salesforce manages changes to these files. The current request for apppart1-4.js has a path that looks like this:

https://static.lightning.force.com/na231/aurafile/%7B%22mode%22%3A%22PROD%22%2C%22app%22%3A%22one%3Aone%22%2C%22ls%22%3A1%2C%22lrmc%22%3A%22-386269907%22%7D/dn_WrJN5m2JRKPALe5d0EA/apppart1-4.js

Future releases of Salesforce will lead to changes in this URI.
Salesforce Caches.
- Lightning Data Service (LDS) – provides data caching for Aura and LWC components.
- Metadata caching – Stores the metadata for objects and pages.

These various level of caching leads to challenges in consistency for performance testing. It is critical that you consider what the states of the various caches are through out your test. For example, you might be interested in understanding scenarios of caches being empty as a majority of page loads for your org are driven from links in emails. This means that the custom caches are always empty and need to be rebuilt.

Octane Score

Salesforce recommends a minimum octane 2.0 score of at least 20,000 and recommended score of greater than 30,000. Essentially the advice is that the faster the computer chip in your machine, the better. You can extrapolate this advice to have a fastest computer chip, the highest network bandwidth with lowest latency and have as much RAM as possible and you will have a great experience. While accurate, this is generally impractical from a business perspective.

Thankfully these requirements have not changed in the last six years and there are plenty of cheap computers that can meet achieve the minimum goals and often the recommended goals.

Conclusion

Salesforce is an incredibly complex and deeply layered web application that provides a lot of challenges in understanding the web performance of your instance. Performance is part of your software development maturity. The key takeaways I would like you to have are:

Identify the key performance metrics that you care about and start collecting these. Ideally this will be both from your test environment and production
Create and run performance at a regular cadence. At a minimum in your sandbox before shipping to production.
Make performance part of your architectural plan. Have goals for your organization. If your company has business analysts, work with them to come up with cost to the company for every second of web page load time. This will help your leadership understand the value and potential savings of improving the performance of your salesforce organization.

It is never too early to start running performance tests. To help you get started the next series of blogs will introduce you to setting up your machine in a clean state, writing basic tests, collecting performance data and visualizing the results over time.