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!
You’re saying the magic words we all want to hear!
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.
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
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 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
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.
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