My app is very slow

[almo30]

Hi, my app is very slow and I don’t know why. Is it a problem of design (I don’t use Adalo properly) or is it a problem of server ? Most of the time, the problem occurs when I use nested lists and calculations (sum and average). But it can also arise when I use a simple dropdown to select a user in a list. Any idea ?
Alain

[gabs]

I definitely not an expert but I had a similar problem. If the list contains too many records and you show them all together this will probably slow down the app. If this is the case what you can do is

1. Set the list to show the records only as the user scrolls through
2. Limit the amount of records being showed to a fix number and use filters to make sure the records being showed are the ones relevant for each user (i.e. closer to current device location, etc.)

[almo30]

Thank you for your answer.
Alain

[Mohammed]

Is there a link to your app PWA/Previewer that we can check so we can give you more specific tips/advice that might help?

[Simonas1981]

A few observations, which are my own and may be inaccurate:

1. Avoid visibility rules in lists. They require resources to process and they can slow down the app. (There are various ways of playing around)
2. Avoid items such as video player in your list. These are again related to sending data, which requires more time to process. (It is better to have a general list and to have a link to a detailed look at a particular entry).
3. Always use the ‘lazy loading’ functionality, but I noticed that this advice is already given above.
4. Remember that screen A shares information with screen B. That is, if you go from screen A to screen B, then screen B will get the information from screen A. When information is passed from one screen to another, Adalo may have the task of sending and synchronising data between the different screens. If the data is complex or requires a large volume of data, this may take a longer time and affect the performance of Screen B. There are further considerations related to this fact. So, if screen A is ‘heavy’ and it is not necessary to move data to screen B, I advise the use of an intermediate blank screen (for example, with loading simulation) so that the information on screen A is drowned out and no longer interferes with the operation of screen B.
5. Reduce the number of different databases that are fetching data from your list. This again wastes resources and will slow down the app. There are many ways around this. And it depends on your app and what you want. For example, a post wants to show a username, a photo etc. Normally everybody uses the data in the ‘User’ database, but that’s not necessary, because when you create a post, you can create a few other fields where you can enter the creator’s name or the photo’s Url, and you won’t need to use the data in the ‘User’ database.