Bubble Speed FAQ

Bubble Speed FAQ

Hi while working on one of my apps several questions regarding speed came to my mind. I was wondering if others had similar questions and decided to write them down. Forgive me if these questions were already answered comprehensively somewhere else. I did a quick search but did not find anything.

It would be great if either the Bubble team or experienced users could help with their views on these questions. I think everybody would benefit from that. Some of them might seem easy or „dumb“ to some of you but I am sure it will help inexperienced users, like myself. OK let’s go:

  1. If I have a text field to help find a thing (I.e. „Unique ID“ type) and I generate a unique ID string via the Calculcate RandomString function in Bubble: Does the length of the string have an influence on speed (e.g. „Search for“)? e.g. a long, complex string takes longer to find?

  2. How big is the influence of using or not using Styles on a) page load and b) on page speed (i.e. clicking a button etc.) in your experience? Do you try to strictly stick to Styles? I tend to not use styles because oftentimes I find myself needing a slightly different variation to an existing style which would lead to many styles or many elements without a style.

  3. Let’s say I have a big group with many elements and many workflows and I do not make that group visible on page load, does it entirely not impact speed? Or do parts of code still need to be downloaded (e.g. the workflows?)

  4. Let’s say I do a search and generally I could find the item I want to display via putting a constraint on one of its field does it improve speed if include additional constraints using other fields to further narrow down the search?

  5. Can one say what the impact of using groups is on speed? e.g. I like to put things into groups even if it is not necessary to organize stuff. Sometimes I have dozens of Group layers. Do too many groups have an impact on speed? What about workflows? Should I always strive for combining as many actions as possible into one workflow (e.g. I could use “Toggle” to show/Hide an element or use two WFs to animate the element)

  6. Do other pages have ANY effect on the current page (e.g. many workflows on that page, plugins etc.?) If yes, what are the things that have an influence?

  7. What about Conditions: Currently we cannot put dynamic conditions on Styles (or it is very limited). If I want to have something like a Dark theme, I need to put a condition on each and every element (i.e. „When Current User’s Theme is „DARK“= Font Color XYZ). How much is a condition that essentially always the same impact speed?

I would be forever grateful to anyone who can share his/her wisdom on the above questions. I will continue to collect questions. Also, please feel free to add additional questions!



1 Like

Hey! :upside_down_face:

You’ll fin an elaborate answer for most of your questions (1, 2 ,3, 4, 5 and 7) here:

For your question 6, no, except for specific cases the other pages will not affect the one that is open.


Thanks for the suggestion. Looks like a great resource. I appreciate the time and effort that must have gone into something like this. On the other hand, I don’t know if this can (or should) make my post obsolete…I feel the community would benefit from openly sharing this kind of information and giving the Bubble team as well as different experts/developers the chance to chime in. But thanks will consider buying this :slight_smile:

That book may or may not make your post obsolete, but for what’s it’s worth, even Bubble themselves reference it in this blog post… https://bubble.io/blog/bubble-apps-scalability-optimization/ … so, there’s that. :slight_smile:


1 Like

sorry but…have you actually read the book? It does not contain “elaborate answers” to most of my questions. I don’t want to put anyones work down but there is a difference between saying “Not using styles will make your page slower” and describing the actual impact (i.e. how strong will the impact be). It is a nice pdf but definitely not a “Book”. Again, I don’t want to discredit anyones work but it is not at a level of “here are 10 incredible performance tricks” but more on the level of basic explanation which should have come with the standard Bubble documentation.

1 Like

I have not read the book yet, although I purchased it as any insight from other Bubblers, especially those with years of experience, is helpful, even if picking up one tip or trick.

In regards to what you ask about

That description may not necessarily be understandable by most Bubble users who use the platform as a way to be a non-technical founder to be able to create a technology product…obviously the actual impact and reasoning would necessitate some level of technological explanation that may be beyond the comprehension of the intended audience.

I would venture to guess that most of the tips in the e-book are intended to be followed, without necessarily needing to understand exactly why it works. It is like when I taught English and students asked why some English grammar concept was the way it was, I always had to explain I didn’t create the English language, I just teach its concepts so others can speak it correctly.

In regards to this

I believe it is because Bubble is java-script based and it needs to load each individual elements formatting and if each element of the same type that has the same formatting is using the same style, that formatting or rather style is loaded only once, rather than for each instance it is used and therefore the page load would be slightly improved…I’m not technical in any way, I just know how to use Bubble, so my understanding an explanation might be off from a technical perspective.

I think as Bubble is developing and expanding they are getting a greater opportunity to improve their documentation, so maybe in the future they are going to not rely so heavily on community support and the organization itself will put out more detailed explanations of how all the different things developers could possible do on their page may impact the performance.

Thank you for sharing your view. I agree, any input is welcome and helpful. Would be good to share that openly but I know we all have bills to pay :wink:

I am not sure if I understand you correctly…I was not referring to the “why” (as in your comparison with your English student example) but more on the “how”. I think, there is a difference between those two questions, would you agree? I also don’t need to understand in-depth WHY not using styles slows down the app but how much it is. For example, “each time you don’t use a style it adds XYZ bytes to your app. If you do the math, not using styles 1000x times could result in (BALLPARK number)” (Just an example from the top of my head). Again, not picking on the pdf, it does not have to resolve everything and some of the insights I would personally rather expect from the bubble team and not from community experts.

I don’t think that is realistically possible because no way of knowing how much formatting has been done to an element…consider a group that has formatting as simple as a background color, compared to another that has outline, gradient background, box shadow, roundness as well as some conditionals for hover or press.

