I do have a managed package that contains a Lightning app (myApp.app) which contains various custom Lightning components.
When I install the package in any org and open the app, it takes a very long time to load. I invested a lot of time identifying the causes for this.
Here’s what I found so far:
Extreme difference between running it in the development org vs. any other org
Loading the app in the DEV org (where we develop the package) it is okay (about 3 seconds from opening the window to having everything shown properly). Instance is EU11.
When I install the package in another DEV org [let’s call it “Test org”] (EU12 but I’ve tried other instances and sandboxes as well) loading takes significantly longer (about 11 seconds).
Salesforce bootstrap.js loads extremely slow
After analysing the performance using Chrome’s dev tools, I figured that the intial delay is not caused by any of our programming, but by Lightning’s own bootstrap.js (see image below).
Our own code is not even executed yet. I even disabled our code completely (just to render the app without any data) and it is extremely slow.
It alone takes 3-5 seconds just to load in the Test org (Chrome calls the state that consumes the time “Waiting (TTFB)”, found this article explaining what it means.).
When I copy the resource URI and just load bootstrap.js in my browser it takes the same amount of time.
What is interesting about that is that in the Dev org, the same resource takes less than a second to load.
Some info about both orgs:
- Both orgs basically don’t have any data in it.
- Lightning Debug mode on/off does not make any notable difference
- All components/classes/etc. are API 42
My questions now are:
- Did anybody have a similar experience?
- Why does it load slower when accessed as part of a package?
- Does anyone have an idea or hints of how to improve app loading times?
The query paramters to bootstrap.js are basically the same in Dev and Test. The only differences are withing given ID values.
Sizes are 4.8 KB in Test and 5.3KB in Dev (so basically the same).
Response Headers are very similar though some differences exist (X-Content-Type-Options and X-XSS-Protection do not exist in the Dev org):
Content-Security-Policy-Report-Only: default-src https:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'; img-src https: data: blob: file:; frame-ancestors 'self' *.salesforce.com *.force.com *.visualforce.com *.documentforce.com; font-src https: data: blob: file:; connect-src 'self' https:; report-uri /_/ContentDomainCSP?type=unknown
Content-Security-Policy: upgrade-insecure-requests Set-Cookie: force-stream=3267950602.37919.0000; expires=Tue, 13-Mar-2018 10:15:33 GMT; path=/ X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block
I’m analysing a similar performance issue, and found that enabling the CDN for Lightning resources makes a significant difference. Doing a hard page refresh without the CDN was 11.9 seconds on average, with the CDN enabled 9.2 seconds.
You can find the setting at:
Setup -> Session Settings -> Enable Content Delivery Network (CDN) for Lightning Component framework
In our Dev org (which is 8 years old), the setting was not enabled. In newly created scratch orgs, the setting is enabled by default.