We kick off the year with a whole swathe of improvements being made to Bubble’s Core systems. The vast majority of these are geared towards improving the performance of your Bubble app, either via the editor or the processing of data.

Bubble Performance improvements

Possibly the most notable and important of these changes is the improvement of server capacity allocation. This improvement to resource allocation has three major benefits:

• Isolation of capacity that is used for scheduled workflows (Backend workflows), this prevents any backend workflows from having a negative impact on front-end performance. No more longer load times while the server is processing!

• Eliminating server capacity errors for in-progress workflows. This prevents partial runs of backend workflows due to capacity constraints, ensuring that any triggered items will run.

• Improvement of performance when running scheduled API workflows in bulk, not only increasing the speed at which the bulk operations are completed, but also minimising the risk of overloading the server with a bulk API workflow run.

Please note that these improvements will only affect applications that are on the “new” workload-based plans, as it’s around the optimisation of WU. Legacy plans will not see these benefits until they upgrade.

Bubble Page Load Speed

Another major win is that Bubble has made multiple passes on improving page load speed, with “more on the horizon”. Having faster page load times is always a major boon on the modern internet, where load times in excess of 2-3 seconds see significant user drop-off. Bubble apps have notoriously struggled with load times as the application grows, especially if it’s one of the more complex applications.

The most recent batch of improvements focusses on minimising the amount of unnecessary code being sent to the browser upon page request, meaning the initial load of the page will happen faster, hopefully boosting user retention. The thing to note about “unnecessary code” is that it’s not always “unnecessary” in the terms of webpage function, but sometimes that it isn’t needed immediately for page load.

For example, page load (at least in the front-end) happens in two primary steps. The DOM load and Render. The DOM is the first step, and essentially boils down to telling the browser what page elements exist and their relation to each other. This might be positioning on the page (order), etc. It typically boils down to the HTML elements.

The Render step is effectively everything else not rendered in the DOM load and often accounts for the majority of the time taken. Until this is completed, you may notice some elements of the page missing, especially images/videos. If you were using the internet routinely back in the 00’s or earlier, you likely remember seeing images slowly appearing on the screen in a “scrolling” fashion. Improvements to modern technology have improved this time significantly, but it’s the same principle none-the-less.

One of Bubble’s changes, for example, is cutting the size of their Javascript Payload (the Javascript sent to the browser on page load) by 7%, meaning that the browser has to load 300Kb less per page, invariably speeding things up.

There’s plenty of other, smaller changes that Bubble has been making under the hood to improve performance further, with plenty more to come! If you’re interested in keeping your finger on the pulse, so to say, it’s well worth checking out the Bubble Forums from time to time, you can usually find the latest changes and updates posted there as they happen.