There are several topics on the forum regarding performance but they deal with dozens of items and I’m seeking a more definitive answer from Bubblers on this question.
In general, which is better in terms of speed/loading, and overall app performance?
A single page with many hidden groups and many workflows
or… Multi page app with a lighter but still decent amount of elements and workflows per page, but similar number of visible elements
I’m not sure how true this is, but I have heard that elements that are not visible on page load do not tax the system, and typically the largest time consumer is initial page loads. If that’s the case, I would think that a single page app with many hidden groups / elements would be faster performance wise, but I’d like to hear others thoughts / experiences on this topic.
The other question I have is whether the total amount of workflows on a page is always loaded upon page load, or are only the ones that are referenced via a visible element loaded? Does anyone know…?
Any thoughts on this subject would be appreciated!
My understanding of elements is a bit different than what you’ve expressed – I believe all elements on a page are loaded, even if not visible, however hidden elements aren’t processed unless referenced in other conditions, etc.
I view the page load as first loading all the elements and then processing all the elements. So hiding elements benefits the latter but not the former.
Sticking strictly to your question of load performance, a single page app will be slower on page load (because there are more elements to load) but appear snappier from that point forward when compared to page navigation.
Using a single page is a bit slower for the initial page load (say 10-50% slower) but then incredibly quick when moving between groups (i.e., changes happen in well under a second - unless you’re loading RGs) instead of 3-6 seconds for a new page to load which is the norm for many pages on Bubble.
Our approach has been to find a middle ground between the two, so we put related “pages” together on a single page by putting each section within a group. And, we’ve got a handful of these multi-page pages. We also have a number of a pages that are stand alone, such as our about-us page, terms of service, etc. This works pretty well for us.
@mebeingken, thanks for the response, and that does indeed make sense. Quite interesting.
The initial load time for the logged in screen of my app can linger on the white screen of death for way longer than I would like, but once it loads it can be relatively snappy, however it sometimes does hang ups in certain spots. For instance, I noticed button elements that conditionally appear when a checkbox is checked sometimes do not render properly, etc, which can be incredibly frustrating, hence my exploration into this topic little deeper.
I initially wanted to set myself up to have my app on a single page incase I wanted to adapt to mobile, but I have decided for my MVP that I’m going to stick to browser based only, which then made me question whether the sheer number of elements, or just those visible on a single page were contributing to poor load times or certain load mistakes.
I was thinking that if I can parcel off some of these items into different pages that it could help performance of each page, but I think I’d rather have one larger initial loading phase and snappier from there, than having people waiting 5 seconds between multi-page loads or longer.
I think this is a good path forward, and my app mostly resembles what you describe here.
Are there any performance related tips that you can share to optimize the single page load when so many elements and workflows are involved. For instance, is it best (or make a discernible difference) to have elements tied to a style? That’s one example, but if you have others that would be great!
Also, are you guys aware of any tricks that would allow you to have a loading / “please be patient” screen while the large single page is initially loading…?
I’ve never tested the speed difference of using styles. I assume they help but only a very small amount (<1% faster). If anyone knows otherwise, please share your experience.
Speed tips for 1st page load:
Less content / few items = faster pages. Optimizing for the user experience often means keeping things simple for them (which also makes pages load faster).
I’d make sure you compress image sizes because that big images can crush page load times.
Be thoughtful when designing your database searches (i.e., multiple joins or nested searches are really slow, calculating a count is much faster than grabbing a single item, etc.)
Be thoughtful about how you use RGs. They typically load after everything else are can take a while to load. We’re starting to use Algolia to load data to some of ours and it makes a world of difference in terms of performance.
If you want to get more sophisticated, I suspect it’d be faster to load content above the folder first and then start loading content below the fold after that.
Hi guys…
Great questions @marktuff, and ones that occupied my mind for quite a while. I am now 6 months into a 12 month project and maybe my experience can help guide you.
Mine is a back-end event management system. I don’t mind if the initial page load is slow, as long as it is then snappy. Hence I have everything on a single page. When the page loads up, absolutely everything is hidden apart from the menu bar. The elements that can then be shown as the user works with the app are:
6 repeating groups with their own search/filter boxes for listing contacts, events, invoices etc.
34 Pop Up Reuseable Elements for editing specific data (each of which averages about 10 input field groups with ~8 elements in each group).
At the moment all works well, the page is super snappy, everything renders just fine, and the page is perfectly editable in real time in the Bubble environment. I’m sure I will reach a limit, but I haven’t yet. If I can, I’d like to get up to around 60 of the pop ups on the page.
This page takes 15 seconds to load which I am okay about. (Compared to 2.5 seconds for a simple page with a ~10 elements on it).
I am based in the UK, and at the moment, during the development phase, I’m just on a simple Personal plan.
Oh and also you may be interested to know that after many hours faffing around with fields being on auto-binding I gave up on that approach as sometimes data took too long to update and was lost as users flicked between the windows.
Yep, same thing. Just saying that I believe hidden elements ARE loaded (their code is included in the page load process,) but their “functionality” is NOT processed. For example, a hidden repeating group does get loaded, but it does not perform the search on its data source. The exception to that rule, is that if another element is visible and references a hidden elements data source, then that search would be performed.
To add my five cents to the discussion, I too think that there’s no given answer for what’s best. I have one app that’s quite search-heavy for example, that needs to allow users to alternate between different lists as part of the workflow. Setting up that on different pages would make the loading times unbearable to the point of almost rendering the app useless. So I’m willing to trade off a bit heaver initial loading time for a very snappy interface once it’s done.
Gmail is a good example of that. The interface and inbox does take a few seconds to load, but once it’s done, you can read as many different conversations and searches as you want without re-loading the page.
For a front page where you’ll want to think of page speed for SEO and conversion purposes, I’d try to make the page as small as possible, avoiding any searches at all if possible, making the “heavy lifting” happen on sub-pages where SEO is not as important or even blocked.
Another part of this discussion is reusable elements. Using them efficiently can really speed up both the editor and the app . I’ve found big pages with a lot of workflows can really bog down the editor, but it runs a lot smoother if the same workflows are contained within reusable elements.
And to illustrate, just take a look in the browser console. Here are two page loads of a page with one repeating group element that performs a search. You can search that the search (msearch) is absent when the element is hidden on page load…
I have so many elements that are individual styles, that I was hoping it would make a bigger difference. But I can do a test and report back my findings.
Regarding this:
By “above the fold” you are talking about just what is visible in the browser window, correct?
I haven’t been as frequent to the forum the past few months, but lately I have started to hear of this Algolia… what is this exactly?
@antony, thanks for sharing with us your experiences, definitely helpful!
I’m closer to you regarding load times but I’m likely at least ~15 seconds, which might actually be quite generous. I need to test page loads on newer machines as I’m a MacBook Air that’s 6+ years old, and it tends to hang up a little. What do you find the best tool to be when testing load times…?
Curious, while you page is loading 15 second, have you figured out any way to show a loading prompt of some sort? I’m worried to have a blank white screen for so long.
Also, your 34 Pop Up Reusable Elements… Just to be clear, are those all different Reusable Elements, or the same Reusable Element populated 34 different times on a single page?
Congrats on the progress you have made. You’re halfway through! It is quite a fun and interesting journey making our own apps! Thank you for contributing to this discussion.
My only testing so far is on my trusty little Dell XPS13…
… and yes, I’d like to find a way to fill the white screen. I read a post about how to do that quite recently. I think it is in the Performance Q&A thread:
When I find the specific reply I’ll post it here.
My 34 pop ups are all different. I also have other reuseables which get incorporated into these if the same set of elements or workflows are needed in multiple places.
Yes, thanks for the congrats. I’m loving the process, and I feel very happy that I will have a viable business at the end of it all, so all very motivating.
Above the fold = what’s visible in the browser without scrolling.
Algolia enables you to create a replica of your database that’s indexed for lightning fast searches. We’ve seen it used to load long repeating groups in 5-20ms and provide site-wide search that’s as fast as any of the big sites you use.
I’ve written about it a fair amount and am becoming a huge fan. I believe it solves a lot of performance problems for Bubble - mainly quickly loading RGs and sophisticated search that’s highly performant. It does take a bit of effort to set-up and maintain so it probably doesn’t make sense for prototypes but almost certainly does for production-grade applications.
If you’re looking to learn more, I’d search the forums for Algolia. I’ve written about it a fair amount and @mishav and @kramwe wrote a post on how to integrate it. As a community, we’re still just getting started with Algolia (so only a bit of documentation, etc.), but it’s almost certainly going to be a big thing for many bubblers down the road.
