Alright speed fans, listen up. I’ve not got the solution to our Google Pagespeed problem, but I’ve been doing some research on my app and I’ve found some major points of improvement.
One of the most annoying things is I’m being told by the debug mode that my app is being slowed down by 2MB of searches, but you can’t find out where they’re coming from. I really don’t have a lot of searches in my app, and they’re hidden away somewhere that I can’t remember.
Now this process might seem rudimentary to some of my more developer-minded colleagues, but I’ve got no real coding or HTML web dev experience so this is how I rooted the big searches out:
Load your app with your developer tools switched on (I use Chrome, I find it easier). In the Network tab, look at the log of things being loaded. If you organise by descending size, you might see a few ‘mget’ lines. I had a few, for example, at like 700KB, 400KB, 300KB, etc. Click on the mget line to see more details, then go to the “Preview” tab, you’ll see a list of all the things being returned. Expand them to get to the unique ID of what’s being returned, then find out what that corresponds to in your app.
I discovered there’s a lot of data being returned when for example I set a condition like "When Current User’s School’s (1 item) Groups’ (10 items) Lessons (100 items) Posts:sorted(by creation date):first item (1 item)… ". I guess it needs to load up all results at each level until it gets to the Thing you’re looking for (can anyone with more Bubble knowledge confirm this??). When I set another condition to “When This Lesson’s Posts:sorted:first item…” it barely loads any data at all, comparatively.
Anyway, I hope this has made sense. I’m going on a major hunt for data hungry conditions and filters now. Basically, if you have a condition that requires calling a lot of levels of data to find one Thing, it might be sucking up your speed.