Will converting all of our pages to reusable elements and placing them in one main page speed up our app?

Questions
1

Hello bubblers, how are you doing? :waving_hand:

We’re building a very robust ERP solution and we are almost done and ready to launch and get some feedback.

I’m not satisfied with page load speed… I want instant loading instead of 2-4 seconds before page loading.

I had a meeting today with other developers and we want to convert all pages to reusable elements and place all in one main page. It sounds promising and almost too easy to be true that speeds our app? :thinking:

Is anyone else doing the same? Now we had like 10 different modules in separated pages and we want to all convert to reusable elements and place all modules to one page and show/hide when needed. This should improve speed by switching between modules/pages, am I right?

:rocket: #ERP

2

Initial page load will be slower, subsequent view switches should see some improvement.

4

The other comment I wrote in Portuguese :brazil: and deleted, The meaning of the question is to bring losses and gains closer together, Depending on your application, the time it takes to load the PAGE will increase, but after the page is loaded, the interaction and dynamics will increase. You can do a test in your application to see if it is worth it. If you consider uploading the plan when you launch it, it can compensate for the loss in page loading…

5

Normally a single page application will attempt to on first page load, load all content so that any future view changes are faster. What that typically results in if a multiple page app is condensed into a single page app structure, the initial page load is longer as it is loading more content on page load.

I believe what you are saying is that after initial page load which is slower as it loads more content, the subsequent view changes are faster as the content is already available to it.

By this I assume you mean you can do something like showing a loading screen for the initial page load so as to ‘entertain’ the user while the app is loading. This is much like what we are used to seeing in Native apps that have loading screens to help users understand the app is working and that something can entertain them as they wait for it to load. Usually a full page floating group with a neat Lottie File is good.

1 Like
6

Essas são, as suas palavras…:technologist:t2::zipper_mouth_face:

Se eu não me engano existe uma FUNÇÃO no Bubble que o amigo pode configurar, ou observar se está selecionado pra CARREGAR todas as páginas do seu aplicativo de uma só vez talvez isso esteja afetando o tempo no carregamento da página…

7

Bubble is a powerful no-code tool for building apps quickly, especially MVPs, but it comes with performance trade-offs—especially in terms of page load speed. While you can optimize to some extent, your ability to do so is severely limited by how Bubble structures its editor and runtime.

Why Optimization in Bubble is Limited

Bubble prioritizes simplicity and speed of development over deep customization. As a result, the following limitations affect performance and optimization:

Editor and Architecture Constraints

  • Limited caching capabilities
    You cannot locally cache search results across page loads. While option sets are cached, data from the main database is not and must be fetched on every load.
  • Inefficient data fetching
    Bubble always returns full records from the database when you perform a search. You can’t query specific fields to reduce payload size. Splitting tables (e.g., normalization) can help reduce the data per call but adds significant complexity to your workflows and logic.
  • No server-side rendering or full CDN support
    Bubble pages are rendered dynamically in the browser. While static assets like images may be cached or served via CDN, the actual app structure and data are not. This limits performance optimizations like pre-rendering or caching full pages.
  • Large JS bundle for the Bubble runtime
    Bubble sends a heavy JavaScript bundle on initial load to support its visual engine. Compared to frameworks like Next.js or other no-code tools (which use vue, flutter etc), this results in a significantly slower Time to Interactive (TTI).

Workflow and Data Flow Inefficiencies

  • Searches evaluate on page load
    All visible searches on a page are executed as soon as the page loads, regardless of whether the user immediately needs them.
  • Automatic updates increase load
    Bubble’s real-time data updates mean that searches refresh automatically when underlying data changes. This adds additional load on both the front end and the database.
  • Front-end workflow reliance
    Many Bubble apps rely heavily on front-end workflows to handle logic, since:
    • Reusable elements don’t support lifecycle events like onMount or flexible inter-component data sharing.
    • Variables and custom state handling are limited and can become hard to manage.
    • A lack of built in JSON support (can’t temporarily store and build data before committing it to the database)
    • Auto-binding on fields (each change is a database call)
  • Server-to-client-to-server round trips
    Workflows often require sending data back and forth multiple times between the front end and server. This significantly slows performance. Ideally, most logic should run on the backend, with minimal front-end interaction and with minimal server calls (1 call per form save instead of multiple calls for every field change)
  • Nested database queries
    Many operations require nested searches or advanced filtering, which can be very slow—especially if the nested data is large or there are multiple nestings.
  • Lack of granular browser-level performance controls
    You can’t control things like prefetching (possible but not easy), debounce logic for searches, or Web Workers to offload work from the main thread.
  • Performance becomes a bottleneck at scale
    As the app grows in complexity and user base, the limitations compound. This makes Bubble better suited for prototypes, internal tools, or small-to-mid-scale apps—not high-performance consumer apps.
  • No static hosting option
    Bubble doesn’t offer a way to serve static versions of your site (e.g., for landing pages or blogs), which forces you to use heavier dynamic rendering even for simple content.

