I’ve spent quite some time pouring through the various guides and posts getting my app to load faster. Thanks to all the great suggestions that have been posted, my app now loads much faster. However, I’ve reached a point where I don’t how much faster it can get on Bubble and if it’s even worth my time to shave off more. Feeling like there’s diminishing returns, yet I very much recognize the importance of a fast load. Here’s where I’m at:
I’m currently on the personal plan.
Public landing page loads very fast (within a second). The app itself is accessed via button/menu selection off the public landing page.
My app is on a sub-page. It’s a single page app, very complex. For a user who is already logged in, the load time is 8-10 seconds on a windows pc running Chrome. The first 4-5 seconds is a blank screen. The next 4-5 seconds are my app init workflows. Load times on mobile are much slower - up to twice as slow depending on the phone.
I realize it’s hard for people to answer without a lot of specifics (and I’m not quite to a point where I want to publish the link to my app) so I’m just looking for “directional” feedback. Have folks with complex single-page apps reached load times faster than 10 seconds on Bubble on Chrome/Windows? What’s a good Bubble load time to shoot for?
i would avoid single page app. the more elements on page the slower it loads
i usually try to have just 1 page load workflow if at all.
you can maybe move some page workflows to a workflow “do when condition is true: page loaded entire is yes” .
try to have only one repeating group that loads lots of data on the page
try to limit its number of items
or if you cant do that then try not to have 100 groups in it but just 3-5.
maximize use of option sets
dont have too many show if X conditionals on all kinds of things. especially ones with searches.
8-10 seconds is very long, especially since the user is already logged in, meaning that they’ve previously loaded the page and a lot of stuff would be cached.
I have a decently complex page and it loads in a couple seconds for a returning user, so either your page is completely over the top complex, or there’s some big culprit like a buggy plugin or a very inefficient client side search.
Google inspect tools should give you some sense of what’s happening on page load.
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.
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?)
OK, that’s great advice @ed727. I’ll keep searching through buggy plugins and data retrieval workflows & data sources as you and @TipLister suggest. Thank you.
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.”;
document.body.appendChild(newDiv);};
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?
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!
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.
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.
