Performance is a topic that frequently comes up in discussions about web development, particularly when employing no-code tools. It goes by various names, such as speed, scaling, and capacity. These various terms all speak to the same question: can my software run quickly enough if I continue to add users and data to it? The good news is that in most cases, the answer is yes. Bubble’s no-code web construction platform can host applications that match or exceed the performance of many traditionally programmed pieces of software, and much of the optimisation that occurs to make that happen happens behind the scenes and is constantly enhanced.

Regardless of the framework, performance is about the effort you do as the app builder. Even though Bubble is normally optimized for a fast, performant user experience, it’s not impossible to accidently slow down your app if you put things up incorrectly. Many Bubble users are unaware that code and no-code web development share many of the same concepts.

1) Make it “magic” in terms of perceived versus actual performance

Here’s a handy framework for thinking about performance: imagine your app’s performance as a stage act in which you are the magician.

what precisely does that mean, and where do magicians come into this? Magic shows, on the other hand, are all about perception. It’s not about doing genuine magic, but rather about controlling what the audience sees. It is the same as designing for performance. It makes little difference to your consumers whether your app is the quickest data processor in the world or takes hours to process a single record; what matters is how they perceive its performance.

You, like the magician, are free to employ any number of tricks to make your programme appear much faster than it is, or to distract the User while heavy processing occurs without their knowledge. 

The apparent performance of your application is all that matters; the actual performance occurs behind the scenes, where no one can see it.

2) Preparation is crucial

Lack of preparation, like any development methods, no-code or otherwise, can plunge your application into anarchy, where old and new ideas intertwine in a chaotic ball of yarn. It’s tempting to grow your database structure, page design, and workflows as you go, letting each solution and new concept outperform the last until you’re left with a bloated product with yesterday’s big objectives.

These points may not appear to be directly related to performance, yet they are: Everything you add to an app, as we’ll see later in this post, will gradually but steadily slow it down. Poor organisation creates legacy data that bloats your programme. Know what you’re building when you build it.

Bubble is not something I would use as a notepad. Bubble works best for me when I’m building finished applications: concepts, incomplete features, and random whims (even if they’re incredibly amazing) belong elsewhere.

3) Keep your pages as light as possible

Let’s take a look at what causes a page to load slowly. The first point we must agree on is that, while Bubble is a no-code platform, it does run on Javascript, HTML, and CSS – the languages that your browser understands.

From a speed standpoint, this implies that whatever you add to the app is also added to the finished code generated by Bubble. Bubble must add thousands of lines of code if you add thousands of items (inputs, buttons, photos, groups, etc.). Now, each line doesn’t make much of a difference, but with time, you’ll notice that the page takes longer to load, the scrolling becomes choppy, and everything feels… slow. Before everything is presented on the screen, the browser must compute the size, position, and styling of each element that you add to the website.

The Repeating Group problem is a prevalent pitfall during this stage of app development. When discussing page elements, we must do it from the perspective of the front-end, not the Bubble editor.

When you add a Repeating Group with 5 elements inside of it, you may be confident that those 6 items will not have a significant impact on your performance.

However, in the front end, those pieces can combine to form a whole other monster. Assume you have a Repeating Group that displays a list of Users with five elements that display information such as profile image, name, phone number, and so on. It works good at first, but at some time, you may have 100 users. Or 1,000. Or 10,000. How does this influence the six seemingly innocuous elements we see in the editor?

So, instead of 6, you now have 50,001 – that’s one Repeating Group of 10,000 rows with 5 components in each row. That’s a lot of computation and rendering on the part of the unfortunate User’s gadget. Things will appear to be slower to load and choppy to move about.

4) Single-page applications can be extremely fast if properly planned

I know what you’re thinking: so single-page apps are bad since they have a lot of elements? No, that is not correct – but this brings us back to planning.

Single-page applications can be extremely quick since they do not need to reload the page (which is normally the slowest portion of any website process), but instead rely on concealing and showing groups and pieces as needed. Performance is a game of trade-offs, and a single-page application trades a slightly longer page load time for significantly faster navigation. As you can see, while that approach makes sense for a SaaS product, it can be problematic for a website that relies on page load speed for SEO purposes. The key is to figure out what kinds of concessions and performance decisions you’re willing to make and then stick to them.

If you do decide to create an app with only one page, keep in mind that each feature you add to the page makes the page significantly heavier. Determine which features your users will need to use frequently and keep them on the Single Page. Every function that isn’t used as frequently (such as sign-up, onboarding, User profile settings, General settings, and so on) can be moved to a distinct page to keep the app lean.

5) Keep track of file downloads

A web page is made up entirely of files. We’ve already established that the Bubble code base is a file that must be downloaded, but have you considered all of the additional useful content that you add to a page that increases the total download size?

Remember that most files are only downloaded once per device, thus this is especially crucial for first-time users and search engine bots.

Images

Because images contain so much information, they frequently take up the bulk of a page’s total size. Keep your photos tiny and static images compressed using a lossless solution such as Tinypng.

Icons and fonts

Fonts and icons are, in many respects, the same thing: a file containing symbols. It makes no difference whether they are letters or smiley faces; they are downloaded in packets. Try to keep the number of typefaces you use to a minimum, as each one must be downloaded. The same is true for icon packs. If you utilise Bubble’s built-in FontAwesome icons, you shouldn’t use the Material Font library since it forces users to download two libraries.

Libraries for Javascript

To function, many Bubble plugins make use of an existing Javascript library. This means that they don’t write the plugin from scratch, but instead use someone else’s code (known as a library) to add features.

This is fantastic in many circumstances because it means you’ll get a widely used, bug-free library, but it also means you’ll have to download one extra file. The libraries are downloaded in the form of Javascript files.

6) Make use of Chrome Developer Tools

The mere mention of DevTools may cause the hair on the back of your neck to rise up. But what appears to be a complex, bloated piece of software for programmers is actually a very useful tool for anyone who works with web development, including you, the no-code app creator.

So, what exactly are Chrome Developer tools capable of? Your application operates by continuous connection between the user’s device (computer/phone/tablet) and the server (Amazon AWS). You may believe that this information is what you see on your app’s screen – and it is – but a lot more information is exchanged to keep your app loading and operating.

• DevTools enables you to test this line of communication. You can examine all network activities on a single page by opening DevTools and selecting the network tab.
• Listing all downloaded files on a page and their sizes (images, fonts, JS, etc.)
• Calculating how quickly a search runs and how much data it needs to download
• Displaying the content of all interactions between your app and the server (searches, workflows, downloads, and so on).
• It is beyond the scope of this post to demonstrate how to utilise DevTools, but you can get started with this DevTools and Bubble lesson.

Read More: the role of AI and ML in the insurance business 

Stay Connected!

Are You Looking For Bubble Apps?