Component trigger performance

Help & Support đź’»
1

Hello,

We’re brand-new to UI Bakery but have lots of experience with similar products.
Over the past week, we’ve been building some proof-of-concept applications to test if UI Bakery will fit our needs as a replacement for our current toolset.

We’ve only encountered 1 issue so far, and I wanted to ask the community if this is expected behavior or whether we are experiencing a problem unique to us.

In our app, we have a button. (The type of component doesn’t seem to matter, but I’m using a button for the sake of this example.)
We add an “On click” trigger to the component and link it to an action. (In this case, a page action, but we have the same result with an app action)
Our action has a single step: JavaScript code that increments a state.
When we trigger this action by clicking the button, there is a noticeable delay before the action is executed.
We are seeing a 400-600 millisecond delay before the action is executed.
Is this normal/expected behavior?

It is worth noting: If we execute the action manually from the bottom panel where the action is configured (By clicking the blue “Execute action” button) the execution is near immediate.
It only seems to be when actions are executed by the triggers of components.

It almost seems as if the trigger event is added to a queue where it awaits consumption, or is subject to some sort of debouncing.
For example, if I click the button multiple times in rapid succession, it will only execute the action once, after that brief delay mentioned above. (5 button clicks result in 1 action execution)

Thanks for any insights you might have.

2

Hi @Tom,

I have tested this on the on-prem and the cloud version. For the on-prem version, I measured a delay of about 250-260 ms. On the cloud version it was a bit more, with about 280-320 ms.
That said, 400-600 ms already seemed a bit much to me when reading it. I’m assuming you’re testing with the cloud version, right? And did you test this with an empty app/page or one that’s packed with components, actions, etc.?

Not sure about the debounce either. The fact that there is a “Server action” should mean that the default “Action” is run on the client side, indicating, as you say, a debounce. But that is something only the team can answer for us.

3

400-600 ms usually points to more than just the click handler itself. I’d test the same button with a no-op action on a blank page first, then compare that to the real page action. If the blank page is fast, the delay is probably coming from state re-evaluation, variable writes, or datasource refreshes chained off the trigger rather than the trigger dispatch itself. If it’s still slow on a blank page, that feels more like runtime debounce / product-side overhead and probably needs a UI Bakery answer. I’d start by stripping out any variable updates and refreshes in the action chain and timing each step.