"Lazy loading" in BPM means rendering or loading parts of a coach only when they are needed instead of at page load. Three mechanisms, from cheapest to most elaborate:
- UI Toolkit visibility: a section that is Hidden (not just invisible) is not rendered at all until its visibility changes; the Tab Section renders tabs lazily by default (Lazy render option) - the content of a tab is built when the tab is first shown. Use this for heavy tabs and collapsed panels (Collapsible Panel with "render on expand").
- Lazy data: load only the data of the visible part - bind a table to a page of records and fetch the next page with a Service Call when the user pages or scrolls (the table's pagination options); load detail objects when a row is selected instead of sending every detail to the browser.
- Custom coach view that defers rendering: in its load handler register an IntersectionObserver and build the DOM when the element scrolls into view; or render on a control event.
// custom view: render only when visible
var me = this, el = this.context.element, done = false;
var io = new IntersectionObserver(function (entries) {
if (done || !entries[0].isIntersecting) return;
done = true; io.disconnect();
me.render(); // heavy DOM / chart build
});
io.observe(el);What lazy loading cannot fix: a huge tw.local sent to the browser at coach start (all coach data is serialised with the page) - reduce the data or load it with services; and slow services called in the coach's load event - call them before the coach or in parallel (question 3122). Question 709 covers lazy loading of child coach views specifically.
References