Common plugin practices that slow down your app?

Plugin builders
1

Hi all, anyone have any tips for what to avoid (while building plugins) if you want to not slow down your app? I’ve heard of apps slowing to a crawl (16s load time) after using several plugins, but are there practices to avoid to mitigate this? Like an obvious one would be not having 3rd party libraries that need to be loaded. Are there any others? I feel like there is a spectrum between a plugin that only has serverside actions that rely on node functions vs plugins with dozens of elements and multiple 3rd party library requirements.

2

I can’t remember if this is a myth or actual good practices, but I do a couple of things:

  • defaulting most elements to invisible and make them visible conditionally
  • if one of those items has a data source, I only add the source in the conditions tab (not the main one).
2 Likes
3

Yep I do this by default for all elements/data sources, even ignoring plugins. I wonder if there are more plugin-specific best practices.

Bubble programmers have called out plugins as being the biggest source of initial load time for certain apps, so I was just wondering what exactly I should be avoiding when building plugins.

4

My experience is that if an app is retrieving multiple data sources at once (also the total size of the data returned), it will slow down to a crawl since your app is writing multiple pieces of data into the DOM (your page) at once. Data Bubble retrieves has to be stored into DOM even if you use a plugin to write to local storage.

The only control we have is when data gets retrieved. So using conditional data sources help a lot. I prefer using workflows to store data in states which I then use as element data sources. This gives me complete control over when and if data loads. Unless I explicitly need real time updates…

Depending on what I anticipate is happening in a user journey, here are alternatives to realtime updates that I use when dealing with large lists:

  1. using my own plugin to track when the latest item in a search is changed. (I only return a unique ID so not the entire record is retrieved).
    This triggers an uptick in a state that tracks how many new records have been created. The user will see how many new records have been created and chooses when to retrieve the new records.
  2. using “Schedule a custom event” to poll for updates. eg. Load up to 50 records every 5 minutes.

Element rendering has hardly ever affected my apps in my experience. It’s always data loading that affects the user experience.

1 Like
5

Don’t put 3rd part libraries in shared section if only one plugin element needs it, instead load those libraries from the plugin element.

Other than the 3rd party library issue, I’m not sure there is much else to do to ensure a plugin doesn’t cause app to slow. Maybe just minimizing how much processing the plugin does by writing efficient code for the functions.

I personally have never experienced a plugin slowing down my apps other than 3rd party libraries getting loaded in shared section of plugin since they load even if an element of the plugin is not on page.

Try to avoid redundancy as well. Most of the time you might not even need an initialization function and can just use an update function.

And for Ways don’t set an action as server side unless used as server side. If you want returned results, but for client side action consider having an element that will expose the values instead so as to avoid the server if all you want is processed values being available for subsequent workflows.

2 Likes