SAP Fiori Performance
Fiori performance depends on the whole stack, the UI5 app, the OData service, and the backend/CDS, plus network and caching. Good performance is designed; poor Fiori performance usually traces to over-fetching or heavy backend queries.
Fiori performance is won in the OData call and the CDS view behind it: fetch with $select, $filter and $top, page long lists, push aggregation down to HANA, and keep dynamic tiles from firing heavy queries. Measure the slow request in the browser developer tools and with ST05, SAT or a HANA plan before fixing the specific layer.
- Watch out: Over-fetching data without $filter/$top.
Where performance is won
- OData efficiency: use $select/$filter/$top so apps fetch minimal data.
- Backend/CDS: efficient CDS views and pushed-down aggregation on HANA.
- UI5: lazy loading, growing lists, avoiding huge client-side data.
- Caching: UI5 app resources cached; use the ABAP/UI5 cache buster correctly.
Common causes of slow apps
Apps that request too much data (no filtering/paging), CDS views that compute expensively without pushdown, and dynamic tiles that fire heavy queries are the usual culprits. On HANA the backend is fast, so needless round-trips and over-fetching dominate.
Measuring
Use browser developer tools to see OData call timing and payload size, and backend traces (ST05/SAT, HANA plan analysis) for the service/CDS. Measure the actual slow request rather than guessing, then fix the specific layer.
Design for performance
Prefer Fiori Elements (well-optimised patterns), fetch minimally, page large lists, and keep CDS views efficient. Small design choices in OData and CDS have large effects on the user-perceived speed of Fiori apps.
Common pitfalls
- Over-fetching data without $filter/$top.
- Expensive CDS views without pushdown.
- Too many/heavy dynamic tiles.