Release of Deferred Drawing Logic for performance improvements

Hello everyone!

We’re excited to announce the addition of Deferred Drawing Logic to the experimental features panel!

Deferred Drawing is a feature that allows elements to wait until they need to draw themselves to actually draw themselves. This should not result in any visible changes but should provide some nice performance gains - especially for single page apps! If you’d like to share your thoughts while testing this feature, please submit feedback using the experimental features panel.

Hope this is useful to people, and happy bubbling!


I don’t see it? I only see the other two…

Hi @gaimed, can you try hard refreshing your page (cmd-shift-r vs cmd-r) and letting us know if that works?

Not working. Can it be because I am on the scheduled release?

Yes, if you’re on scheduled releases, you’ll see the change/deploy tomorrow! Please let us know if you don’t see it then.

1 Like

So excited for this feature! I did some before and after videos on my app (which is a single page design) if anyone is interested.



Looks like quite a big improvement to me so far :raised_hands:


Wow! That looks amazing, @jamesdevonport clear difference!

1 Like

You’re saying the magic words we all want to hear! :grin: :star_struck: :partying_face:

My app’s on the scheduled release tier but I can’t wait to test it out! We have a pretty hefty index page that’s practically a single page app and then the rest of the functionality happens on various other pages, so I’m intrigued to see what effect this will have.

Could you share a bit of the behind the scenes magic that you guys are doing so I know what to look for.

1 Like

Neat! I’m hoping at some point soon pagespeed insights will improve drastically…

1 Like

Nice! Would love to see some in-depth performance improvement tests from someone that has a heavy application running (+ some time to spare) :slight_smile:

1 Like

@alex.stanescu Still not seeing this on the scheduled tier release

Yup, a pretty significant performance gain, loads and displays much smoother than before. Many thanks for this, good work :+1:

1 Like

Hi Rico!

Essentially what we are did was separate out element creation into a “register” and an “initialize” step - the former will set up any data sources or states that might be needed before the element is visible but will do no drawing work. The latter then only runs once we actually need to draw the element (either because it became visible or because its size is needed to space out other elements). This allows significantly less work to be done at page load and spreads out that work to when you actually interact with each individual element. None of this should be actually visible outside of performance improvements though :slight_smile:


This should be out on the scheduled tier - can you double check that you are on the latest Bubble version (v16) and make sure you refresh your editor? If you’re still not seeing it can you let me know what app you are working on and I’ll take a look!


Magnificient. Now my development version is faster than Live version for the first time :blush: having been beta testing in development. It takes 1.3sec to load a page with over 100 groups. Currently live version takes 1.73sec to load. A 0.4 sec improvement in load speed is great . I can imagine due to caching property of live version this may reduce latency to 1sec< . Bravo Bubble Team @alex.stanescu


Will this work in apps using the old responsive engine??

Looks like a great update!

1 Like

I’m curious about this too. Will this change affect apps on the original responsive engine?

@design.agx and @sdharssi yes this will work for both the old and new responsive engine


@grace.hong @alex.stanescu

I’m working on a client app and I don’t have admin rights, so I can’t see if the client has subscribed to this as a feature to test, or if this feature has been rolled out.

Either way, what I am seeing is that when an element has a search in it, saw to show a list of things, and that search is the datasource of the RG, which is hidden and made visible via conditionals. There is a lag time between when the RG is made visible and when the data is displayed. Likely this is intended behavior as a way to speed up page load and help with performance, not needing to load data on hidden elements until they are visible.

One request is to add into this new feature a way for Bubble to automatically after the page has been loaded entirely to fetch the data for the elements that are hidden. I would assume that once the page has been loaded entirely and the page performance has benefited from this new feature, to have an automatic fetch of data would not drag on page load speed performance, but would significantly improve the user experience as the data would be readily available the moment the hidden RG is made visible.

Currently I am having to work around this as I do not want to see the lag time from the moment the hidden RG is made visible and the data is then loaded.

I posted a tip on how to work around it, which ultimately is still loading the data on page load, so the work around doesn’t provide the benefit of the new feature, but does get rid of the lag time.