Hey all!
I’m trying to optimize my app’s loading time and would love to get some inspiration on methods and best practices
It’s a sort of training app, with 3 main data types: Users, Days, Sessions.
(Days are also a datatype because they hold additional data about the user that cannot be held otherwise)
The main page has a repeating group that loads the current user’s sessions for any given day. Whenever a user clicks +1/-1 days it loads the previous/next day’s sessions, which takes a bit of time.
My question: are there ways to preload 2 days ahead, so that the server request time will happen ahead of the user clicking the +1/-1 days buttons?
And also, If there are any guides about the order in which bubble loads elements and data to the page I would love a reference, Couldn’t find it in the manual
Thanks a lot!
Hey @omerbialer1 ,
The best option is to experiment a bit with custom states, repeating groups that are hidden and shown based on conditions etc.
A couple of options come to mind.
- Bubble does smart stuff to optimize searches and show results relatively quick, so simply doing a search for today and the coming 2 days and filtering (using option filtered, see image below) those results to only show the current day might already be enough. Just to be sure, in the search retrieve the data for today and the coming two days and use :filtered to only show the results for today. From what I understand this way you retrieve all the data from the server and client side limit what is shown. When the user clicks +1 update the filters first and next the search.

If the solution above does not work the options below might work:
- Use pagination to limit the number or results in the repeating group.
- Use 1 repeating group to display data for the current day and 2 hidden repeating groups to retrieve data for tomorrow and the day after. When +1 day is clicked, you display another repeating group and you change the data source for the two hidden repeating groups to retrieve new data.
- Try the solution above using custom states. When a user clicks +1, update the custom states and use the custom states as a data source for the repeating group. One of the benefits of Bubble is that changes which occur server side are almost immidiately visible client side (whether this works well using custom states I’m’ not sure btw).
You can really get creative with Bubble, so maybe it is possible to combine the first option with the other two. Also you can schedule custom events, repeating groups can show merged data sets (f.i. a combination of a search and a custom state with a list of results of the same data type) and you can change a data source based on conditions etc. etc. So there are quite some options to play around with.
If you want to know more about performance optimization, Petter has a good book about it.
Best Regards,
Gerbert
https://mvp-design.tech
2 Likes
Hey @gerbertdelangen , thanks!
Your first option, of loading the entire list and filter it on the client side worked perfectly!
I’ve never used the :filtered option before and it was just what I needed.
Thanks again!
1 Like
Could someone knowledgeable please enlighten me… if I search for all records, then :filter on the client side, does this load in all records into the browser first, when using pagination?
I’ve got daisy chained filters that kicks in client side after the initial set of records are loaded. It works really fast and well, allowing users to quickly adjust filters on the fly, instantly seeing results, with no perceived additional searching or loading.
I can’t quite get my head around HOW it’s working so well? I mean, if it’s only loading in 15 records per page, and I’m applying a filter that can ‘see’ records 20 pages deeper… How’s this happening? Is it bubble efficiency magic, or am I actually unwittingly loading tonnes of data into the browser upfront? (But I think pagination prevents that?)
Would love to know…
1 Like