Real-World Impact

Even a basic Bubble app can take several seconds to load, compared to near-instant loads from other no-code or low-code platforms that support much better optimization.

This is a trade-off: Bubble dramatically accelerates development and iteration, but sacrifices performance and fine-grained control over how pages load and behave under the hood.

Summary

Bubble is fantastic for building MVPs, prototypes, and admin dashboards quickly. But if your top priority is fast load times, scalability, and performance optimization, Bubble’s inherent limitations will eventually become a barrier. The editor abstracts away most of the low-level control you’d need to truly optimize an app’s front-end performance.

1 Like
8

Show a screen shot of that Function in Bubble that allows you to check a box to make ALL Pages of the app load at once. I’ve never seen or heard of such a feature.

1 Like
9

I think what the OP is asking for is confirmation of a known behavior, which is when a app is built as a single page app, it will take longer to load on first page load compared to a multiple page app. And the tradeoff for that longer initial load for a single page app, is faster changes between ‘views’ (where a view in a single page app is akin to a different page in a multiple page app). This is known and the reason why any service that wrapps webapps for app stores recommends to use a single page app approach as the switch between ‘views’ is snappier compared to switching to a new page in a multiple page app and therefore more in line with what users expect from apps downloaded on app store.

1 Like
10

Thanks guys…

Yes I’m asking about a known behavior of converting current pages’ main groups to reusable elements and then showing all of them on one page while we still keep current pages as they are… So there will not be a single one-page app (because the bubble editor will crash all the time), so we will maintain modules in their pages, but on the frontend, we show only one page and the user will probably see much better load time between switching between modules/pages which we pull from their own pages as reusable elements…

1 Like
11

Not true dude (and you know better), don’t just copy and paste from chatGPT. You can set searches to run conditionally.

To answer OP, it doesn’t matter if you use reusables or just regular groups. But SPA will feel faster for your users after the initial load. Sendgrid is a billion dollar company and their app doesn’t load instantly. Worry more about functionality and marketing, not shaving down 1s of load time.

4 Likes
12

Daniel here is an important tip this info is rare to find I don’t know why. If you use Bubble built plugin your DOM will be filled that can cause an SPA to load from 3.9 to 4.2 secs if you fully optimize. If you have 10 groups nested and put Bubble built in plugin in to the most inner one all 10 groups will be loaded on page load. If you have complex SPA that can be easily more. So make sure not using Google material icons or other frequently used Bubble built client side plugins. Other than that overall fully optimzed complex SPA adds at most 0.6-04 secs

2 Likes
13

Captura de tela 2025-07-05 050646

14

Screen Shot 2025-07-05 at 7.26.36 PM
Screen Shot 2025-07-05 at 7.26.36 PM978×265 27.8 KB

@apresentadorrfilho you do understand the topic of conversation in this post is about whether or not an app change of ‘page’ would be faster on a single page application compared to a multiple page application? It is not about Timezone Overrides.

Screen Shot 2025-07-05 at 7.26.15 PM
Screen Shot 2025-07-05 at 7.26.15 PM1604×257 21.9 KB

The section your screen shot shows for Page (at the individual page level) is underneath the heading of Enable timezone override controls, which means the Page (at the individual page level) checkbox is about whether or not you are able to override the timezone controls on the page level, and nothing to do with loading all pages in an application at once.

Screen Shot 2025-07-05 at 7.29.42 PM
Screen Shot 2025-07-05 at 7.29.42 PM1357×278 49.2 KB

2 Likes
15

Great explanation…

Yes, Bubble users also need to have the humility to ask themselves how much THEY are investing in performance, to compare the performance of their application with the performance of large platforms such as Facebook, Instagram, X and others…

I believe that if you want to compare the performance of your application by investing $36 per month, and demand that Bubble deliver the same performance as a platform with the best engineers working tirelessly to invest millions of dollars in performance…

As long as Bubble needs to adapt EASE to the understanding of users, who often don’t even know how to correctly RELATE an object to a Repeating Group…

And demanding that your application have the same performance, I don’t know if that is being unfair, or being CLUELESS even in the logical sense…

16

You should not approach this in such a way as to create the reusables from the pages and then need to keep the pages and reusables causing you to make updates to two areas of the app (page and reusable) if you ever need to make changes.

Instead, if you want to convert to a SPA for improving the speed between navigating users between ‘pages/views’, just convert the existing pages into reusable elements and on the one page, put each reusable element into its own group that will help to control conditionally the visibility.

