12

We have a 3rd party developed Lightning App where most of the components don't render until after a 50 second delay on the first use of the day. But you can e.g. open the Salesforce Sales app first and that opens quickly: the problem seems to be with this specific custom Lightning app. Though we do see a similar big delay for this Salesforce Labs Package Visualizer App.

I have not seen this described anywhere, so that makes me think that it may be a problem in the app, but there is nothing obviously wrong with the app that I can see (apart from it using way too many of its own LWCs).

So before I do a lot more measuring/testing/logging, is a big startup delay on a custom Lightning app using many custom LWCs normal?

PS

This Why is my Lightning App inside a Managed Package extremly slow during its bootstrap phase (but not in the DEV org)? may be the same problem.

PPS

The call that blocks (for 48 seconds) is the first call of this:

.../aura?r=11&aura.DynamicComponent.getTemplateDescriptorWithExpansionBundle=1

with an immediately following call to the same endpoint taking 700ms.

This seems like a similar "org warmup" effect to what is seen for Apex code, where the first access to an org takes a few seconds extra while the Apex code is compiled and cached. Is the platform pushing all the LWCs through (slow'ish) tools that generate the single .js file per LWC and caching that result?

(We have now created a Saesforce case for this question too.)

Improve this question
4
  • I would say that it isn't normal, however, there are so many variables in play. how do the components interact with each other, how much data is shared across components, how is the data being fetched, how much data, external api requests.
    – glls
    Jul 8, 2021 at 13:10
  • Thanks @glls, the delay is before any data is requested.
    – Keith C
    Jul 8, 2021 at 15:17
  • Hello @KeithC, is it worth trying to compile all classes? I'm asking because if you feel that this is some sort of warm-up procedure it might be worth trying that.
    – Jeferson Chaves
    Aug 10, 2021 at 9:14
  • 1
    Hi @JefersonChaves perhaps. I imagine for the LWCs there is both cross-LWC checking and code generation per LWC including stubs to call the Apex code. My guess is that the tooling used for that is more designed for development-time than run-time and so runs slowly (relative to how fast Apex compilation is now). When we demoed the problem to SF support, this being a "start of day" problem made them not so concerned. We have more follow up to do.
    – Keith C
    Aug 10, 2021 at 14:12

2 Answers 2

Reset to default
10

My colleague has created a test-case app that consists of many copies of the same LWC using different names. The LWC is fairly typical i.e. moderate size and not crazy complicated.

Using this test app with 50 LWCs, 100 LWCs and 200 LWCs indicates that the time taken is linear at about 400ms per LWC so e.g. a 20 second delay for the 50 LWC case. The call that suffers this delay is:

aura.DynamicComponent.getTemplateDescriptorWithExpansionBundle=1

and the delay is suffered on the first access of the org of the day and sometimes later in the day too. (This fits the theory that the LWCs are processed once and cached, and that they are eventually evicted from the cache.)

Our conversations with Salesforce support have so far indicated that as this is not a problem on every request, it is not a major problem. They also point to best practices of only referencing the LWCs that you need which of course makes sense.

As of 26 Aug 2021 the case is still open and being worked on by Salesforce.

As of 2 Oct 2021 the case is still open and being worked on by Salesforce. One insight is that it appears to be the Apex import aspect of LWCs that makes the process so slow; lots of LWCs with no Apex imports have a way lower delay. Obviously some LWCs need to interact with Apex code, but worth eliminating (or moving) such calls if they are not really needed. So "doing something on Apex imports" seems to be an expensive part of the LWC processing. (FYI this interesting article about the JavaScript processing aspect.)

As of 8 Oct 2021 the response from Salesforce support is:

Load time is directly proportional to the number of lightning web components.

GetFlexiPageInfo which is being invoked by the getTemplateDescriptorWithExpansionBundle fetches and compiles all the metadata of the components which are involved in the component and ships it over to the client side. During the first request, it is going to take time then for the subsequent page loads the processing time gets reduced significantly.

During the lightning web components loading, apex references would be validated during the first load which is the cause for the delay in the first request. It depends on the number of components too. The more the number of components the longer it would take to do the validation.

Our R&D team confirmed the behavior as WAD.

So it appears that a significant delay the first time this process is gone through is normal, so your first user of the day should expect such a delay.

Improve this answer
6
  • We have the very same issue, please post updates here :( We are referencing the top level LWCs which are a handful but as it is a composition model for us some of these pages end up pulling about a 100 nodes under descriptorUids (both system and ours) and that kills that initial load. For us this happens both in dev org and in prod (we don't use LWC debug mode though in dev), and what is worse it basically happens every day.
    – zaitsman
    Aug 30, 2021 at 1:04
  • 1
    Hi @zaitsman, Thanks for commenting, will post updates when we get any. FYI we see the same sort of delay in the Salesforce Labs app [Package Visualizer ](appexchange.salesforce.com/…).
    – Keith C
    Aug 30, 2021 at 8:03
  • Hi @zaitsman Support are saying "working as designed".
    – Keith C
    Oct 8, 2021 at 16:50
  • Great :( (I mean not great, but what can you expect from them?) SF Partner program is promising direct developer support for all Partners by December, if that does eventuate I will try to chase it that way. Thanks for letting me know!
    – zaitsman
    Oct 9, 2021 at 13:45
  • 1
    Hi, Our last response from SF was "working as designed" so we are just living with it. A work-around could be to have some automation that connects and opens a page or two say every 30 minutes to keep the org warm. I assume that the problem is known to the dev team and would hope that work is going on to eliminate it. I'll pass on our case number - need a colleague to find it for me though.
    – Keith C
    Feb 6, 2022 at 12:24
1

140 custom lwc components to build an App sounds like a lot imo, however, the loading time does sound unreasonable (Not normal).

As mentioned in my comment, there are so many variables in play.

  • How do the components interact with each other,
  • How is the data being fetched
  • How much data is shared across components
  • How much data
  • External api requests

etc, etc, et....

Several references that are useful for troubleshooting and considerations for performance:

This one is a quickie for checking loading times

Adding ?eptVisible=1 to the Lightning URL Ex: https://.lightning.force.com/one/one.app?eptVisible=1

Unfortunately, you will have a lot of digging to do =/

Improve this answer
3
  • 1
    Yes, just didn't want to start looking if the delay we see is "normal". Think I need to start with being able to repro more easily and then tracking down what is running during the delay.
    – Keith C
    Jul 8, 2021 at 16:10
  • 2
    We've now created a case: the blocking call is the first use of the org at the start of the day (by any user) and is an API call well before our LWC code starts to run.
    – Keith C
    Aug 5, 2021 at 22:53
  • @glls i second Keith C this is not really related to data, interaction or api requests. this is LWC trying to compile a list of 'what components to load'.
    – zaitsman
    Aug 30, 2021 at 1:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .