🚀Performance
Last updated
Last updated
Adalo simplifies the complex process of building and launching mobile apps with its powerful Builder, extensive component marketplace, and supportive community. However, it's important to remember that your app is still a complex system. Even basic Adalo apps involve a database, multiple screens with numerous components and logic, and integrations with third-party services like Google Maps, Zapier, and DreamFactory. For everything to function properly, the database, page rendering, and network interactions must all work seamlessly together.
Furthermore, every single time your app queries the database, or carries out complicated logic, or talks to a third-party network, app performance will suffer. Therefore it is critical that you always keep performance in mind when building your app, and this section provides guidance on how to make your apps fly.
Web application performance tools such as GTMetrix and Lighthouse assign a numerical score to web application performance, with 0 being a total failure and 100 being perfect. The reality is applications very rarely achieve a 100 score, but that shouldn't stop developers from trying!
We encourage you to think about mobile app performance in similar terms, and regularly ponder how a particular application change or addition will affect performance. Ask yourself questions such as whether an image has been appropriately optimized, or if on-screen logic can be simplified, or even whether a complicated screen should be broken into multiple screens. How you respond to these questions will invariably move your performance score up and down, so choose wisely!
Probably the easiest-to-understand example of this line of thinking pertains to images such as logos or photos. According to various online resources the average LTE connection speed today is 20-30 Mbps. Let's go with that lower number just to be safe. This means that an uncompressed 1 MB image will require 0.4 seconds to download. That may not sound like much, but what if your app included an image gallery consisting of 10 images, all of which were 1 MB in size? That's right your user will wait a whopping four seconds for those images to download.
Adalo uses a service called Imgix to display images uploaded from collections. This allows for the use of parameters when displaying the image using the URL option as shown below:
Using the Imgix API Documentation you can add these parameters to the end of the URL and make adjustments to the image. Using the parameter for output quality "q" can make a big difference regarding the file size. Here are example image taken with an iPhone 16 Pro. Without Parameters - 6.7 MB With ?q=30 - 2.1 MB
Here is how it would look in the Builder:
You can also use image compression software or service like https://compressor.io/ to compress these images before adding them to your app, reducing their size from 1MB to 40 kB? That's right, those same ten images would now require just 0.16 seconds to download!
You can use an online tool such as https://www.omnicalculator.com/other/download-time to estimate file download times based on different file sizes and connection speeds.
https://compressor.io/ is but one of many free online services capable of efficiently compressing images on your behalf. And if you are reluctant to upload your images to such a service, keep in mind that even simplistic graphic editing software such as MacOS Preview offers compression capabilities.
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 natively supports eight different list types, including Simple List, Card List, Image List, Avatar List, Horizontal Card List, Horizontal Chip List, Custom List, and Table. You'll find these list templates in the builder under the components tab.
The Custom List is intended to be used solely when no other list type can accomodate 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.
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.
The Adalo team has been working around the clock on improving app performance, making major improvements to our infrastructure and software. However in the end this is a team effort! 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.
