We created big apps, with multiple pages and multi sub-pages to fulfill many of our companies operational needs. We have split it in several apps already, separating the most we could without making the experience too disperse but still struggle with app performance lagginess and slow reaction times. What functionalities should we prevent using the most that have the biggest impact on performance?
One design pattern we found that caused significant slowness was having actions call other actions in a loop. Actions can be slow because they do a lot of setup and logging.
If you have a piece of shared JavaScript code that you need to execute over and over, considering putting it in the Custom Code section as regular JavaScript.
2 Likes
You will need to identify what part is having the most issue:
- Trigger an action but takes a long time to run the action, very likely the action process time designed is too long.
- Load too much data within one page, not just the data thatâs shown on the page, but the actual outcome from the code. Letâs say you have 5 actions each load 1000 records with 50 properties. On that page, you are loading a very large amount of data. This will slow down all the other actions and also increase the rendering time. You will need to consider server-side pagination. (Please note that app-level actions will create a load on all pages.)
- Complex app layout, list component within a list component for example, at a certain data amount, the whole page will become very slow. You will need to reduce designs like that.
- If you are doing a query of a large database, and do post processes, and it does take time, itâs never harmful to add a loading image just to get the âwatched pot never boilsâ feeling out.
Had been fighting speed for a while and eventually got through it, hope this helps.
1 Like
Thanks Simon for the info. We do have actions that take up to 8 seconds, but we use loading status for all of them. We also use server side pagination and even lowered page sizes from 100 to 40. It had a small positive impact but the slowness exists even if im not interacting with any action. Things as simple as changing tab, hovering over new rows. Opening dropdowns, writing in a input element. We do have a few component on each page but i cant say its ridiculous amount. one for example has 2 multitabs each with 7 tabs, and 8 modals. Is that enough to make the experience so laggy?
Hi Diego, thanks for the elaboration. From my personal experience with UIBakery, this is very likely to make things laggy. Of course, would need to know more about what you had put in tabs and modals to confirm this, but let me tell you one layout I tried on one dashboarding app.
- I have a multi-tab of 5 tabs.
- Each tab has 2 charts and 3 modals.
- Each modal has 1 table of records showing 100 records with server-side pagination.
This layout is already pretty laggy. These components create a larger page load, and they render from time to time, all of these will slow things down.
Letâs say you only have 1 table of 40 records in the layout you mentioned, including modals, (27+28)*40. The data size is already 1200 records, and if each record has a lot of fields, the data load is already high. And these tabs in tabs structure will also take up resources to render. Modal content is also rendered even if the user hasnât opened them.
Another strategy I tried is, if I need a large amount of data but to return only part of the data and process it. I put all data loading and processing in the action library. For example, for my dashboard, instead of loading couple of hundred of historical data, and process it into monthly summary on the page. I use action library and return only monthly summary data (so 12 data points). This had lightened up the page load for me, and of course, splitting big tables into pages would help.
I think UI Bakery also provides a service to host your app on a dedicated server which might help (I havenât tried it).
1 Like
Hi Diego,
I too have some performance problems, especially with low memory equipment.
In my experience, enable the âEnable renderer cachingâ option if you donât have it enabled.
Download the minimum amount of data required, if you can, nest the queries in a single action, since some previous versions support more than one select in a call.
Donât execute the actions automatically when you start the component, execute them only if you need them, especially if they are DB data downloads.
Since version 3.93.0 supports âswitch off rendering for hidden componentsâ switch all modals to âNo Renderedâ this improves performance. (the logic must match with how works âno renderedâ in the modals)
Check the logs, check that each action is executed when it should and takes a reasonable time, that they are not executed several times or that when you switch tabs you are not executing actions that should not be executed.
BR
2 Likes
Thanks Simon, for the reply. Ill try experimenting with some other layouts hoping it will help!
Yes⊠idk why but these pages consume so much memory⊠ive tested some pages that take over 1 gb of memory in the web browser when other websites such as gsheets that handle so much more data use way less⊠I seen the the enable render caching but ill def take a look and i still got to experiment with the non rendered component as i havent yet. Thanks again for suggestions