Last updated
Was this helpful?
Last updated
Was this helpful?
Like web performance tools that provide numerical scores, regularly evaluate your mobile app performance. Consider how each change or addition impacts performance and make decisions accordingly.
Take time to review each screen and address certain design choices which can slow down your app. Here are some common causes:
Excessive Groups: Too many unnecessary groups add weight to the screen, increasing load time and processing demands.
Hidden Components: Check if any off-screen components are still part of the screen, as they can affect performance.
Overuse of Text Inputs: Even hidden text input fields can slow down your app. Instead, consider storing data in record collection properties when possible.
Adalo supports a huge number of native (built by Adalo and the wider React community) and third-party (built by Makers) components. Our overarching goal is to give Makers maximum flexibility in terms of designing apps in exactly the way they want. With that said, some components are unquestionably going to be more performant than others, perhaps none more so than lists.
Adalo supports seven types of lists, including a simple list, card list, image list, avatar list, horizontal card list, horizontal chip list, and table.
Additionally we support the option of creating a Custom List when the maker determines that the default list layouts aren’t suitable to their specific app requirements. The Custom List is intended to be used solely when no other list type can accommodate your needs, and our extensive benchmarking indicates its use will come with a drag on performance. Therefore it is critical that you ask whether one of the other list types can reasonably satisfy your requirements before choosing the Custom List!
Another common source of performance woes pertains to overzealous retrieval of records. The Adalo Builder includes several options for tweaking the number of retrieved records (see screenshot), including an option for setting the maximum number of retrieved items. So if your screen intends to only display for instance the latest 10 products, be sure to sort according to your product catalog's created at date and assign 10 to the Maximum number of items field!
There is a lot to be said about this particular topic, and we'll undoubtedly return to this section in the weeks ahead to expand upon it further.
Creating counts with filters on a list record is similar to creating a list within a list which will decrease your app’s performance score. You can avoid this by adding a number property to your collection which can be used to track the record count. In doing so you will avoid requiring the app to constantly calculate the record count on every screen load. Watch this video for more information:
Every time a calculation is performed it requires a load (small or large) on our server and the device the app is on. If you have a list of 20 items, each item in that list has to do a calculation which is 20 different calculations the server and device have to handle. It's recommended to pull a sum or total from a property from the collection the list is connected to. For example, if you have a list of posts, with comment counts have a property in the post that is a number property of comments. When a new comment is posted you can update the number property in the post. This way when scrolling through posts it will show the comment number property instead of doing calculations every time more posts load.
Avoid adding lists within lists or loading too many lists on a single screen. This can overwhelm the app and slow down loading times.
Limit the number of sequential actions triggered on a single component or screen, especially if they involve conditional logic. Overloading actions can lead to delays and performance issues.
Many-to-many relationships can complicate your app’s data structure and slow down queries. Use alternative data modeling techniques when appropriate such as a number property with the related collection records ID.
Auto-Refresh will refresh a list every 5-10 seconds which will reload and filter all list data and strain app resources. Use it sparingly and explore alternative ways to update data dynamically.
To keep your app speedy, be careful with the number of components on any given screen. Too many components can make screen loading slow for your users and do not always create the best user experience. Try dividing up the screen into a flow of screens. More screens are better for performance and user experience than one screen overloaded with components.
Using too many relationships in the database or displaying deeply related data will degrade performance. Consider consolidating similar collections into a single collection where possible. For instance, instead of having separate collections for Shoes, Pants, Shirts, and Hats, create one collection called Clothing Pieces with a text property for the type.
Large amounts of dynamic text or high quality uploaded images can slow down the the app when loading lists. Ensure you compress photos when possible and limit text in in lists.
For more detailed guidance, we encourage you to explore these resources:
By combining these best practices with ongoing improvements from Adalo, you can ensure your app performs efficiently and provides a seamless experience for your users. Be sure to start thinking about your app performance in terms of a score and asking yourself whether each new feature will move that needle up or down.
Avoid nesting components too deeply within . Nested parents over four levels deep are likely to experience slower loading speeds and unexpected results. Deeply nested components also make managing layout settings more challenging. Consider breaking up the screen into multiple screens or reworking your database to display the required data more effectively.
To help you improve your app’s performance, we’ve gathered tips and best practices from the Adalo Team, Freelancers, and Maker Community and shared them below.
