Do’s and Don’ts for app speed

Hi @alexbarciog,

I’ve made a video about this some time ago, I’d recommend to have a look: Adalo hints and tricks: Image manipulation with ImgIX - YouTube
I think this should help. Look at advice here Resize Fit Mode | Size Parameters | imgix URL API Documentation fit=clip&w=100 - your images will be only 100 pixel width. Of course you can change and experiment :slight_smile:

Please feel free to DM if you have more questions.

Best regards, Victor.

Hi @JL_LJ,

Thanks for sharing the info!
It would be interesting to know the performance, please keep us updated :slight_smile:

Best regards, Victor.

Hi,
You create the filter first and then the view:

Then in the API endpoint, you add “views=XXXX” with the name of your view to the endpoint:

Example: https://api.airtable.com/v0/appXXXXXXXXX/Movies&**view=Movies** and use it on the external collection.

4 Likes

Thanks a lot! This is new to me, I’ll try it out :smiley:

Hi. Do you guys know if hidden components in a page affect speed? Thanks

I believe elements and even data gets cached until it’s been changed, so if your users close the app but don’t log out, things will load instantly.

I could be wrong, if someone wants to chime in also?

Dead Adalo team,

Please do something about the app speed fast OR change your marketing message to avoid your customers getting the very wrong idea that they can actually build commercial apps. This is simply not true due to terrible app speed.

I tried all suggestions from this thread (and more):
• Avoiding many-to-many relationships
• Limiting the amount of lists per screen to 1-3 (and not having lists of lists)
• Installing a “data preloader” from PragmaFlow
• Trying an external database (AirTable)
• Minimising the use of visuals, not using videos
• Avoiding long lists with a lot of records
• Avoiding making the database huge (building mostly via “update record” rather than creating new)
• Avoiding having a lot of actions attached to one button
• Not having too many screens (in this case <20)

And all of this doesn’t help. The app works well on the web but the Android app is really not usable. And it’s not usable with just 1 person (me) being online. What would happen if hundreds of people logged in?

I took on a client and also started building apps for my company… and now I honestly feel a little embarrassed that I was naive believing the no-code tools could work.

2 Likes

Hi @Vykintas,

Sorry to hear that you experience troubles with the app’s performance on Android phone.

Based on what you write, the issue is not related to general Adalo performance, but rather to some specific problem of your app on your phone.
The thing is that Webapps (PWAs) usually work slower than native apps. During app execution the former are interpreted by a browser engine, and such interpretation takes some time and resources. Try to run webapp at a same time with Google Meet videoconference - you will see the performance degradation. Native apps are already precompiled, so they work faster.

But in your case webapp works faster. So, in my opinion it means that the problem is related to a combination of a compiled app + phone model. It will be quite difficult to say what causes the problem and I would advise to submit a support ticket here: Submit a Support Ticket, so that Adalo team can have a look at your app and find what might cause the problem.

Best regards, Victor.

4 Likes

Thanks a lot, @Victor. Appreciate your continuous support to the community.

I recently tried releasing multiple apps as native Android apps and tested with multiple devices:

  1. Pretty heavy app w/ AirTable database (a lot of screens and functionality, with multiple (2-3) lists per some screens)
  2. Medium size app w/ Adalo database (way less screens, though some having 3 lists and some “count” elements on them)
  3. Small app w/ Adalo database (10 screens with 0-2 lists per screen)

The results are that all of them work well on laptop web browsers but only the #3 works ok as a native Android app. The #2 & #3 are really “unreleasable” to an external audiences due to unbearable lag.

So the conclusion I’m making is that only very light minimalistic apps can work decently well on Adalo (and still having question marks on what happens when hundreds of people log in).

Don’t get me wrong, I’m grateful to Adalo for developing the best app building interface out there… however, performance is really the weak spot of Adalo and I believe Adalo’s marketing team should communicate honestly about what their platform can and cannot do.

Otherwise, they raise unrealistic expectations and seriously risk losing customers (e.g. I’m now testing Bubble and FlutterFlow as potential substitutes).

3 Likes

That’s true, on android my app is too slow…

2 Likes

Hi, @Vykintas @njimmy10

Thanks for sharing the info. @Vykintas great job with the testing - you have a lot of valuable data now. In my opinion, your results support the hypothesis about problems with some Android apps.

Again: given same network conditions, native app should not work slower than the web-app due to the fundamental way Adalo works. Adalo hosts the data in the backend DB (internal), app requests this data, processes it and displays on a user’s device. Requests to external DBs are also done via Adalo backend. So overall speed will depend (a) how fast the data is returned from the backend and (b) how fast it is processed on a user device.
Obviously, native apps, as they are compiled into binary modules, process the data faster than web-apps, which are interpreted in the browser context.

So if webapps work fine, but same apps on Android doesn’t work well → there is some problem with Android builds.
Adalo Team is aware of the problem and information from you might be very valuable and help in resolution. I highly recommend submitting a support ticket about the problems.
@anon78309838 @ben1 may I please draw your attention to this.