I think overall, most of the performance related concepts would not have an ability to boil down how much, but instead could only touch on the why portion.

Another example would be loading data in a RG…impossible to tell how much slower your load would be by having a lot of related data fields on the data type in the RG, because a lot of it is probably needing to consider the users device, internet connection etc.

Most likely the best you will be able to get from any community member and Bubble themselves would be the why, and not the by how much.

yeah…again…ballpark numbers/guidance or examples. I can do (and will do when I have some time) set up a couple of test pages which contain the exact same content and make an A vs. B comparison with different scenarios…just from the top of my head. No need to make it scientific. Let’s not confuse complex or tedious with “not realistically possible”. And as for anything in this universe…individual cases can of course differ from the average use case and different factors always play a role with anything in this world.

As per your RG example…that’s actually what the PDF (the one you bought but did not read so far) is trying to illustrate by separating the different factors and giving the reader options on how to influence each one of them (e.g. how many bytes is a short text on a thing adding to the size of the thing) Maybe you should give it a read! Anyways, thanks for sharing your opinion.I think we are going slightly off topic. I will see if I can share some insights here if nobody else wants to chime in.

That is awesome…more incentive to read it sooner…didn’t know he was providing some ball park figures on how much some things influence the performance

I just read this :

And one of the guy made an app that went viral (it’s make-fortnite-skins)
I do think that there must be a lot of concurrent users even now the site has like 20k/month
However, may be it doesn’t load the server that much compared to someone who has a lot of RG on the page?
Just choose an image (make them small size) and put it on top of the character?

I’d say the #1 thing that is going to affect page load speed is the number of elements on your page.

I have an app with a large page. It’s a SPA (single page app). The whole bulk of this app is on one page. Take a look at this screenshot of my load times over a week.

You can see a massive drop in load times. This is from an update I pushed live.

The update added styles to almost every element, and removed a bunch of unnecessary groups. I didn’t remove much from the page in terms of content/functionality/design, it was mostly there were groups/shapes where there didn’t have to be groups/shapes.

So I’d say definitely use styles & use as little groups as possible.


As the writer of the book (I’ll call it book, since I love the feeling of being a published author :sweat_smile:) I’ll just chip in that I honestly mostly agree with what you’re saying here. Its purpose is to share my perspective on how to think about performance, and identify and correct a lot of common mistakes that Bubble developers are making that slows applications down. As much as I of course appreciate the mention, I don’t want to sell the book as something it’s not. It’s not an in-depth technical documentation of the why’s, but more of an easy-to-understand guide to the how’s. There are several reasons for this: one being that the intended audience is people who were attracted to Bubble precisely because their knowledge of web development are limited, and another being that there’s a lot about how Bubble performs that’s hidden away in their servers without us being able to research it In this regard, I agree that Bubble’s documentation leaves a lot to be desired, but I also think that a technical documentation is probably better handled by them (since a third party like myself will have a difficult time keeping it up to date).

I do know that Bubble’s documentation is undergoing an upgrade, and hopefully it will shed light on more technical details than it does today.

I’ve purposefully avoided going into details on “how big is the impact”, even though it has turned out the number one thing people want answered since the release. I thought about it and even did a lot of research and calculations trying to illustrate it, but my conclusion in more or less all of the cases ended up being “it depends”. I don’t disagree that it’s possible to measure impact in different scenarios (like setting up test pages as you mention), but I think the conclusions in many cases would be difficult to apply broadly. As much as I’d love to have straightforward answers, the range of apps that is created with Bubble and the different solutions (sometimes brilliant, sometimes… questionable) is simply too varied to give provide any data that would match all scenarios. I chose the approach of avoiding straight answers rather than providing set rules with a range of caveats. That being said, I would encourage and applaud anyone who invests their time in researching, learning and sharing their experiences here. I don’t by any means think that I have the final answers to everything performance-related or that someone can’t improve on the research and learning that I’ve done.

Ok, enough about me and the book.

  1. Yes, it does theoretically impact the search, but unless you are generating strings with hundreds or thousands of characters, the impact will be negligible.
  2. Styles are rendered inline in the HTML by Bubble, and that approach is not very efficient. The upcoming upgrade to the responsive engine will likely apply a more efficient way of rendering, but it’s not going to be available to the public for some time still. As for how big, I don’t have any good data that would help you out there, and again… it depends. On a general note, my educated guess would be that storing the styling info somewhere else (such as an Option Set) is probably more lightweight than using styles and then setting up conditions on every element. If you want your app to have a light mode/dark mode for example, I would probably save the styling info in an Option Set and use Bubble’s dynamic colors instead of Styles. So as with everything else, there are exceptions to every rule.
  3. There are three levels to that question: not having the element and workflows on the page at all would be the most efficient. Having them there, but hiding them would be less efficient, and having them there and showing them by default is the least efficient. So the answer to your question is yes, it will impact speed even if hidden, but less so.
  4. Additional constraints are more efficient
  5. Groups (and any other element) will slow down your page, and it’s generally wise (from a performance perspective) to use them sparingly. That being said, performance is of course not the only factor you should prioritize when building your app. Naturally, groups have their use, and are still necessary for all sorts of purposes.
  6. I don’t have a clear answer to this: my guess would be that it does not have a significant impact, but I can’t say for sure.
  7. I actually answered that without having read that part of your question first. See point 2.

Dear Petter,

One question/idea - I have landing pages, with 10 sections. All sections have some images (compressed) and text. If I load page it takes some time.

Would it make sense to hide all sections, and only show on scroll? Would it be faster to load or there’s no difference?

Thank you.