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.
@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.
Most certainly!. Those iOS devices are equipped with bleeding edge tech CPU integrated with a specifically designed OS that enforce you to use a specific browser (see above). For all the downside that the walled garden has, tight integration for JavaScript performance (read bubble) is not one of them.
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!
walled garden has, tight integration for JavaScript performance (read bubble) is not one of them.