A VBCS application that feels slow at 100 records per page load usually has the same root causes — too many REST calls on page load, large unfiltered data fetches, or DOM-heavy layouts that re-render unnecessarily. Here’s a systematic approach to fixing them.
Diagnose before optimising
Before changing anything, measure. Open the browser developer tools Network tab and reload the app. Look for:
- How many REST calls fire on page load?
- Which calls are slowest?
- Are any calls firing multiple times when they should fire once?
This takes five minutes and prevents optimising the wrong thing.
The most common performance problems
Too many REST calls on page load
Every REST-backed business object, service connection call, and dynamic reference list that auto-fetches on load adds latency. Audit your page lifecycle and defer anything that isn’t needed for the initial render.
Patterns that help:
- Fetch reference data (dropdowns, lookup lists) once at the application level, not on every page that uses them
- Use lazy loading for secondary panels and detail sections
- Replace auto-fetch on list components with explicit search-triggered fetches
Large unfiltered data fetches
A business object that fetches all 50,000 records to display in a table is a problem regardless of how fast the REST endpoint is. Always apply server-side filtering:
Filter expression: status = 'ACTIVE' AND created_date > last_30_days
Never fetch all and filter client-side. VBCS’s built-in table filter is a UI filter over already-fetched data, not a server-side query — set filterCriterion on the business object’s fetch parameters instead.
Unnecessary re-renders from variable bindings
Variables shared across many components cause widespread re-renders when updated. Structure your variable scope carefully: page-level variables for page-wide state, flow-level only for cross-page state, app-level sparingly.
Caching reference data at app level
For data that changes rarely (cost centres, currency codes, business unit names), fetch once on application startup and store in an app-level variable:
App → App Level: startup event → Call REST (reference data) → Assign to appVariables.refData
Every page then reads from appVariables.refData instead of making individual REST calls.
Table component performance
For tables with 500+ rows: enable virtual scrolling (scrollPolicy: 'loadMoreOnScroll'), limit initial fetch to 50 rows, and implement server-side sorting rather than sorting the client-side data array.