Lightning Container Component Limits

lightning:container has known limitations. You might observe performance and scrolling issues associated with the use of iframes. This component isn’t designed for the multi-page model, and it doesn’t integrate with browser navigation history.

If you navigate away from the page and a lightning:container component is on, the component doesn’t automatically remember its state. The content within the iframe doesn’t use the same offline and caching schemes as the rest of Lightning Experience.

Creating a Lightning app that loads a Lightning container static resource from another namespace is not supported. If you install a package, your apps should use the custom Lightning components published by that package, not their static resources directly. Any static resource you use as the lightning:container src attribute should have your own namespace.

Previous versions of lightning:container allowed developers to specify the Content Security Policy (CSP) of the iframed content. We removed this functionality for security reasons. The CSP level of all pages is now set to high. This value provides the greatest security, because content can only be loaded from secure, approved domains. When lightning:container is used in Communities, the CSP setting in that community will be respected.

Apps that use lightning:container should work with data, not metadata. Don’t use the session key for your app to manage custom objects or fields. You can use the session key to create and update object records.

Content in lightning:container is served from the Lightning container domain and is available in Lightning Experience, Lightning Communities, and the Salesforce mobile app. lightning:container can’t be used in Lightning pages that aren’t served from the Lightning domain, such as Visualforce pages or in external apps through Lightning Out.