Common Performance Issues

Overview

There's a lot that goes into building an application. And even the smallest thing can impact your application's performance. For example, setting components' Trigger Type to Watch can slow down your processes. And limiting Button components to single clicks helps avoid confusion for your end-users. These are all things you likely wouldn't notice until they start causing issues down the line. So, let's look at some configuration mistakes that can cause common performance issues.

Use Module Outline to diagnose common issues with configurations. To learn more, visit our Real-Time Configuration Analysis Tool article.

What You'll Learn

In this article, you'll learn about configurations mistakes that can cause common performance issues.

Configuration Mistakes that Lead to Performance Issues

If your application is running slowly, you know there's likely a performance issue. You might be dealing with 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 that allow multiple clicks

  • Overloaded submission sizes

Below, you'll find solutions to each of these issues. However, these solutions are not one-size-fits-all. And you may have issues with performance caused by circumstances not listed here. But if you file these solutions alongside your knowledge of best practices, you're sure to see positive results while building.

Components Set to Watch vs. Manual

It's your choice how you trigger Data & Event Processing components. You can trigger these components manually, or you can leave them to watch for an event. When the component on Watch sees that other event has happened, it fires.

All components on Watch immediately start to watch for the event they depend on. This means every component set to Watch executes when the page loads. This may not seem like much, but excessive components loading at once takes a lot of processing power. This often results in pages loading slowly. And those delays can cause other issues down the line.

The easiest way to avoid this is to trigger components manually whenever possible. It's a best practice to have as many components set with a Manual Trigger Type as possible—all of them, if possible. You can do this using buttonClick events, Initializers, Data Workflows, or concurrent and post-triggers in Plug-Ins.

Content Components vs. HTML Element Components

Content components have similar functionality to HTML Element components. So, it's easy to confuse cases where you should use one over the other. For example, if you only need a single HTML tag in your configuration, you'll use an HTML Element component. Using a Content component here isn't necessary and can bog down your application. Content components are great if you need more than one HTML tag. You can also use them if you need dynamic information (such as {{data.firstName}}).

When using a Content component, though, remember to never insert Javascript. Unqork is a no-code solution, so using Javascript is never necessary. Plus, it can cause unexpected issues for your end-users. For peak performance, stick to HTML and CSS in Content components, if necessary. But if you include these in a Content component, be sure to include the appropriate closing tags.

It's also important to delete empty Content and HTML Element components. Keeping unneeded components of any kind bloats your application and slows it down.

Using Panels, Field Groups, and Columns

Panels are bulky components that use a lot of power on the front-end. If you're simply using one to group components, use a Field Group instead. Save panels for when you really need specific panel functionality. For example, if you're importing modules, making a modal, or need it as part of navigation, you'd use a panel. This general rule applies to columns as well. Columns are great for organizing your components for better presentation to the end-user. But adding too many columns bloats the application and negatively impacts performance. So, be mindful of when you use these components.

Data Tables vs. Data Collections

Having too many data tables in a module can also cause performance issues. Instead of always using data tables, consider using data collections when possible. Data collections sit at the application level rather than the module level. To determine if you should use a data table or data collection, ask yourself:

  • 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. You can retrieve that data using an API call instead of loading the entire data table in the module. If you're noticing performance issues, see if you can replace any data tables.

Layout of Components

Organize your module in a logical, procedural manner. This means positioning input components above the component that uses them. Then, you'd place any outputs below those components. It’s important that your module is executed in the proper sequence. But it's also important for that sequence to be clear from your configuration. For example, it can drastically decrease performance if components are initialized twice. The same goes for initializing components in the wrong order. Organizing components logically can help prevent race conditions, which increases efficiency.

Stagger Load & Pagination

If you're using the Navigation component, you must have the Stagger Load setting set to ON. You can enable this at both the module level and the component level. This setting allows for only the displayed panel to be loaded from the server. This improves performance and prevents long load times for larger modules.

Similarly, enable Server Side Pagination for any Plug-In using the List Submissions for Dashboard service call. Otherwise, the performance of your module might suffer.

Unused and Test Components in a Module

Unnecessary or deprecated components can increase the size of the module. This negatively impacts your application's performance. Disabled components or components set to Hide (excluding Hidden components) bloat a module. So, if you’re not planning on using these components anytime soon, it's best to remove them completely. (Make sure you don't have active components linked to those you're deleting, though!)

While working through your components, also check Trigger Types for Data & Event Processing components. For components set to Manual, as is best practice, make sure they're actually triggered. If a component isn't triggered and you need it, fix the issue. Otherwise, remove the component from your module. You might have these components left from testing your application. But leaving Data & Event components untriggered doesn't contribute anything to a module. However, it does negatively impact application performance. So, reconfigure these or remove them.

File Upload Compression

When using the File component, keep in mind that image uploads are often large. For example photos taken with a phone typically clock in around 4 MB. Images of this size are rarely needed. And outside of general performance issues, they can cause issues with APIs calls. Certain API calls have limits on the request and response sizes. Compressing file uploads can help avoid this. Fortunately, the File component lets you compress uploads. You should do this whenever possible to avoid potential issues.

Restricting Buttons to Single Click

End-users sometimes click buttons multiple times. They might do this by accident or because they think their first click didn't go through. To avoid this, you typically want to restrict buttons to just one click. This is easy enough thanks to the Button component's Restrict to Single Click setting. Setting this to ON means that, even if an end-user clicks multiple times, only one click will register. Allowing multiple clicks risks hurting your application's performance or breaking its underlying logic.

Minimizing Submission Size

One of the most important contributing factors to performance is submission size. An overly large submission can drastically reduce the efficiency of your application. If you notice a decrease in your performance, it might be because your submissions are too big. This could be for a few reasons. Maybe you're saving too many fields to the submission. To solve this, remember to only enable Store Data in Database for fields you actually need to store.

If submissions are still too large, you could break them up. If working with different entities in a single submission, separate them out. This helps avoid overloading that can be caused by one massive submission. You can create different schema modules that hold different entities' submissions. This is useful when you have components with large amounts of data, like File components. In this case, you could hold File submissions in one schema module. Then, you can store the rest elsewhere. This way, data from file uploads is not weighing down an entire submission.