Bubble best practices: how to make your app run fast (by AirDev)

Hi Bubblers,

Just wanted to share a resource that we put together based on many experiences of trying to make things run faster in Bubble:

Bubble best practices: Optimize for speed

Hope people find it helpful and definitely let me know if there are other techniques that should be included!

Canvas by AirDev


Thanks for this. I was just re-doing some tasks to improve the speed. This will be great to try and implement these ideas.

1 Like

I can’t seem to access the page. Maybe doesn’t work with IE?

Informative post and some good examples shown, thanks.

As an addition, I’ve also found speed playing a factor when using optimized custom web fonts uploaded through cloudfront and using compressed images (for parallax or large backgrounds).

1 Like

I thought IE had been discontinued :wink:

1 Like

I wish! They STILL use it at my job. Seems like a security risk to me. Oh well.


I think that unfortunately might be the case. Gitbook (which is used for this) says:

We design GitBook to support the latest web browsers. We support the current versions of Chrome, Firefox, Safari, and Microsoft Edge

Interesting! A couple follow up questions:

  1. Are you saying that optimized custom web fonts through cloudfront work faster than Bubble’s native fonts? OR that optimized custom web fonts through cloudfront work faster than those that are not through cloudfront?
  2. For compressed images, are you using Bubble’s native Imgix-powered compression? Or something else?

Really nice read @vlad

Hi Vlad,

Sorry, missed your reply here.

  1. Using the ‘shared assets and resources’ to host the fonts (.eot, .ttf…) via cloudfront, rather that the default uploader location on AWS, it seems to be a tad faster. However I unfortunately didn’t do a test prior to the switch over as to what the actual numbers are before and after. I guess this probably depends on the number of custom fonts being used, for less than 2, probably nothing to impressive, but more and its probably worth it.

  2. So yes, when I can, I’ll use the modifier to process with imgix to set the quality of an image (usually for me about 80% is fine and doesn’t comprise quality) along with using the ‘auto enhance’ feature to get the brightness levels up at bit. However with static and dynamic images, I’ll compress them locally before uploading them to either the in-element image or into the database to call from a ‘do a search for’. I use some free software Caesium (https://saerasoft.com/caesium/) which I’ve found does a good job at re-sizing and compressing with very minimal loss and shrinking kb or mb right down. Most of the images I’m talking about here are background images at large dimensions, this is where the file size can vary e.g. full viewport backgrounds. Probably for small sidebar graphics its not worth compressing locally, imgix should do the job. But say a large slideshow of half a dozen images, I feel its worth it.

I regret not doing some tests before and after the changes mentioned above, I feel like pages that were impacted run a bit faster, sure nothing game changing, but every little helps right :wink:
I’m tempted to run a few test with the fonts, as before it was noticeable on the network timings (3 custom fonts at around 700ms load time each). Also a quick test with some background images and the page load times with fresh cache would be worth some testing to evaluate if there really is a decent speed increase and if its worth the trouble…

1 Like

This is a really well-written and organized resource @vlad - thank you!

1 Like