Nintex Apps and Salesforce Lightning Performance Tips

Part of Nintex Apps's strength is its flexibility, but within that flexibility, it's also possible to design pages that do not load or perform as smoothly as they could. Additionally, page designs that may work well in one context may encounter performance issues in another.

This is especially true when Nintex Apps is deployed within Salesforce Lightning, where the page load life cycle is more complex than Nintex Apps or Salesforce Classic. There are several considerations to keep in mind both in terms of how you design your pages as well as how you deploy your pages.

Page Load Lifecycle in Lightning

It is helpful to understand the timeline of a page load when considering both page design and deployment options in Lightning Experience. Observe the slides below, and note when certain resources are loaded—particularly how Nintex Apps page resources come last in the life cycle.

../_images/lightning-skuid-page-load-lifecycle.gif

Page Design

Limit resources needed at load time

Only so many resources can be fetched at any given time, and the order of that resource fetching within Lightning cannot be controlled by Nintex Apps. Because Lightning Experience opens the door for multiple pages and Lightning components to load at the same time, there is potential for an extended queue of resources, all waiting to be loaded.

For example, a Lightning app page which, between all of the components—Lightning and Nintex Apps alike—loads 30+ resources will run into this issue. Since only a few resources can be loaded simultaneously, other resources inevitably end up further back in the loading queue.

Whichever component—Lightning or Nintex Apps —whose resources load later will appear to be slow, when in reality its resources have not even begun to load. And because of the page load life cycle, this cannot be remedied other than by reducing the number of components and resources needed at page load.

Comparing Skuid Page Lightning component vs the Visualforce Lightning component

It's important to recognize that a page's performance via the Visualforce runtime is in no way indicative of how it will perform within Lightning Experience. This also means that using Nintex Apps's Preview functionality will not accurately reflect performance in Lightning., regularly test your app pages within Lightning pages via the Nintex Apps Page Lightning component.

Why is this? When working within Visualforce, a single Nintex Apps page—and any pages loaded within the Page Include component—makes up the entirety of the resources requested at load time.

When working in Lightning Experience, there may be multiple Nintex Apps Page Lightning components, multiple Lightning components, and additional Lightning resources loaded. Because of this, Lightning page loads can be magnitudes larger than Visualforce page loads, depending on the way the Lightning page is assembled. In short, do not rely on Visualforce performance for your page benchmarks. , test app pages in Lightning Experience.

Best Practices

  • Recognize that everything added to a Lightning page (Lightning, Visualforce, and Nintex Apps ) adds to load time. The more Lightning components within the page, the longer load times will be. While Salesforce Classic deployments are often simpler, full-page overrides, Salesforce Lightning allows for many disparate resources to be implemented into a single page.
  • Hide Nintex Apps elements behind tabs within Tab Sets.
  • Evaluate your use of custom code, as it represents another resource to be loaded. Where possible, consider replacing that code using Nintex Apps's declarative features. If absolutely necessary, consider bundling as much custom code within as few static resources as possible to avoid multiple resource load requests.
  • Make it common practice to test your Nintex Apps pages within Lightning Experience, and not just through Nintex Apps's page preview functionality. Doing so will give you a better view into the runtime experience of your end users, allowing you to catch where certain page changes may negatively impact page performance before they become hard to trace because of future revisions.
    • To better diagnose whether or not your app page's design is causing slowdown, place the Nintex Apps page on a Lightning Page by itself. Then compare its load times with the fully configured Lightning page. If the load times still aren't comparable, the configuration of the Lightning page may be causing the slowdown. In that case, work to reduce the number of components on that Lightning page.
  • Inspect the browser's Network console to see how long it takes for Nintex Apps to start loading its resources. You'll be able to tell when Nintex Apps's Skuid Page Lightning component is loaded by its &skuid.SkuidLightning resource name. If supported by your browser, you can also find additional Nintex Apps resources by filtering resources for the term skuid .
  • Use the Enable Content Delivery Network (CDN) for Lightning Component framework. <https://releasenotes.docs.salesforce.com/en-us/winter19/release-notes/rn_lc_cdn.htm> Enabling Lightning's CDN will improve page load time by caching static content.

Limit network requests in the page when possible

With Nintex Apps, it's easy to make multiple, sequential calls to the server. A typical list of actions from Nintex Apps's Action Framework may look like:

  1. Save a record.
  2. Query a Model and use the results to update the original record.
  3. Save the record again with the changes.

And while this is an easy-to-understand set of actions, it is not ideal for page performance. Three serial, dependent network requests are involved. However, you can use Salesforce's server-side processing functionalities to perform this operation instead of handling it on the client. Because server-side processing occurs first in the page load life cycle, you're likely to see performance gains by placing more of the logic there.

However, it can be difficult to see where those optimizations are needed while still designing your page. Consider crafting the logic of a page declaratively first (i.e. through Nintex Apps's Action Framework), and then refactoring that logic to be server-side focused for better performance.

Best Practices

  • When possible, limit the number of times a client must send and receive network requests to retrieve a page's data. , try to send or receive as much data you can in as few requests as possible.
    • Look for ways to reduce the number of network requests, particularly in Lightning. Even if you might not need the results of query B or C until you receive the results from query A, try querying for all three upfront and use branching logic in action flows to avoid multiple, sequential queries.
    • Use Salesforce's server-side logic (Trigger, Workflow, Process Builder, Invocable Apex, etc.) when you can. Using Apex Triggers or Flows to do subsequent DML operations can happen when the request is already on the server, which means they are resolved quicker.
  • Build pages declaratively first, then optimize their logic by continuously testing network bottlenecks.
  • Open the browser's Network console and look for network requests originating from Nintex Apps. Network requests will have a resource name similar to &Nintex Apps.Nintex AppsLightning.save=1 . If you notice a particular user interaction is a lot slower in Lightning than in Visualforce, clear the network panel, initiate the interaction and see how many network requests are invoked.

Deployment Considerations

Use the Nintex Apps Page Lightning component

Using the Salesforce Visualforce component in Lightning is typically not recommended. Each Visualforce component is an iframe, meaning that they can't share resources with one another and each one handles their own network requests.

One of the Nintex Apps Lightning component's big optimization strategies is the ability to cache all of Nintex Apps's runtime resources after the first Nintex Apps component loads. But while this data can be cached, any additional Visualforce components—even those not related to Nintex Apps —can negatively affect the performance of other Lightning components (including Nintex Apps ).

Verify Salesforce settings before deployment

After adjusting your Nintex Apps and Lightning pages, there are some final settings within Salesforce setup to check:

  • If you've finished developing your pages, ensure that Debug Mode is disabled as it can adversely affect page performance.
  • Verify that secure client-side caching is enabled, as it can improve page performance. But try to only enable this setting after you've finished developing your pages and have deployed them. Otherwise, end users may load older versions of your page.