Another question, in my startup workflows, I schedule a backend workflow to build a list. That backend workflow recursively calls itself until the list is built. Looking at Chrome Dev tools it looks as though that backend workflow might be the culprit. Does the app wait until a backend workflow is completed? I thought backend workflows simply ran asynchronously on the server.
the elements do not load but it does have to check every condition if element X is visible; more conditions more time spent.
does your app require that list/ask for that list in a datasource?
Yes per Bubble. They load but aren’t yet drawn. If they require any data, the data isn’t called until they are visible (unless something else is referencing the data in the invisible element). See Bubble manual below:
My understanding is that backend workflows don’t take time/resource away from the front-end stuff happening (because they are running on the back end), but they do take time/resource for the front-end to schedule.
Also as @TipLister is asking, how is the list being built by the backend interacting with the front end? Kind of hard to pinpoint this stuff in isolation.
I see. Thanks so much @ed727. I would guess then that it’s the sheer number of elements on my single page that’s causing it to take so long to load. I didn’t realize that the code behind every element (even non-visible elements) is sent on page load (bad on me). The app uses and presents a lot of data stored in a SQL DB in the cloud. I need a bunch of screens (around 20 floating groups) to allow the user to interact with the information. I also have about 15 popups. For the scope of the app, there’s no getting around needing that many screens. Does that sound like it’s over-the-top for a single page app?
RE: the list being built - the backend workflow builds the list that the front end can use at a later time. Seems to be pretty straightforward as the Bubble manual lays out and should just run asynchronously.
@TipLister - Yes, but after the app loads. Then the main screen is shown and the list is used as a data source. Also, might be too much info, but the list is stored between sessions and is not deleted/recreated fresh each time. It’s only modified or added to.
Hmm… I think the number of elements will impact speed at the margins, but when an app is very slow to load it’s usually not the elements. It’s usually: a) a buggy plugin; or b) something happening on the data side (like the app downloading tons of data onto the page which is then filtered client side).
If the issue isn’t easily visible via Google inspect and the Bubble debugger, best way to figure it out is trial and error. Duplicate the page in your test version, strip something away, and test the speed. Then strip something else and test again. Keep deconstructing the app and eventually you should find the culprit.
(PS on the backend recursive workflow, question is how long does it take to run and does the front end require it in order to do something prior to any user interaction?)
I’m a novice at using Inspect/Dev tools, but I think I’ve found something worth noting. Here’s what it’s showing me:
When I load my app I get a 4-5 second “stallout” where it’s just a blank screen. After that it appears like my app workflows kick in. It looks like it’s reporting an error on image retrieval or something like that? In the source, I see this:
newDiv.className = “warning-message-failure”;
newDiv.innerHTML = “Your browser was unable to load the application data. We’ve been notified of the issue. Please try again in a few moments and make sure not to use ad-blockers.”;
Is this an issue with an image or font loading or a bad plugin? It appears this stallout is half my problem. Any advice on how to further troubleshoot the issue?
Hi, unfortunately I’m a novice at google inspect as well. I know some of the basics from this performance guide (The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)), but that’s it.
I recall in some prior posts where people had speed issues it turned out to be a plugin, and there may be something in there about how they debugged it using Google.
Good luck and I’m interested to hear what you find!
so try to avoid any “do a search for:filtered”
try to only have “do a search for”
filtered is done on clients computer so this takes a while.
Update: Tested the app loading time on my son’s 2 year old IPhone running Chrome. To my surprise, the app loaded in about 4 seconds on the same home network. It didn’t have the 4 second blank screen stall at all. But on my desktop running Chrome, I can’t seem to get rid of that delay. Now I’m thinking it might be a security or anti-virus software issue that’s causing the issue. Good news is that the core Bubble element load, client side workflows and back end workflows are all performing quite well. Concluding that it is not related to size/complexity of single page app, searches, broken plugin, etc.
Possibly worth considering - are invisible RGs loading things like photos? For example - you might have a user data type feeding an RG, with photos as one of the RG elements. If so, you could try (and I have!) setting the data heavy visual element to be empty until it is visible, and then load the photo. Done like that the page will work while the photos continue to load.
Another approach with the list you’re generating with a B/E workflow is this:
Set the output to be a data field (rather than a state) eg; My List as a field in data type User, then set the output RG to show the list. As the list is built by the B/E workflow the RG list will change and show the new entries as they go on the list.
An equivalent approach (not sure if this works) is to use a state to store the output list, and each time the workflow adds to the list set the state as equal to the state plus list “new items”
It helps to clear the cache in your browser regularly when testing to get a more realistic sense of how it will load for a real user.
Hope that helps.
like everything you should know the target machine of the user. Apple iOS and their Achips are engineering marvels, but not everyone has access to a 24month old iPhone.
Thank you Shane. I do some of those things, but your idea of adding the list to the User data type has given me an idea. Appreciate it.
It’ll be interesting to see what impact the Bubble team’s recent focus on performance (as mentioned in Josh’s recent post) r will have on your question especially in relation to singe-page apps, RGs, and invisible elements.
Be sure to check the post out.
@lucas.ar Totally agree. My app will be used by the public, so it needs to be performant across all device types. I still don’t know why an older phone would perform better than a desktop computer. I’ve also tested my app on other Windows machines and I get the same stalling issue. I’m really starting to wonder if the Windows Defender/Firewall doesn’t play well with Bubble or something like that. I’ve cut a bug to Bubble to see if they can help figure it out.
There are a variety of different PC, mac and smartphone browsers, and there are slight differences between how each reads websites.
My guess continues to be that it’s a bad 3rd party plugin, mainly because that was the problem in the last couple of these that I weighed in on. Hopefully Bubble can figure something out. But even if not, if you dupe the app you can deconstruct (or reconstruct) it piece by piece and figure out what’s causing the issue.
@ed727 Just so I understand, you’re saying Chrome on a smartphone could handle buggy plug-in code differently/more efficiently than Chrome on a Windows machine?
I use about 8 plugins that aren’t what I would call “standard” in Bubble. I’m assuming the API Connector, SQL DB Connector, Toolbox, for example are not causing the problem. So I’ll try to deconstruct as you suggest and see if the load time improves on Windows/Chrome. Thanks.
Chrome on iOS is indeed Safari underneath (by apple store rules on browsers), so it´s not as comparable.
IMHO you should focus on performance gains on the least powerful device : aka laptops with 5y old hardware.
You should have at least 3 devices with that config, maybe your particular chrome on laptop is bloated of extensions? Chrome (read safari) on ios is certainly not.
I wanted to report back with where I ended up on this topic. As others have noted, we need Bubble to pursue some of the performance ideas laid out in the last December update because for those of us writing complex apps, sometimes there’s just no getting around the complexities. What’s under the hood needs to be as fast as possible for the apps we create to perform well. Here are some of my observations and conclusions, FWIW.
- I never could figure out the blank screen delay on Windows. Bubble support was great to work with and was able to replicate it, but wasn’t able to really fix anything.
- I attempted to reduce the delay myself by trying so many things, all from forum threads, the performance book, etc. Small improvements here or there, but nothing really major. I uninstalled plugins, rewrote queries, shifted workflows around, etc. etc. etc. Massive waste of time. I very much believe that as a Bubbler you can really mess things up as far as load time and app performance goes, but in my case the load time was due (I think) purely to the amount of screens/elements and the underlying code needs to be downloaded. In the end, Bubble holds the keys to the car here. Still have no idea why it works faster on IOS. I think @lucas.ar has the best theory on that.
- I did deconstruct the app and started to break it into multiple pages. For sure this works from a page load standpoint. I got my first screen to appear with no blank screen pause at all under Windows/Chrome. So for those who have an app structure that allows for breaking it apart this may be the best method to improve load times. For me, it was an end in itself. My app is a game and it’s too complex to be broken into multiple pages because of the communication that would have to happen between pages. Also, my app does perform well once loaded, and I would have been taking an in-game performance hit to break it across multiple pages even if I could have figured out how to do it.
- In the end, I was able to really improve the user experience by using a better loading screen and progress bar approach. I used to have the loading screen as the first page of my app, which wouldn’t even show until after the long Windows/Chrome pause. Instead, I duplicated the loading screen and kick it off immediately when the user presses the button to launch the app. The loading screen also has a progress bar on it. The workflow advances the progress bar, pauses for a second, advance the progress bar, etc. Then the last step of the workflow goes to the page where the app lives. For some reason, this really worked and greatly reduced the Windows pause. I think Bubble is smart enough to start loading the page ahead of the workflow. The overall load time was maybe a few seconds longer, but the user experience is much better as the app responds immediately to the button click and the user see things happening on the screen, thereby eliminating the “dead” time of the blank screen. Big win. I’m getting to the point where I can start showing the game to others, so you’ll soon be able to see exactly what I’ve done.
Hope this all makes sense and helps others in their pursuits of reducing load times. Thanks again to those on this thread who have helped me out!