It’s been like this for an hour now. Has anyone found a workaround for that? I remember reporting that issue to Bubble before, but they couldn’t fix it.
Why can’t it be a scheduled thing? I could just init and get the report later, like in the security checker.
Open the browser’s dev console. I bet you it is filled with errors.
Yeah, optimize application, should probably be a first class-citizen. I know the team is working on a new version of it and the target is to release it in 2025. 
2 Likes
It had only 6 errors related to something else, around 400 api calls, 6mb transferred data, mostly elements’ attributes.
Hope they fix that
It’s a known issue. Since it does it client side, there’s an upper limit for an app size - and if you exceed that, you’ll never be able to optimize the app again 
Bubble.io are aware. I’m on an enterprise plan and informed them and it’s been that way over a year so I doubt any movement is happening on this front.
This has been reported before. One of my apps can no longer use this action because it simply crashes.
I also hope that one day I can clear everything that’s on this (now huge) list.
I’ve already suggested adding some kind of filter. This action lists all items that are not in use, but there’s a category column. So maybe these categories could be used to allow us to select what we want to “search” for to optimize instead of searching everything by default. But I’m not sure about the level of nesting involved.
Maybe @georgecollier might have some ideas, since Buildprint handled the bubble JSON, which I believe is also the case here.
Is the failing of it related to the size of the app or the number of issues?
If you consistently optimize app every week on a larger app and always clear the issues, would it still fail?
These aren’t actually “issues”, but rather removed or unused items. So it’s related to the size of the app, but also to the time you’ve left the action unexecuted.
Apparently, when executing this action, it checks the entire app, so consider deleted items such as fields, data types, option sets, options, element-level properties, styles, reusable elements, etc. If the list is large, and it’s executed on the client side, it can easily crash the browser.
I think there should be some periodic alert about this optmization like that one about Bubble version update.
Surely there are many new users out there who have no idea this action exists, and when they find out, it will be too late.
Other things that can fail in large and complex apps are the App Search Tool not finding certain item references and the Issue Checker not identifying certain issues (this can happen even in small apps sometimes).
Yeah I know. I’m using it colloquially.
I mean, is it hanging on the size of the JSON or the # of things found?
Hypothetically if you were to always make sure the # of things found was 0, would it still eventually stop working past a certain app size?
I think it is a myth
I got your point. And indeed, that’s a good question.
So we have two cases here.
1 - The issue occurs because of the size of the JSON resulting from the app size (regardless of whether items are used or not and which could be listed as an optimization option). So it would be entirely related to the app size.
2 - The issue occurs because of the size of the list of items to be optimized that would be returned. In this case, the issue would be directly related to the number of items to be optimized and, therefore, the frequency with which the optimization is done. The longer it takes, the larger the list.
If it’s case 1, then we are all in the same boat. Nobody is safe from this if the app grows to a certain point in the future.
If it’s case 2, those who optimize with some frequency will be free from the issue, until the day they forget to optimize for a while.
I still think it’s case 1.
Hey @fede.bubble, could you take this to the team and give us a better answer?
In any case, are there plans for any future fixes? Maybe that could be a question for the next AMA with @emmanuel.