Our goal is for Bubble to be as fast as any comparable hand-built solution, and we’re very aware that in many scenarios we currently are not, so we are definitely sympathetic.
That said, we’ve run out of the majority of low-hanging fruit on the performance front: most potential speed optimizations on our end that we’re aware of require significant engineering efforts. At the moment, we’re investing in hiring and training engineers to build out our software development capacity. While we do this, our ability to tackle big projects is somewhat limited, although we hope that changes over the next few months.
So in practice, if you contact us about a specific performance issue, what you’ll generally get from us is advice on how to change things on your end to optimize your app, which might require making some compromises on your preferred design. (Although, occasionally a user report does identify an easy-to-fix issue we weren’t aware of that we can immediately address. This is the exception rather than the rule, however).
Some of the major things we’re aware of that we plan to address on our end include:
- The total size of the javascript we send to run an app is high, which can slow page load, especially on slower internet connections and older devices
- Because of the way we ignore null filters in searches, users often inadvertently request much more data than necessary in order to load the page (we plan to fix this in the short term, since it’s a relatively easy improvement compared to other things on this list)
- Writing data (creating, modifying, and deleting) is slower and more capacity-intensive than I believe it needs to be: I think there’s significant room to speed this up
- Likewise, importing large quantities of data can probably be significantly improved
- Currently, workflows must finish in under 5 minutes, which can make it challenging to do operations that touch large quantities of data in a reliable way. While the “Schedule API workflows on a list” action can sometimes be used to work around this, this action currently requires loading all the data that is to be modified, and then adding a scheduled task for each action in the list, which itself can hit the 5 minute limit
- Our debugger doesn’t always make it easy to identify what elements of the page load are slow and why
In general, the advice we give for improving performance on the user end:
- Whenever possible, build small, simple pages. This is often a better user experience for your users, and makes a big performance difference: the total number of elements displayed on the page is a big driver of performance.
- Think about what data you actually need to load in order to show the page, and just load that data. The largest driver for slow page loads other than total number of elements is total number of data items
- Avoid modifying data on every page load. Adjusting element states to track where users are on the page performs much better than modifying things in the database. Avoid modifying data in “do every X seconds” events and events that run automatically on page load or sign in.
- When you need to do a calculation that involves touching a lot of data, if possible, do it behind-the-scenes periodically using a scheduled workflow, then save the result and use it later, rather than doing it every time the user loads the page. For instance, if you want to show a total # of X on your homepage (like, your total number of signed-up users), periodically calculate it via a scheduled workflow, and save it to the database. That way, a homepage load only touches a single data item instead of touching every single user in your database.
These tips can make a big difference: I’ve often investigated a user app with performance problems and discovered that a single poorly-optimized search was driving 95% of the performance issues. Definitely use the capacity usage drill down chart on the logs tab to investigate where capacity is going. And as mentioned above, we plan to add additional tools to make it easier to find slow things that don’t show up in the capacity chart (for instance, seeing on page load which searches are loading the most data).
As far as the decision to upgrade to dedicated goes, the areas in which it helps the most are:
- Geography. While we may eventually offer shared plans hosted outside the US, this is likely at least a year away. If you’re in a location where hitting the Bubble servers are slow, dedicated can speed this up by moving the servers closer to you. We serve large static assets via AWS’s CDN, which should be fast regardless of geography (with some exceptions such as China), but fetching the page html and doing database queries requires hitting our servers.
- Operations that modify or read a lot of data. These typically run substantially faster on dedicated (though the above-mentioned improvements will still make a difference for dedicated customers as well). These operations can also often be sped up on share plans via adding more capacity, though dedicated has somewhat less overhead.
- Stability. The ability to test your app on our main cluster prior to upgrading to the latest Bubble code is very useful for situations where stability is highly important, and while dedicated clusters do go down, they are significantly less likely to be affected by a Bubble-wide outage than shared plans are.