Building a Facebook or Airbnb clone in less than a day? That would have been unthinkable when these billion-dollar platforms were founded. Today it is - thanks to no-code tools. With Bubble, Flutteflow, WeWeb and the like, anyone with a computer and an internet connection can now develop their own app.
VisualMakers community projects such as GuestGoods, CircleHand or DreamyTales show that it is possible. Modern front-end editors and ready-made templates make it incredibly easy to create a beautiful app experience. However, an app that is intended to host several thousand users requires more than just beautiful colors and neat tables.
Even if not noticeable from the start, performance - mainly expressed in loading times - is something that is often not taken into account when the first app designs are made. Unfortunately, many citizen developers often don't learn (or learn too late) how to optimize an app for performance. In this blog post, we will therefore look at some of the best practices that will help you to optimize the loading time of your app.
The content in this article is not explicitly related to no-code development, but comes from classic development. This list is certainly not exhaustive. We would be delighted if you have your own tips that you can share with us. Simply join our Slack community.
First of all, it's about the front-end. This concerns everything that can be seen, such as images, texts or tables, but also invisible front-end elements such as containers or div blocks.
Reduce the number of elements you have on a page to a sufficient minimum. The more elements that have to be loaded, the longer the loading time and the slower the app. Each element requires loading capacity, but even non-visible elements such as div blocks can drag down performance. So think carefully about whether you need to include other elements such as text or images in their own div blocks or containers.
If the design of your app is already minimalist in nature, then you will benefit from this. If not, then you need to find the right balance between appearance and performance. When in doubt, you should prioritize performance. True to the motto "Is this art, or can it go?"
Ultimately, you want to build a powerful app that looks good, not a useless work of art. Looks aren't everything!
This is not about cars, but the auto settings of elements, e.g. the automatic height or width of a container. This setting costs you performance, because calculating it requires capacity. You can relieve your browser of this work by working with absolute dimensions, e.g. height: 150px instead of height: auto. The same applies to a fixed number of rows or columns in a table, for example. Fixed numbers will require less capacity than a relative number that still needs to be calculated. Of course, this is not always the best solution. But if it is a working option, then you should prefer it. Always with regard to the responsiveness of the app, of course.
Let's stay with the design. Animations are an important part of the look and feel of a website or app. Sometimes they have the decisive coolness factor. But as you might have guessed, this coolness comes at a price: compromises in performance.
So here too, what is absolutely necessary and what is just a nice-to-have? Any wobble effect on a button will reduce performance. And let's be honest; nobody likes wobbly buttons.
As you've just learned, looks aren't everything. Inner values are also important. And when it comes to these inner values, it really matters whether it is 3.5 megabytes or 40 kilobytes, for example (remember: 1000 kilobytes is 1 megabyte).
We are talking about file sizes. This applies to all types of media that you upload. These are usually images, logos, videos, GIFs or downloadable files, e.g. in PDF form.
Always compress these files before you upload them. There are many free online services for this, such as compresspng.com. For images and logos, it is also advisable to use small file formats such as SVG or WebP, which was developed by Google.
There are elements where you want to make visibility dependent on various factors. However, to improve the performance of your app, you should actually think in terms of presence rather than visibility. This means that you should not first load certain elements that have conditional visibility and set them to non-visible, but not render them at all.
If, for example, you have different views of an element for different user groups (admin view, visitor view, etc.), you could prevent all views from being loaded but invisible by linking rendering to the user condition. Then do not load certain elements at all.
The same applies to data, of course. If you need to access data, make sure that you only load the data that you need instead of loading all data and then filtering it. This not only has the advantage of improved performance, but also data protection. Because even if certain data is not visible in the frontend, it may be possible to find it in the source code if it has been loaded and no security precautions have been taken.
For example, you can use "Only when" conditions before retrieving data from the back-end. The slower alternative would be to retrieve all data and then filter it.
While we're on the subject.
Loading data is what often takes up the most computing power. Therefore, improvements applied to data loading will have the biggest impact on the performance of your app. Simply put, you need to make sure that you only load the data that you need at that particular time on the page.
Data is stored in the back-end and that's why you can make performance-relevant adjustments there to increase the performance of your app. Firstly, there is the factor of which database you choose and how you structure your database. But that is a topic in itself.
If this is already done, then you can, for example, ensure that you optimize the API endpoint that retrieves the data from your back-end. The main thing here is to reduce the volume of data that you send to the front end to the absolute minimum. Only ever send the columns or fields that you need for the respective operation.
With a tool like Bubble, which does not necessarily require an external back-end compared to WeWeb, things can look a little different. There you don't need an API, but can communicate directly with Bubble's own database via the editor. In this case, however, how you express your commands is relevant. Whether you select "Do a search for" or "List of", for example, makes a difference. Here is a short version:
"List of" is worthwhile for short lists. For example, if you want to display users' favorite colors, then use "List of". In this case, the expression could be "Current User's (list of) favorite colors". Lists with only a few (1-30) entries can be loaded more quickly.
"Do a search for" is worthwhile for long lists. For example, if you want to display the purchase history of a user, then use "Do a search for". The expression could then be: "Do a search for purchases" + the condition that the buyer = current user.
Join operations retrieve data from two or more tables based on a common field. The result is a result table that combines data from multiple tables. Doing this costs performance. It may not matter with 3 tables and 1,000 records, but if you want to scale, it could make all the difference.
So avoid these performance killers wherever you can. If you can display information in a single table or retrieve required data separately, then do so. Only use join operations when absolutely necessary.
For example, if you fill a repeating group with data in Bubble or want to display a collection in WeWeb, the data is loaded by default even if you set it to "display-none".
For pages where performance is particularly critical, e.g. where large tables occur, it is therefore advisable to link the loading process of data collections to user interaction. In this case, data only loads when required and not automatically. For example, a table only loads when the user scrolls to it or clicks on a "View Data" button. In WeWeb you have the option of conditional rendering for this.
If you have several pages in your app or, for example, a table where you can switch back and forth between pages, the question arises as to the best way to load the data for this. The following options are available:
In this case, all data is loaded in the browser and displayed on the corresponding pages - even what you don't see. This is ideal for small amounts of data. If there is a lot of data, performance slows down massively or the browser even crashes.
From a UI/UX perspective, it may still make sense to create a long table instead of using different pages, for example. However, this should always be done in consideration of the performance reduction.
A good way to reduce the loading time is to use a lazy load. With a lazy load, only the data that is in the part of the browser that is visible to the user is loaded. If he or she scrolls down, more data is loaded. Lazy loads are particularly suitable for images or load-intensive tables that are not immediately visible.
In this case, all the necessary data is loaded into the browser, but only what should be visible is rendered. This slows down the initial loading of the page, but when users switch to another subpage or table page, the data is quickly visible as it has already been loaded.
Only the data that is to be displayed is loaded here. This speeds up the initial loading, but slows down the loading between pages. Nevertheless, this is often the best option to minimize the perception of loading times.
Skeleton loaders are visual placeholders that users see while the actual data is still loading. The purpose of this is not to increase performance, but to improve the user experience.
You may be familiar with this from the LinkedIn mobile app. If you open it, you will initially only see gray "shells" of what is displayed as soon as the necessary data is available.
These are often subtly animated with a pulsating effect or similar. The skeleton, including the animation, lets the user know that something is happening and, in our opinion, makes a better impression than classic loading icons.
Inthis tweet, Gregory John from Buildcamp explains how you can integrate skeleton loaders into your own bubble app.
As mentioned above, this list is not exhaustive and certainly not the 100% correct guide for every app. So our final tip is: test it. All you need is two versions of an app or page that you want to test against each other and a good old stopwatch. Then test them across different browsers and devices. Either a clear winner will emerge, or you'll learn something about how certain customizations behave with different interventions (browsers, devices).
We hope these tips will help you scale your no-code side project into a powerful app that can compete with Airbnb, Facebook and the like - in terms of performance and maybe even revenue!
So if you have any questions about your project, feel free to write to us! Join our Slack community. There are over 750 other no-code enthusiasts waiting for you and your questions.
Or book a call with us. Maybe we can help you realize and scale your next project!
