Mobile Performance Suffering? I Feel Like things Are... Well, Just Slower than in the Recent Past... Anyone?

Hmmm… Is it just me, or does it seem like, in the current version of Bubble, things aren’t performing as well on mobile? (Particularly Safari iOS.)

Feels like pages that make use of Toolbox functions (JS to Bubble, Expression, etc.) are more sluggish than in the recent past. I don’t CONSTANTLY benchmark things, but I have pages that use custom calendars and other JS features (that I’ve not touched in some days) than seem like they are taking A METRIC S-TON of more time to load than previously.

I’ve been doing a lot of work on my app lately, so perhaps the change is due to something else, but I’ve got the sneaking suspicion that either (1) throughput and processing power on my current plan (personal and the moment) are more restricted than before or (2) there are some inefficiencies introduced recently.

Anybody else experiencing something similar?


for me there there has been a direct correlation of things working differently on mobile since Bubble went through the branding change. Well it happened at the same time…maybe just coincidence…i hate change but things cant stand still

Can you see if its due to the new version of Toolbox, which came just before the branding change, by comparing versions …
v0.3.0 which didn’t get the plugin code minified
v1.0.0 which did have the plugin code minified
v1.0.1 (current) which has an additional small js to load as a workaround for being minified :stuck_out_tongue:

Testing for performance is hard though, taking into account caching and variable performance of Bubble’s shared servers.

Good tip, Misha. Im not sure which version is installed in my app. (I thought latest, but will check.)


Yeah, what I’m noticing become most noticeable in the last 48 hrs.

BTW, the thing that made me say this about Toolbox was that the thing that’s suffering the most is my custom calendar, which uses the technique cobubble originally posted with an Expression element to generate dates in a month.

A thing that used to be quite quick — changing “pages” to a new month is now notably slower and laggy.

Anyway, will check what I asked, but wanted to clarify my comment for you.

Hi @misha, Well, the current version of Toolbox used in my app is 0.3.0. I assume it’s safe-ish to upgrade to 1.0.1?


@misha: SO, tested 1.0.1 just now and it seems as if this is slightly faster.

My Calendar widget page – which is almost like an entire app in itself, really – was taking as long as 8+ seconds to initially complete loading on desktop yesterday. Of course, that inspired some changes that, overall, are good optimization improvements, but did not drastically improve performance.

Mobile loads of the same page were taking in excess of 15 seconds.

Today things are much snappier: Desktop version of same page is taking < 4 seconds to go from first element visible to fully ready calendar. Mobile is loading at around 10 seconds and paging to next/previous month is still more sluggish that it should be.

AS FAR AS TOOLBOX: I have been toggling back and forth between 0.3.0, 1.0.0 and 1.0.1. As you say, performance testing on Bubble is very hard. However, I do think there is a small speed improvement in 1.0.1 vs 0.3.0. (And actually, it may not be “small” – could be on the order of 20%.)

I’m observing occasional strangeness on Safari iOS in general with Bubble in addition to the overall bad performance I was seeing yesterday on both desktop and mobile. Last night, fonts were not loading properly and a lil’ bit ago today, I observed FA Icons not loading (on Safari iOS). Seems to be back to normal at the moment.

Anyway, I’m not sure if ANY of what I’m seeing specifically relates to Toolbox or whether it might be related to RG performance. Something’s changed a bit though of late.

At least today, performance does not abjectly suck…

Dunno what else to report on this!

Best Regards,

I got same issue, navigation pages was under 2 sec and now, > 10 sec.
See my last post : Navigation very fast between pages
Bubble is still in optimization process and progress.
Once in cache, pages on mobile are now at 5 sec.

Yeah, there seems to be some bug-a-licious stuff going on, but it’s hard to pin down. In general, I’m seeing slowness and weirdness strike at random times this week. It’s frustrating as it’s impossible to tell at times whether something is a “did I do that?” or a “did THEY do that?”

1 Like

My mobile version of the site isn’t directing properly…as if the domain doesn’t exist. I’ve never seen this happen. Desktop works just fine.

