New Experimental Performance Enhancements

@rpetribu That’s correct - these improvements will apply to any new responsive page, regardless of how they were created / upgraded.

@bubble38 That’s the idea :slightly_smiling_face:. Server-side HTML is definitely the major goal here, but there were fundamental ways our old elements code was incompatible with it. So, we had to rewrite a lot of the rendering in this new system, which is most of what this change is. In the process, we were able to easily support moving CSS to stylesheets.

Server-side HTML is many times more complex than server-side CSS, so I wanted to get the changes out now so we could get feedback / bug reports while working on the further improvements; ultimately, I am very excited by the changes this unlocks.

7 Likes

Ugh agree. Beyond missing the awesomeness of the new engine, new Bubble features like this will be out of reach.

1 Like

I can see your situation as equal as many Bubble customers!
It is a very sensitive situation.

@emmanuel @cal
I feel frustrated when I hear Bubble inform: “ok, we have news, but it only works so that it accepts to change/update its entire structure. Sorry.”

It’s not simple, when talking about business, to change something and just see what happens.
Bubble needs to think that we are not only students practicing, however we are entrepreneurs. We have to think about our customers too, and Bubble with us.

I believe Bubble could take into account not forgetting the customers who believed in the first idea and grew, somehow, within Bubble.

I beleive a good part of who is updating their APPs for the new features, are those who have small applications, or are just starting out. So it is east to fix some new issues in reason that update action.

So, please Bubble, don’t forget to help “yours primaries and loyal customers” to grow without creating situations where our current apps have to suffer great losses in order to receive “such new features”.

Remember that many of us have customers, business being practiced, so some changes that impact the continuity of companies and provive the service to “our customers”, certainly cannot be applied, if we will immediately have 1000 (or more) errors due to the changes and to absorb more hours (and costs) to fix them all.

Ps.: I hope I can be understood positively.
Ps.: Congratulations for always looking for updates.

2 Likes

Thank you, @cal ! There are a few bits not rending correctly. I’ll make a Loom video and message you.

Just added the feature yesterday, realized today that popups aren’t showing in the order they were before. Some are popping behind already shown popups, so you can’t interact with what’s being prompted.

Should I submit a bug report?

@bcart0v feel free to submit a bug report, or just DM a link to the page so I can take a look at it. Thanks!

@sam.morgan thanks! I just sent you a dm

@rico.trevisan I just bookmarked your message to keep you in my mind if I decide to hire someone for it, thanks!

My groups are not clickeables, will send you a DM too

great stuff bubble.

unlike some other comments I completely understand that this only works with new engine. Ofc, it is flexbox and not old responsive. One does not just simply make this feature work for both, believe me.
I understand you want special treatment for being a longtime user, but expecting this, is a little over the top.
I have just helped a client move over 30 pages, and it took me less than a week. Some of those pages were pretty bad. Reading something like “years” I cannot take seriously.

despite the frequency and impact of new features you are adding it is a little sad to see 3 bugs after every new feature release (and these are only the public ones discovered after a few hours). id probably consider testing it with 5-10 users, maybe even paying them, so that not everyone who clicks this upgrade has to fear consequences for an app that potentially goes live. as of current state I would recommend 0 of my clients to ever try experimental features. maybe i am getting it wrong and that is the idea here though.

3 Likes

That’s pretty much the point of why it’s released as an experimental feature that we can opt in and out of.

Opting in should mean that builders are willing to help in contributing to a stable release by reporting bugs and giving feedback.

3 Likes

A couple of improvements I’ve seen in some simple pages.


21 Likes

This is what I love to see! :heart_eyes:

2 Likes

Nice work @cal! Bubble gets better every day.

1 Like

Refreshing the test environment takes a lot longer with this option on.

Turn it off and the app refreshes immediately. With it on, it takes sometimes 1 min for the first load after a change. I’m guessing it has to do with all the server-side work it has to do every time.

My current strategy is to

  1. keep it off in test.
  2. When I’ve got a deployable version, I’ll turn it on
  3. do a smoke test
  4. deploy it
  5. turn it off in test.
  6. rinse-repeat 2-5
6 Likes

@rico.trevisan wow! that’s significant!

You’re exactly right - we do a bunch of server-side processing which we need to redo if a page is changed. We do cache the result for a good while so it should really only affect the first load of your page, but it does make development more annoying.

We’re looking into ways of speeding up this processing, or have it so while it’s processing it sends a less optimized version of the page, so that the page load isn’t ever going to be super-slow, just slightly slower since you’re missing the optimizations.

6 Likes

@cal Should we be expecting a performance boost on all pages, or are there any circumstances where the page will load slower? For e.g. if I’ve got a large single page app, will the initial page load//server-side processing offset any gains from the update? I’ve noticed the initial page load is quite slow when testing on development.

Also re: the above comment you’ve made, you mentioned the page has to be re-processed if changed which slows down initial page load - is this the same on production? For e,g, if I push a change from dev → live will the new page initially load slower on production? I push changes v regularly so this is important consideration.

@cal with this feature I have noticed that each element on the page has a specific class id for example class="bubble-element Text cmaMhaG1". Will this change with addition of new elements or I can use the class ID to modify the text, i,e when implementing dark mode?

@media (prefers-color-scheme: dark) { .bubble-element.Text.cmaMhaG1 { opacity : 0.10; } }

Accessing bubble-element.Text will be general and is constant for all text but just wanted clarification on the effect of adding a new text to a page to ids of existing text.

Thanks you

1 Like

@messly The initial page load by the first customer after a deploy to live will be a little bit slower, yes. However, once assets are generated, every subsequent load will be faster. As I mentioned above, we’re looking into improving the initial start-up time; for now, if 1 page load being slower is a deal-breaker, then I’d recommend leaving the feature off. However, I’d recommend trying the feature first - the performance gains may be enough for you to offset that for you.

@amos Good question - they will stay consistent, but I wouldn’t rely on them just yet (while we are in this experimental phase). The algorithm we use to generate those IDs may change throughout the course of this experimental run and that would break your CSS. For now, I’d stick with custom IDs if you want custom CSS (or use something like the Classify plugin if you need classes)

1 Like

Thanks