Performance of the Spark / BPM UI Toolkit is good enough for most coaches; when it is not, the causes are almost always the same:
- Too many controls: every control is a coach view instance with its own DOM and JavaScript initialisation (a few ms each). A table with 20 columns of Text controls and 200 rows = 4,000 views - seconds. Fix: table pagination (page size 10-25), Output Text / read-only rendering for display columns (much lighter), fewer columns, lazy tabs (question 2439).
- Big data payloads: the coach is serialised with all of tw.local; 2 MB of JSON slows load regardless of the toolkit. Load details on demand with Service Calls.
- Formulas and events on large lists: a formula per row re-evaluates when any referenced control changes; keep them local (${../Qty}) and avoid whole-table formulas in rows.
- Repeated re-rendering: setting a bound list again (setData on the table) re-renders everything; update elements in place when possible.
- Old browsers / IE11: the toolkit's Bootstrap 3 + jQuery stack was tuned for them, but IE is 2-3x slower on the same coach; modern browsers are fine.
Measured on a typical claim form (60 controls, a 10-row table, 3 tabs): first render ~600-900 ms on a laptop, most of it the coach framework bootstrap, not the toolkit. Compared with hand-written custom coach views the toolkit costs a little in raw speed and saves a lot in development time; hybrid designs (toolkit for forms, one custom view for the one heavy widget - a large grid, a chart) get the best of both. The browser's performance profiler (Performance tab > record page load) shows exactly which views are expensive.
References