Common Performance Issues

Small configuration choices can affect how well an application runs. For example, setting components' Trigger Type to Watch can slow down processes. Limiting Button components to single clicks helps avoid confusion for end-users. These issues are easy to miss until they begin causing problems. This article covers common configuration mistakes that lead to performance issues and how to fix them.

Common Causes

If an application is running slowly, there is likely a performance issue. The cause might be one or more of the following:

• Excessive components on Watch.

• Misuse of Content and HTML Element components.

• Misuse of Panels, Field Groups, and Columns.

• Excessive data tables in a module.

• Illogical component layouts.

• Stagger load and pagination issues.

• Unused or test components.

• Uncompressed file uploads.

• Buttons configured to accept multiple clicks.

• Overloaded submission sizes.

The following sections cover solutions to each of these issues. These solutions might not apply in every case because other performance issues can also occur. Applying them alongside general best practices will help improve application performance.

Components Set to Watch vs. Manual

Choose how to trigger Data & Event Processing components. Trigger these components manually, or set them to watch for an event. When a component on Watch detects that its watched event has happened, it fires.

All components on Watch immediately begin watching for their triggering event. This means every component set to Watch runs when the page loads. This might not seem like much, but many components loading at the same time uses a lot of processing power. This often results in pages loading slowly, which can cause other issues.

As a best practice, set as many components to Manual Trigger Type as possible, ideally all of them. Use buttonClick events, Initializers, Data Workflows, or concurrent and post-triggers in Plug-In components.

Content Components vs. HTML Element Components

Content components have similar functionality to HTML Element components, so it is easy to use one when you need the other. If only a single HTML tag is needed in the configuration, use an HTML Element component. Using a Content component here is not necessary and can slow down the application. Content components are a better fit if more than one HTML tag is needed, or if dynamic content like {{data.firstName}} is required.

When using a Content component, never insert JavaScript. Unqork is a no-code solution, so JavaScript is never necessary. Using JavaScript can also cause unexpected issues for end-users. For best performance, stick to HTML and CSS in Content components. Ensure the closing tags are included.

Delete empty Content and HTML Element components. Keeping unneeded components of any kind makes the application larger and slows it down.

Before reaching for a Content component, describe the goal to the Build Agent. The agent can often suggest a component or approach that achieves the same result with better performance.

Panels, Field Groups, and Columns

Panels are large components that use a lot of resources on the front end. To group components without panel functionality, use a Field Group instead. Save panels for when specific panel functionality is needed, like importing modules, creating a modal, or building navigation.

This rule applies to columns as well. Columns are useful for organizing components and improving the layout for end-users. But adding too many columns makes the application larger and hurts performance. Be mindful of when to use them.

Data Tables vs. Data Collections

Having too many data tables in a module can cause performance issues. When possible, use data collections instead. Data collections exist at the application level instead of the module level. To decide whether to use a data table or data collection, ask the following:

• Will this data be used across more than one module?

• Would the data table have more than 10 rows of data?

If the answer to either of these is yes, use a data collection. Retrieve that data using an API call instead of loading the entire data table in the module. If performance issues occur, check whether any data tables can be replaced with data collections.

Component Order

Organize modules in a logical, step-by-step order. Place input components above the component that uses them, and place outputs below. The module must run in the correct sequence, and the configuration should make that sequence clear. For example, components initialized twice or in the wrong order can slow down the application significantly. Organizing components logically can help prevent unexpected behavior and improve efficiency.

Stagger Load and Pagination

Stagger Load is a setting that controls which panels load from the server at a given time. If using the Navigation component, set Stagger Load to ON. Enable Stagger Load at both the module level and the component level. When enabled, only the displayed panel loads from the server, which improves performance and prevents long load times for larger modules.

Similarly, enable Server Side pagination for any Plug-In component using the List submissions for Dashboard service call. Without Server Side Pagination, module performance might suffer.

Unused Components

Unnecessary or outdated components can increase the size of the module and hurt performance. Disabled components or components set to Hide make the module heavier. This does not apply to Hidden components, which are designed to be non-visible. If these components are not planned for use soon, remove them completely. Before removing any component, verify no active components are linked to it.

Also check Trigger Types for Data & Event Processing components. For components set to Manual, as is best practice, confirm they are triggered. If a component is not triggered and is needed, configure a trigger for it. Otherwise, remove the component from the module. Untriggered Data & Event Processing components left over from testing contribute nothing to a module but still hurt performance.

File Upload Compression

When using the File component, note that image uploads are often large. Photos taken with a phone are typically around 4 MB. Images of this size are rarely needed and can cause issues with API calls, which often have size limits on requests and responses. Compressing file uploads can help avoid these issues. The File component includes a compression setting. Use it whenever possible.

Restricting Buttons to Single Click

End-users sometimes click buttons more than once, either by accident or because they think their first click did not register. To avoid this, restrict buttons to a single click using the Button component's Restrict to Single Click setting. When set to ON, only one click registers even if the end-user clicks multiple times. Allowing multiple clicks can hurt the application's performance or break its underlying logic.

Submission Size and Data Retrieval

Submission size is one of the biggest factors in application performance. A large submission can slow down the application. If performance decreases, submissions might be too large. This can happen if more fields are being saved than necessary. Only enable Store Data in Database for fields that need to be stored.

If submissions are still too large, split them. If working with different types of data in a single submission, separate them. Create different schema modules to hold different types of submissions. For example, if there are File components with large uploads, store those submissions separately from the rest. This way, file data does not weigh down the entire submission.

Additionally, retrieving large amounts of data in the end-user's browser has performance implications because end-users' computers and browsers have resource limits.