Best regards, Victor.

P.S. I won’t argue on the subject whether Adalo is usable for commercial apps or not and what speed could be considered “fast” and what “slow”. I’ve had an experience working with apps with 50-70+ screens perfectly hosting several thousands of users, and they were commercial apps.
Also, keep in mind that app performance doesn’t depend only on the number of users or lists on the screen - it also depends on the usage model, screen setup, etc etc etc - there are lots of factors involved. In one of my experiments I’ve built a very poor performing app - only 3 screens (2 of which are login and signup). Home screen took minutes to load - because I was wondering what will happen if I display a list of 20 000 items :slight_smile:

3 Likes

Thanks for your message Victor, i hope my message reaches Adalo, Adalo is growing day by day, and every new user question is: why my app is slow?, is adalo capable of supporting my app? And every question is related to adalo performance and app speed, i think so far if at least someone from adalo can guide us through our app maybe to check their performance and speed, to be honest, i am launching soon an app with expected more than thousands users and about a 200 active per day, i am afraid that my app crashes and doesn’t work, that’s a fear every developer have to be honest. And again Victor thanks for you message i have submited a ticket and hoping to not getting the same reply as usual.

1 Like

Weeks ago i started a topic about servers in EU, i read forum and there is a lot of European developer which their targets are europe, as for me too, i hope adalo can publish something about their plan to make app better, i also suggested to store data locally which make app faster and then send them to adalo server, as a one time thing not with every record creating or record update.

1 Like

I think there are fundamental different in technology perspectives around these platforms.

But, we can only guess it, unless those founders are showing their building blocks.

Flutterflow is more like automation tool for developer, so coding skill is required, but not as intense as coding from scratch, without coding skill it would be difficult to achieve final product.

But for runtime, this will be the quickest and future proof (or present proof) to engine breakdown. Just need to get our hands dirty with source code.

Bubble and Adalo also has a difference in my assumption, Adalo have not managed to separate the editing and runtime algorithm, so sending request and receiving data both for editing and runtime are using the same method, sending json data.
There are chains that data has go from postgress (real db) to list on screen, it could be 10 gateways or less or more, while each gateway will package the data with transformation and bundling, so any data we request, it will go through these gateways back and forth, so that is why a member here identify all API data will come from Adalo server instead of direct from the source, because it needs to repackaged using those gateways.

What I think that Bubble has manage to do that separation, but maybe not fully, that is why they can give more or limit hardware related resources, so the client is no longer just another engine that need to open repackaged data, but it becomes the code itself, which is at par to developing front end client from code.

In simplified terms, no code client is still an engine, engine is slow, it needs to be converted to just client without engine, to do that no code server must change to serve the need for no code client and just client (translated from no code client).

It is mouthful indeed, so had better expecting explanations from official sources.

But in practice, I have seen some progress, many to many relationship updates are quicker, count handling is faster too, but it could be the peak time of those gateways, I may use them during low peak period.

My suggestion is if you have time and effort, embrace all, they are all useful and can be used at particular work when regarded as suitable.

4 Likes

Thanks, @Victor !

Yeah, just submitted the ticket with references to and my experience with all 3 apps.

In the meantime I’m waiting for Apple to confirm an account so that I could test all those apps on iPhones as well. Also I’m trimming the apps down even more (less screens, less lists, less values per list, less visibility conditions, less actions etc. - will see how it goes).

Will drop an update here once the apps tested on iPhone - this will help understand if the issues we’re facing are just Android-related.

1 Like

My experience is that iOS builds run way smoother than Android builds on comparable hardware.
Android lag can be 2-3 seconds even on phones released this year, while the same app on an iphone 6s runs just fine.

3 Likes

That’s true!

2 Likes

An update on my app performance cases above.

GOOD NEWS: Apps are fast and smooth on iOS devices

  • Both - PWAs & native iOS builds

  • Both - with Adalo as well as AirTable (External Collections) as databases

  • (Though still not sure how they will behave once hundreds of people log in)

BAD/MODERATE NEWS: Most Apps are still unbearably slow on Android

  • Adalo database-based apps (unless extremely light) perform real bad both as native builds as well as PWAs

  • However, I managed to make my AirTable-based Android native build work pretty well by splitting the app into 2 separate apps and getting rid of all non-essentials

QUESTION: Anyone can explain why PWAs work so bad on Android? I understand there could be some issue with code conversion into Android native builds… but why PWAs are laggy when overall apps work well on desktop browsers?

cc: @Victor

3 Likes

Hi all!
I have an app with 500+ users and 1500+ records in database colections. The app is on Google Play. It’s an app to manage your car documents (the app is not in english, sorry). I will put here a link if you want to see how an app with 2000+ records works in Adalo
Android: https://play.google.com/store/apps/details?id=com.boglex.blucar
Preview: BLUCAR

2 Likes