The Ultimate Guide to Bubble Performance: Tips for Faster Page Load Speeds

Introduction

Welcome to the fast-paced world of app development where every second counts!

In this comprehensive guide, I will dive deep into the mechanics of Bubble.io, the leading no-code platform that's revolutionizing how apps are built. Whether you're a seasoned developer or just starting out, understanding how to fine-tune your app's performance is crucial.

I've titled this article "The Ultimate Guide to Bubble Performance" because I want you to be able to apply these measures, starting today, in your own bubble apps. Some of the measures are quick tips for bubble performance that will only take a few minutes to grasp and apply, while others will require more thought and planning.

In both cases, if you stick with me and follow through, your applications will surely benefit.

Let's embark on this journey to ensure your Bubble.io app runs as swiftly as possible!

Understanding Page Load Speed

Why obsess over milliseconds? Simple. Users expect rapid responses.

Page load speed is the amount of time it takes for the content on your app's pages to fully display.

Fast page load speeds are essential for user satisfaction and can greatly affect your app's success. After all, your users don't want to sit around waiting for your application to get its ducks in a row.

Page load speeds are also an important factor that Google takes into account when ranking content for its search engine. Scalable applications that solve problems are only great when real users can find them and put them to work.

Want free traffic from Google?

Then you need to study the tips and suggestions I'm going to share with you. I'll explore why speed matters and how Bubble incorporates features to help with this.

Real Performance vs. Perceived Performance - Why Both Are Important

There's more to performance than meets the eye.

'Real' performance refers to measurable load times, while 'perceived' performance is how quick an app feels to a user.

Both of these concepts are of vital importance.

Obviously, real performance contributes to perceived performance. If the page loads in 400ms, well that's great!

However, that's not always possible.

To understand why, you have to understand how Bubble works.

Bubble does not serve up static HTML web pages inserting dynamic data like a PHP application might. Instead, it uses javascript to automatically render the entire page dynamically.

While this allows Bubble to actually do what it does, it also means that the delicate dance between its servers and the users' browsers must be carefully orchestrated in order to deliver a smooth experience.

This means that sometimes you can take action on the client side to make the user feel like things are moving along quickly, while the server is working to prepare all of the data that is necessary to actually resolve the problem.

Striking a balance between the real and perceived performance can create a smooth and enjoyable experience.

Let's dig in and discuss strategies to achieve true performance optimization.

Things Bubble Already Does For You to Improve App Performance

One of the amazing things about building applications in bubble is that so many of the complexities of traditional web application development have been removed from the equation.

Bubble isolates its users from tons of the mundane issues that developers normally have to contend with.

And many of these built-in advantages contribute to being able to build scalable applications that perform well.

Compressing Images for Faster Loading

