Optimizing your Bubble App

Bubble provides you with a no-code solution for virtually all of your app development needs. It provides
everything from database management to API integration, practically making this codeless platform as
powerful as its code-intensive counterparts.
However, even with the power it provides, it still fundamentally runs on the same hardware and software
principles, thus subjecting it to the same constraints. Running directives to process or display data takes
time and storing information in the database takes up memory space.
Though at first, these costs may not seem significant, such as with computing-intensive operations taking
only milliseconds and complex data structures taking up only kilobytes of database space, your app must
inevitably expand, and these little costs will start piling up. Unoptimized milliseconds are only a drop in
the bucket, but millions of milliseconds represent an ocean of time lost on you and your users’ parts.
Unfortunately, people who use Bubble because of its appeal as a no-code development platform are also
unfamiliar with how to deal with and optimize for these constraints. Though the concept may seem
daunting, BubbleHelpers is here to give you no-code web development support by teaching you about
Bubble app optimization.
It’s important to note that Bubble on its own already does a lot of its performance optimization. It
compresses images, caches JavaScript, and runs database queries as appropriate to be as optimal as
possible.

Under the hood

Before we start stripping our app down to its most optimized and performant form, it would be good to
understand how exactly Bubble loads pages. That way, we can understand where bottlenecks might form,
and find ways to fix them on our own.
When Bubble loads a page on your app, it does the following in sequence (as stated in the Bubble
manual):

Bubble sends the code for all visible and invisible elements
Bubble draws all visible elements on the page
Bubble fetches all the dynamic data needed for the visible elements
This has a few important implications for performance. First and most importantly, invisible elements do
not demand resources unless a visible element makes a reference to data from the invisible element.
Second, generally, the quantity of elements has a greater effect on loading speed than their type.
Repeating elements like tables generally take slower than individual elements. They also take longer to
load depending on the number of elements per cell they contain.
Plugins that are installed on your page are also bundled with the code that Bubble sends, regardless of if
they’re used or not.

Keeping pages lightweight

As noted above, Bubble has to do a lot of things just to display a page on your app. Thus, one of the most
obvious approaches to optimize your app is to simply reduce the burden on Bubble’s end and keep the
pages lightweight.
Every element on a page represents a set of size, position, and style calculations that the computer is
going to have to run before it can even display the elements. Though a handful of page elements shouldn’t
create a noticeable dent, once you’re rendering thousands of elements your users are going to notice the
page slowing down.
Note also that elements won’t be the only thing on your app’s codebase. Every workflow and action
associated with your page will represent an additional cost to your page’s performance every time it
loads.
If you absolutely cannot reduce the number of elements any further, then one possible and efficient
solution is to just partition your single page with lots of elements into several pages with fewer elements.
You could group the displayed elements into pages fitting themes or relevant fields, and then just have the
user be redirected to them instead of letting them see everything all at once.
Another approach is to just reduce the number of visible elements on a single page. This is especially
useful if you’re planning on making a single-page application, which allows users to avoid the
inconvenience of having to be delayed navigating through pages that each needs to load every time in
exchange for a single long loading time for a single page and much faster navigation. All it’ll require on
the developer’s end is to work through selectively displaying only the needed display elements for the
appropriate parts of the page.

Fixing Database Searches

Whenever you need to retrieve data stored on your app’s databases, you will often make a lot of searches.
These searches can easily involve Bubble sifting through thousands or even tens of thousands of entries,
depending on how your app has scaled with use. Fortunately, this is one of the processes that Bubble has
taken special effort to optimize, as noted earlier.
One way in which these database searches have been optimized is that sorting and filtering at the database
level are inherently more efficient. This entails that it’s faster for sorting and filtering to be performed
before any manipulations are carried out on the list of results than after (e.g. search:count is faster than
search:group by:count).
It should be noted that not all filtering operations are created equally, and some filters are ‘advanced’ in
that they are not conducted on the database level, even when they are used first. Generally, filters that
show up in the Search palette are done on the database level, while those that don’t or are applied with the
:filter command are considered ‘advanced’ and slower.

Planning it out

Even with all these tips though, there is no substitute for properly planning your app. A lack of proper
planning and design before you build your no-code app will leave you with scaling and legacy issues as
your app expands and you go further into the development process. Planning an app will take time and
expertise, but it will all pay off for you and your users in the end.

Some of this planning and expertise, in fact, can be found with BubbleHelpers. Even if you’re already
well into your app’s development, feel more than free to refer to BubbleHelpers for assistance and no-
code web support.