When converting the page to reusable element, keep in mind, Bubble to this day has not yet taken my suggestion when they first released the ‘convert group to reusable element’ feature and expanded upon it to be fully realized feature that we need, and make it so we can convert an entire page into a single reusable element with one button press. So unfortunately, you will need to retain some key concepts for converting a page into a reusable element.

  1. Start the process by grouping ALL container groups on the page into a Single container group. That group is what you will right click and select convert into a reusable element.
  2. All popups, group focuses, and floating groups live on the page and will not be converted into the reusable element. You will need to manually copy with workflows and paste with workflows each of those types of containers.
  3. All custom and conditional workflows live on the page. You will need to manually copy and paste them into the reusable element.
  4. Custom states on the page will need to be manually added to the reusable element.
  5. There will be issues in issue checker to resolve, most of them will be due to the fact that any setting of state actions if state was on page, popup, floating group or group focus will not get converted properly as those elements will not be part of the conversion and will need to be remapped. Additionally, any conditionals that referenced any popup, groupfocus, or floating group will need to be remapped as will conditionals on those elements if those conditionals referenced elements or custom states that lived on the page.

I would suggest testing things out first to see if the benefits are great enough to change the entire app over.

One thing to keep in mind is if an app is a single page app, and you use the go to page action to navigate between ‘pages/views’ the page is not actually loaded again, BUT the page is loaded workflow triggers will still execute. Custom state values do not get lost.

I would not recommend using the experience of other apps as a guiding light for all bubble apps. I believe the time to load depends on a lot of factors and there is not any type of range that fits all bubble apps.

Every group and element are basically loaded on page load, this is why in the debugger when we use inspector we can see the names of elements that are labeled as ‘not visible’ because Bubble does, if they are on the page, whether or not they are set to be visible on page load or not, they are retrieved from the server and returned to the client device, which for me is the concept of loaded for elements. The data fetch is different story.

Again this completely depends on the app and what resources are needed from the server in order to fully load the app. The amount of data returned impacts loading speeds, amount of elements etc. all impact the loading speed, so each app is different in terms of timing, but I can imagine a situation in which app A as SPA compared to app A as multi page app, maybe the extra load time is between 0.4 and 0.6 seconds, but I wouldn’t say that is a truth across the board for any bubble built app.

I was CLUELESS about everything related to apps when I got started in Bubble March 2018 as a non-technical person looking to find a way to launch a startup idea. I think Bubble attracts a lot of similar non-technical people looking to build an app. It is kind of what the vision of Bubble is, to make apps development accessible to everyone, even the CLUELESS. Good thing there is the Bubble forum to help people become aware of some technical things related to app development.

3 Likes
17

Sim claro EU faso parte desse time de sem NOÇÃO…

18

Not sure, doesnt feels right

19

Prove it wrong if it doesn’t feel right

20

Hi,
Here are my 2 cents about it.
I experimented a page loading (with a huge repeating group, but that’s not the point here) in like 20 seconds. Reapeting group is pretty bug and I can’t paginate it for usage purpose.

Each lines contains a lots of elements. It’s pretty much like an ERP btw. (contacts, statistics, info, etc, for eachlines).
And when you click on a line, you have much more infos about the line (graphs, more stats, more RG about call stats etc.).

After a few days of researching here are the main solutions I found where very useful :

  1. I asked the data of deployed line (mean when I click on a line) loading when the line is the one clicked/opened. Gained a lot of loading time, but still super slow (20 to like 12 seconds).
    It seems Bubble doesn’t really care about data are used/drawed or not on screen, it loads everything.

  2. As there are a shit ton of data, there where a ton of data loading, and bubble doesn’t optimise anything..
    Solution here where to create meta data stats for each record at 5am each line and had everything in one table.
    On each change during the day, I update the record of this line for having the RG up to date after every action.
    It went from 12 to 8 seconds.

  3. Here is the solution I had the most difficulties to find.
    I already indicated that I wanted to ask for data in the deployed line when it’s the one deployed (solution 1). But making it unvisible by defaut, weren’t enough for not loading the DOM elements.
    After a lots of researches I found that DOM preloading is very slow, because it loads my 100 hiden row elements DOM.. !), and can’t be removed when you use conditionnal visible enabling/disabling with default disabling.
    After a lots of tries, I found that when you don’t use conditonnal, but you use workflow like “show/hide” elements, the DOM is not prelaoded..
    That’s so crazy that the 2 usage wheren’t the same !
    But yes, DOM inspection in chrome confirmed it. With “show” in workflow, DOM is only loaded when workflow is called.
    That allowed me to gain still haave the remaning time. Leaving it with like 4 seconds.

Now I can load a 100 row RG, with like 20 columns from like 7 or 8 tables with cross searches and an RG in each line visible by default, in like 4 seconds.

So yes it’s probably not what you want, but I guess you don’t have the same constraint as I have, so using those solutions, at least the third, could help you much.

I guess :slight_smile:

Hop it helps !

2 Likes
21

Thank you all.

We have begun converting our modules into reusable elements, and we are already observing positive results. It appears that our loading time has decreased from 3-6 seconds to 1-2 seconds. Once we have completed the process and tested with some real use cases, I will gladly provide more detailed feedback.

1 Like