Bubble does some heavy lifting by automatically scaling and compressing images. This not only reduces file size (depending on the user's device) but it automatically hosts them in a world class content delivery network (CDN), which can significantly decrease page load times.

Later in this article I'll analyze how you can best take advantage of this feature and improve on it.

Leveraging Browser Caching for Enhanced Performance

Bubble leverages browser caching, storing certain parts of your app locally in the user's browser. This means repeat visits are faster because the browser doesn't need to reload everything.

By not needing to download all of these assets multiple times, the user can enjoy a more streamlined experience without even realizing that this is going on in the background.

Database Indexing and Optimization

Efficient data retrieval is key to any application.

Bubble uses database indexing to make data queries faster. However, the bubble developer doesn't need to worry about designing, implementing or maintaining these indexes. It all happens automatically in the background.

This is a huge benefit.

Proper database management is often a critical piece of an application developer's responsibilities. Taking this off our plate is an enormous benefit of building applications in bubble.

Later we'll explore additional database optimization techniques to ensure your app isn't held back by data bottlenecks.

Minifying CSS, JavaScript, and HTML

Minification is a process that shrinks code files, and yes, Bubble does this too. By removing unnecessary characters from CSS, JavaScript, and HTML, Bubble makes sure these files are as lean as possible.

We'll look into additional ways to minimize code and maximize speed.

Strategies to Improve Page Load Speed for Your Bubble App

Images, Fonts, Styles and CSS Issues

Every element on a page of your app has to come from somewhere.

That means that a server has to find each and every asset and send it to the user's browser so that it can be shown in precisely the right place. And this means that each asset has to be transmitted over the internet.

Obviously, page load speeds depend on the size and number of assets required.

Performance optimization is all about whittling down the amount of time it takes get this job done.

If you can shrink or eliminate elements on the page, the amount of work will be reduced as will the time it takes to render the page.

Images

An image speaks a thousand words but should not take a thousand seconds to load.

Images represent a significant percentage of the assets that need to be received in order to fully render your application's page.

So, what can you do to shrink them?

While Bubble already does quite a bit to resize and cache your images, you can also use the built-in integration with Imgix to compress and optimize them even more. Remember, every byte you save makes your page a little faster for your users.

Another aspect to take into account is the format of images that you decide to use. In general, I recommend using jpgs for static images and SVGs when an image needs to scale from small to large without losing quality.

However, that being said, it is important to understand that SVGs are not really images, at all.

Instead, they are actually micro-programs that the browser executes to render a vector image.

Vector images are cool because they are lightweight and can scale without losing quality.

However, these micro-programs do require that the browser works harder than just rendering an image file that it receives from the server.

For this reason, it's a good idea to only use SVGs when you really need to.

Too many vector images on the page will actually slow things down.

Fonts

To understand this section, you need to understand one of Bubble's peculiarities.

Any font that you use (even once) anywhere in your application will be loaded on every page of your application.

Read that again.

The price of one special font used once on some remote page of your application, is that Bubble will include that font in every page load of every page regardless of whether it's used on that page, or not.

Now let's do some math.

Imagine your application loads 5 fonts and that each font takes 200ms to download to the user's browser. 5 X 200 = 1000ms.

Yep, we're talking about a full second of additional load time on every page!

That's why fonts are critically important to bubble app performance.

And sometimes they are getting loaded without you even realizing it.

For example, some plugins may use their own default fonts for elements. Also, some themes that you purchase will come with styles that use specific fonts.

So, how do you solve this problem?

Use the network tab of the Google developer tools in your browser to see which fonts are being loaded on your page.

Next, go through your application and change the font choice for any elements that are using fonts that you don't need.

Finding these "remanent" fonts can be very challenging especially in a big app because Bubble doesn't have a function that let's you search for elements based on their fonts. If you absolutely get stuck, you can use the export app function in the settings section of the builder, and then search the XML file for the font name.

It's doable, but it won't be fun

Styles and CSS

Another great way to reduce the amount of information that you send to your users' browsers is to effectively utilize Bubble's style functionalities.

By creating styles and then using them in your application, the browser doesn't need to download unique styling information for every element on the page. This also makes changing the aspect of your app easier too! Also, remember to set your application font(s) in the style section and then set your elements to use the "App font".

In most cases, using styles reduces the amount of data sent to the browser and thus the time required to load the page.

However, you can go too far.

If you go crazy creating willy-nilly styles for every unique case, the strategy can backfire.

Your styles have to be downloaded to the browser in a CSS file, and if it grows too large, then you'll be shooting yourself in the foot.

For the one-off cases, the best choice is to use the style that most closely resembles what you want and then override the options that need to be different.

Optimizing Your Database Structure

Probably the single most important thing you need to get right to ensure that your bubble application performs well is your database design.

Bubble's database is a powerful engine, but it needs to be finely tuned to propel your application correctly.

A well-structured database is the backbone of a high-performing app.

And a poorly-structured database is a surefire recipe for disaster.

Let's discuss a few of the most important things to take into account.

User table

Every page load of your application will most likely load at least one record from the Users table (the current user).

This means that optimizing this table will affect your entire application.

So, try not to overload the User table.

In fact, anything that isn't absolutely necessary should be moved to an auxiliary table.

Saddlebag tables

Which brings me to the topic of saddlebag tables.

In the badlands of old New Mexico (where I was born), when the cowboys had to cross the desert on the backs of their sturdy steeds, they would put their most treasured possessions in the saddlebags that would hang from the horses' sides.

Why?

Because they are easy to carry, but can be left behind if the need to gallop presents itself.

Saddlebag tables serve a similar function.

As your application grows and you add new features and functions, many of your primary tables will tend to grow as well.

And this bloat can slow down your pages.

Why?

Because every time you do a search for this datatype, you'll be pulling in all of these fields to the browser (even if they are not being used). This can be especially painful if you have "heavy" data fields (blog posts, images, files...).

This is how bubble's database works, so you need to adapt your design to its reality.

To avoid this, it can be advantageous to break your main tables into the primary table (include the bare essentials) and link this table to your new saddlebag tables.

This way, you can avoid pulling data from the saddlebag tables unless it's actually required.

You do need to understand that taking this approach will require a bit more work when creating and deleting new entries.

Privacy rules

One quick fix is to spend some time reviewing the privacy rules for your main tables.

Why?

Because Bubble applies privacy rules before any searches that you execute are run.

By limiting the number of rows that are being considered in the search, you are making the searches faster.

This is why good privacy rules are not just a security feature of your application.

List fields

People ask this all the time.

Should I use "List of" fields in my tables or should I link out to separate tables.

And like all good questions, the answer is "it depends".

Bubble doesn't really offer us a true referential integrity functionality like most traditional databases do.

What does this mean?

Well, if you have a table of albums and each album contains a set of songs, Bubble doesn't automatically maintain the relationship in the way that those of us with SQL database experience would expect.

There are two ways to handle this relationship in Bubble.

In both cases we are going to need to create two separate data types: album and song.

Alternative 1 is to include in the album table a field called songs which is a list of records from the song table. This makes it super simple to operate on any particular album's songs. However, by itself this does not give us an easy way to navigate from an individual song to its album.

Alternative 2 is to simply store a field in the song datatype called "parent album". Then, we can easily do a search for songs who's "parent album" is equal to any one album.

Alternative 3 is to combine both of the previous.

Which is best?

In general I would recommend Alternative 3 as long as any single album isn't going to have hundreds or thousands of songs.

If, on the other hand, albums can have hundreds or thousands of songs, then Alternative 2 is probably the better choice.

Optimizing Your Workflows

Workflows in Bubble.io are powerful, but complexity can lead to delays. Simplifying your workflows can have a profound impact on performance.

Understanding where workflows are executing

One of the most important things a bubbler needs to understand when designing and building a bubble application is where things are actually being executed.

Is a workflow running on bubble's servers, inside the user's browser, or split between the two?

Page level workflows execute inside the user's browser, while backend workflows execute on the Bubble server.

Why is this important?

First of all, because you do not know how fast of a computer the user has. And second, the more work you push to the user's browser, the more data it will need and the more opportunities to seem slow.

Conclusion?

Structure your application in a way that offloads as much work as possible to backend workflows that won't effect the user's experience.

Understanding in what order workflows are executing

Because bubble workflows are organized in consecutive steps, many inexperienced bubblers think that this is how they run.

And they are dead wrong.

In order to maximize performance, bubble will, by default, try to execute all steps of any given workflow simultaneously once the workflow is triggered.

There are two important exceptions to this rule.

If a step refers to "Result of step N..." then that step will wait until the referred to workflow action has completed.

If you trigger a custom event, the current workflow will not continue until this custom event has completed.

Why are these rules so important?

First, and foremost, to help you avoid unintended consequences of your workflows. Almost all of us have encountered pesky bugs caused by workflow steps executing before "previous" steps were finished.

Thus, if you want/need for your workflow to execute in a specific order, you must use the two rules mentioned above to make it work that way.

Workflow types that you should try to avoid

Not all workflows are created equal.

In fact, some workflows are especially hazardous regarding page load speeds. Let's dig in and learn about them.

On Page Load Workflows

Obviously, these workflows will execute every time your page is loaded.

This means that they will slow down the process of loading your page. Why? Because both the code and the data required to execute must first be downloaded to the browser before the page can actually load.

Sometimes they are necessary and unavoidable, but try your best to not use this type of workflow.

One alternative is to schedule a custom event to run N seconds after "page is loaded entirely". This is often just as good and will not slow down your page load speeds.

Do every N seconds

Like their names suggests, you are basically telling bubble to repeat this workflow every X amount of time from now until hell freezes over.

Does this sound like something that will be enjoyable for your user?

Do when condition is true (everytime)

While not as bad as the previous, this type of workflow can also be inviting disaster. Do you really know how many times this condition is going to be true?

Also, this type of workflow happens without the user having expressed intent. Basically, you're taking over the control of the experience without the user knowing why.

In general it's a poor design decision, but can be useful at times.

Be really careful with workflows that are inside reusable elements

If all of these types of workflows can be resource hogs, if you include them inside a reusable element, then you're just magnifying their probability of slowing things down.

For example, if the reusable is your header or footer, then you are forcing these workflows to execute on EVERY PAGE of your app. Is this really necessary?

If the reusable gets placed inside a repeating group, you could be forcing these workflows to execute multiple times on the same page!

Optimizing Your Conditionals

One of Bubble's most impressive features is the ability to associate conditionals to both on-screen elements as well as workflows and workflow actions.

However, in order to render something with a conditional the browser first needs to receive the data that will be required to evaluate the conditional.

And the longer it takes to evaluate the conditionals, the slower your page will load.

So, how can we optimize our conditionals so that they impact the application's performance as little as possible?

First by understanding how Bubble actually evaluates conditionals.

When you set up a conditional expression inside the bubble editor, you can combine separate boolean phrases using "ands" and "ors". This allows you to create truly powerful application behaviors depending on multiple factors.

But does how you set these up affect performance.

Yes, it does!

You see, Bubble evaluates conditionals from left to right, one after the other. And once the conditional is proven false, Bubble stops evaluating it and moves on.

This gives us the ability to make sure that we set up our conditionals in an optimized fashion.

Start off with the easiest ones first, and then proceed with the more complex conditionals.

For example, if you need to combine "Current user is logged in" with a database search "Do a search for .... :count > 0", put them in this order. Why? Because if the current user isn't logged in Bubble won't even have to attempt to do the search!

Which brings me to the topic of using the :count operator with a search.

First of all, it's clear that this type of search is going to be necessary. Often you need to know if the database contains any records that match a search criteria, and this is how you do it.

That being said, you do need to be careful with this type of searches.

Why?

Because they can require the database to parse large number of records in order to count how many results exist, and this can slow down your app.

Another tip is to always compare :count < 1 instead of :count = 0. The result is the same, but tests have shown that the first way of phrasing the conditional is quicker and consumes fewer workflow units than the latter.

Optimizing Your Searches

Data moves through your application like blood through your veins.

That's what apps do.

But for the data to flow efficiently you really need to be careful about how you do your searches.

The wonders and dangers of "Do a Search For"

Searches lie at the core of any bubble app.

However, they are not the only way to access data from the database.

For example, page data sources are a faster way to access a specific record in your database. Likewise, navigating through a datasource is faster than doing a search, as well. So, always try your best to avoid unnecessary searches.

But when they are necessary (which is frequently), you can also do quite a bit to optimize how well they work. Here are the key points:

• Implement good privacy rules
• Be careful about using the :count operator (remember, it needs to parse all the relevant data)
• Try not to include searches inside constraints for other searches
• Understand where your searches are being executed

Not all searches are created equal. Here's the lowdown:

Bubble will execute basic "Do a search for" searches that include constraints and sorts on the server and then send the results to the user's browser. This is the most efficient scenario, as it does most of the heavy lifting on the backend without depending on the user's computer resources.

But not all searches are so lucky.

Avoid :filtered and Advanced filtering

Whenever you include a :filter, :sort or an Advanced search constraint, these operations will be processed on the user's browser.

Why are these scenarios dangerous?

Let's consider an example.

Imagine that we have a table of customer invoices which contains 200,000 records in total, 50 of which belong to the customer "Big Joe".

If I do a normal search with the constraint Customer = "Big Joe", Bubble will execute this search on the server and transfer 50 records to the user's browser.

Now let's think about what happens if I just do an empty search and then add a :filter with the same Customer = "Big Joe" in the filter.

In this case, Bubble will send all 200,000 records to the browser and let the user's computer filter down the 50 records! What a disaster. This is guaranteed to produce slower performance.

Now, let's imagine that we've set up a privacy rule that only allows users to see their invoices?

In this case, we can just do an empty search and Bubble will return the 50 records we need directly to the browser without having to do any additional work!

Advanced constraint searches are similar to :filtered searches in that they are executed in the user's browser. Sometimes you'll need to do an advanced constraint, because that's the only way to get the data you need. But as a general rule of thumb, try to avoid them, if possible.

See how important it is to optimize your searches?

Optimizing Repeating Groups

Repeating groups are a fantastic feature of Bubble for displaying lists and grids, but they can be taxing on load times if you aren't careful.

You have to learn how to use them wisely in order to avoid performance pitfalls.

The most important thing to realize is that everything that happens inside a RG happens once for every record visible in the repeating group. Thus, repeating groups can act as echo chambers that multiply every operation held within the repeating group.

That's why you need to be especially careful with searches inside the repeating group. Sometimes it's necessary, but often you can structure your database in a way that minimizes the need.

Let's go back to the "Big Joe" example that we discussed above.

Now let's imagine that we have a repeating group that lists each of our 5000 customers and inside the repeating group we do 2 searches - one for the :count which returns the number of invoices and another with :sum which returns the total amount invoiced.

This repeating group is now forcing Bubble to do 10,000 additional database searches (they won't all execute at once, because Bubble is smart enough to only execute the visible ones, but still).

What is a better way to handle this problem.

Instead of putting the searches inside the repeating group, a better solution is to do an aggregate search that returns the unique id, number of invoices & total invoiced values and use this as the datasource for the repeating group. Bubble will run this search on backend and deliver the results in a way that is much easier for the user's browser to handle.

Another thing to be careful with are API calls that execute inside the RG. Just like with native bubble searches, these API calls will be executed multiple times, which can lead to lagging page load speeds.

Finally, you should use pagination functions whenever possible.

This way you can limit the impact of your repeating group's echo chamber multiplication effect. If the repeating group is only displaying 8 or 10 rows at the same time, then your searches and API calls will be much more manageable than a never ending, scrolling repeating group that knows no end.

Want a powerful performance impact? Optimize the heck out of your repeating groups!

The Truth About Bubble Plugins

Let's face it.

Who hasn't spent a few hours browsing the Bubble plugin marketplace?

It's kind of like walking the cookie aisle at Walmart.

Oh! That looks delicious!

I could maybe try this one out too!

Want to identify an amateur bubble app? Count the plugins. (Hint: If you have to scroll the list, you're in trouble.)

Just like with the cookies, you need to have some self discipline if you want to maintain a healthy application.

Plugins can extend the functionality of your app, but they can also slow it down.

Let's discuss how to choose and use plugins effectively, ensuring they don't become a hindrance to your app's speed.

The difference between Bubble plugins and marketplace plugins

Not all bubble plugins are created equal.

The first distinction to make is between Bubble's own plugins and third-party plugins available in the marketplace. While they all share the same screen, Bubble does not treat it's own plugins the same as external ones.

Many plugins will load their javascript libraries on every page of your application. Others may include a whole roster of API calls.

In the case of external plugins these scripts and API call definitions will be loaded on every page load of your app - regardless of whether the page makes use of them, or not.

This can be a real drain on your app's load times.

Here are my core recommendations about Bubble plugins:

• Be VERY judicious about using plugins, when in doubt, don't
• Try to make due with Bubble plugins whenever possible
• Plugins that implement a specific type of element on the page are usually OK as long as they don't load a bunch of scripts in your site's header.

This section is short, but don't underestimate it.

Plugins are one of the MAJOR causes of slow bubble applications. They can have a terrible negative performance impact.

Be ruthless and get rid of as many as you can! You won't be sorry.

Evaluating Your Current Performance Situation

If you're going to improve your application's page load speeds (and performance, in general) you're going to need a reliable way to measure where you stand.

And here's the thing - it's not as easy as it might seem.

First of all, many website performance tools just don't work well with bubble applications. So don't get overly worked up by poor scores on many "performance" tools like pingdom, etc. They can give you a rough estimate of page load speeds, but many of their recommendations just don't make sense (or aren't doable) in Bubble.

Another source of information are the stats that Bubble gives you inside the Logs tab of the editor. Just realize that these are aggregate numbers that only serve as another indicator.

Finally, you can check the javascript console of your bubble app and see the reported time to load any specific page. However, can't conclude that the "page loaded in x" messages are truly representative of the average across different geographies and user devices.

Last but not least, you also need to understand that page load speeds will also vary by:

• The first page load after modifying your app (will take considerably longer)
• Repeat visits to the same page (will be faster do to caching)
• Normal browser windows vs. incognito windows
• The Bubble plan that your app is running on

What About Lighthouse Scores?

Google's Lighthouse is a tool for improving the quality of web pages, including their speed. It gives you a set of scores based on performance, accessibility and seo metrics.

The goal is to get as close to a perfect 100 score, as possible.

However, the truth is that lighthouse scores don't treat Bubble applications all that well, as they were basically designed for traditional HTML sites.

You CAN get decent Lighthouse scores with bubble apps, but it takes lots of effort. Bubble's capacity to easily compete on Lighthouse scores is limited.

Fortunately, Bubble has announced that they are working on performance enhancements that will directly improve your bubble application's lighthouse scores.

Meanwhile, this article gives you literally hundreds of optimizations that you can apply to your application to improve both perceived and real performance.

Advanced Tips for Bubble Performance

All of the optimizations that we've seen so far cover the basics of how to build a sustainable, scalable user-friendly bubble application. These are the bread and butter of solid bubble web application development and are prerequisites to any subsequent strategy.

But like any great infomercial - wait, there's more!

I'm going to round out this Ultimate Guide to Bubble Performance by explaining some of the more advanced strategies that you can implement to go even further.

These tips for bubble apps that fly are slightly more complicated and will probably require a bit more effort, but if you're committed, then here we go!

Learn to Use Chrome's Developer Tools

Improving your app performance is a never-ending struggle.

It is not a do it and forget it sort of proposition.

Instead, it is more of a do it, do it again, and repeat over and over sort of proposition.

Every millisecond that you can shave off represents a small, but significant improvement.

But how do you keep going once you've done the obvious?

This is where you have to dive deep into the Google Chrome Developer Tools.

Chrome Developer Tools (which you can access from the View/Developer menu of your browser) offer a wealth of information to help you identify and fix performance issues. Mastering these tools can give you a significant edge in optimizing your app's speed.

Three tabs you need to get familiar with:

• Javascript console - here you can identify things that aren't working correctly
• Network tab - here you can see which assets are heaviest and which assets are taking the longest to load. (Use the sort and filter options to dig deeper).
• Lighthouse tab - here you can directly run Google's scoring algorithm and identify issues that need fixing. Remember that the Accessibility and SEO scores are important too!

I know, you're a bubbler, not a developer!

After all, that's why you're using Bubble in the first place.

But rest assured, getting familiar with the Google Chrome Developer Tools isn't that big of a job, and it's absolutely essential if you want to consistently improve your page load speeds.

Use Typesense to Improve Searches

Let's talk about Search with a capital "S".

Maybe you want to allow your users to search across all your blog posts. Maybe you want them to be able to search across some other large database table in your application.

Can you do this with a standard Bubble "do a Search for"? Yes, you can.

But the honest truth is that it will be expensive (lots of workflow units) as well as relatively slow.

That's where Typesense comes in.

Typesense is an open-source, typo-tolerant search engine that promises lightning-fast searches. Let's delve into how integrating Typesense can benefit your Bubble app's search capabilities.

As I mentioned, Bubble's search functionality over large datasets isn't great. It works, but it's not awesome by any stretch of the imagination.

Lots of people use the Fuzzysearch plugin to make user searches more flexible. And this also works, but it's not significantly better than just using the native search functions.

Another popular alternative is to use Algolia, but I'm reluctant to recommend it.

Algolia, which is a competitor of Typesense, is fast and will definitely improve over native search functions for large datasets. However, you'll need to use their plugin (which will slow your site down a tad) and as the volume of searches grows, their service can get expensive fairly quickly.

Instead I recommend using Scious search plugin and Typesense.

Together, this plugin combines with Typesense to provide first class search capabilities at a very affordable rate.

It does take some time and effort to set up, but the returns are definitely worth it.

Use Wureducer to Improve Data Load Times

Wureducer is a solution aimed at reducing the amount of data sent over the wire. We'll examine how it can help speed up your Bubble app by streamlining data loads.

By now everyone has heard about Bubble's workflow unit functions to measure server utilization. Basically, every time your application does something that requires the Bubble servers, the taximeter clicks on and starts counting. Depending on your plan you get a certain number of included WUs each month, and if you go over the limit, you'll need to pay an overage cost.

Thus, as your application grows, so will your bubble bill.

Another drawback is that Bubble relies on realtime polling of the database. This is really cool, when needed, but overkill when not. Sometimes, you REALLY want that latest change to the database to show up on-screen instantly, but often it really doesn't matter.

Unfortunately, Bubble doesn't have any functionality that allows your application's to cache data that isn't changing very often.

Enter a great plugin by Ab Advany (builder of Coalias.com) called WU Reducer.

Not only does this plugin save you money, but it also caches your DB calls on Cloudflare's edge network. This means your app doesn't have to be continually polling the database.

Setting up the plugin isn't as easy as just "do a search for" and it will require making changes to your application, but in many cases it is completely worth it.

Use a PWA app to improve Caching

With all the news about PWAs being turned off in the European Union, this section might be surprising.

However, the truth is that Google loves PWAs.

What is a PWA?

A progressive web application - basically it's a way to convert your web application into an app that can be downloaded to your user's device.

But why would I talk about this here?

First of all, because Google has already said that PWAs are good for SEO. So, anything you can do to improve your application's ranking is a good thing to keep in mind.

But most importantly, in my opinion, is that if done correctly, your PWA can help improve the way your application is cached on the user's browser - even if they never download it as a PWA!

This means that you can improve on Bubble's default caching strategies to make your application even zippier for your users.

This really only applies to subsequent page loads (after all, the first time you request an asset it has to come from somewhere), but after that it can be a real boost.

Progressier (https://progressier.com) is a great way to do this, if you're interested.

Consulting an Experience Bubble Agency for More Help

Well, if you've made it this far I can only offer you my congratulations!

I get it, this article is over 6000 words long, and I could very easily make it another 6,000 by digging even deeper into the topic.

Improving Bubble application performance is not a trivial matter, and it takes skill, dedication and a lot of hard work to pull off.

And that can be daunting.

Luckily, now that you understand the problem and have a pretty good grasp of what the solution looks like, you're in a great position to get some professional help.

After all, sometimes you need an expert's touch.

Partnering with an experienced Bubble agency like Ratio.dev can provide you with tailored solutions to improve your app's performance, while you focus on other aspects of your business.

If this is something that might be of help to you, feel free to reach out to us and we'll set up a call.

Conclusion

Final Thoughts on Enhancing Page Load Speed

Let me say this up front.

Bubble applications can be fast.

But to achieve this, you're going to need to do a whole lot of things right.

Sloppy bubblers create sloppy apps that struggle to withstand the trials of growth and evolution. However, with a good dose of dedication and discipline you can definitely make your application shine.

To wrap up, remember that optimizing your Bubble app's page load time is a continuous effort.

Stay vigilant, keep testing, and apply these tips to help your app soar past the competition. With the right strategies in place, you can provide a user experience that is not only seamless but also delightful.

So, take action and watch your app's performance reach new heights!

Finally, if you need help optimizing your Bubble application for performance, don't hesitate to reach out to us at Ratio.dev