There could by many explanations for that and you might want to create a new topic if you’re having trouble getting it sorted. Sounds fairly orthogonal (but then who knows?) to the types of issues I’m reporting here (which are primarily around performance and, of course, drops in performance disproportionately affect mobile platforms)…

I’ve noticed the slowness as well on mobile browsers, but I also recently switched to a Dashboard setup where groups show and hide and wasn’t sure whether it was my updates or Bubble.

On mobile Safari I also noticed icons not showing up and text style loading incorrectly and then jumping to the correct style

Yeah, there’s been some kind of mobile loading shenanigans going on for sure.

I DO also feel that certain types of complex repeating groups are – for some reason that I can’t determine – performing more slowly than in the past. I don’t know if it has to do with conditional states on objects in the cells, JavaScript element executions or something more basic. At any rate (and others MUST be noticing this), the custom calendar hack/technique seems WAY less performant than it used to be.

(I KNOW the Bubble folks would say something like, “Well, a 7x6 matrix of cells in a repeating group is kinda-sorta pushing it performance-wise.” And, while there is some truth to this, I haven’t yet met a modern browser or device that someone would actually be using that has had a big problem. For example, such calendars used to be a touch pokey on an iPhone 6, but they are markedly less responsive TODAY as opposed to just a couple of weeks ago. SOMETHING is going on, but I do not know what it is and so have no way to improve it except to optimize as many things as I DO have control over and hope for the best…)

That’s interesting, the code size difference due to minification is tiny (its not a large code base) … possibly there is a change in where the code gets hosted from, like a faster CDN.

Thanks for testing, @keith.

Wow, that is a long wait.

Are you loading the calendar with dynamic data from Bubble’s database? If you don’t need it to be automatically updated when it changes, you might make it faster with the list modifier
:make static

Hi @mishav,

Thanks for the reply. The calendar of course does need to get events from the database. What I do is load them into what I think of as “pre-loaded” Custom States. (In fact, I have to do this as some of the event data comes from my API which parses iCal URLs and returns all the events as a list of events — this has the problem of that data type, the events that come back from the API, are not “savable”.)

I do not, of course call the API synchronously, BTW, the values are already stored.

The values are filtered by only those events > current date/time. And even that filtering is done before reaching the page (it’s part of the API workflow). Point is, there is usually NOT a large amount of data being loaded. That part does not seem to be the bottleneck.

There are, of necessity, a couple of merges that must happen to the event values. But again this is lightweight.

I have experimented with :make static in this case and it seems to have no effect. (Not on oerformance and ALSO, not on the data shown.).

In fact, if the data changes while one is on the page (say, an event is added or the API to update the events by parsing an external iCalendar URL is called), the new events will show up in the calendar. I find this odd, but that’s what happens. I’m not sure WHEN :make static actually does what the reference says it does.

I’ve PM’d you a link so you can see for yourself how it behaves on loading. If you’re up for looking at my code I could send you that as well. There’s some clever stuff that I do with the JS to Bubble elements.

One thing that IS slowing this page is the calendar dates are clickable. That element a shape to take the clicks, has a large number of conditional states to figure out “is this day available or is it already booked?” “is this day selectable as the end date for the reservation?”, etc.

That “booked or not” condition is pretty complex as it invokes a :filter with Advanced criteria like “event’s start<-range->event’s end contains parent group’s date” (which is the calendar date in the RG that forms the calendar).

That condition evaluates slightly slower than the alternative way: If I load a list of individual dates and key off “List of Booked Dates contains parent group’s date”, that speeds things up A TOUCH. And that’s how I used to do it, but then I realized that a list of such dates is not necessary.

Anyway, Bubble can be weird sometimes.

Its a nice looking calendar widget : )

If each day on the calendar has to do lots of these, then yes a likely candidate for being slow.

Would it suit your app to move the criteria/logic into the javascript, and then passing the result from javascript, so clickable just becomes one condition? It might save a few round trips to and from the database.

[clickable list of booleans]#current cell number is yes
[clickable dates list] contains current cell's date

1 Like

Will give that a look.

This topic was automatically closed after 14 days. New replies are no longer allowed.