Skip to Content

UI5 Application: Approaches for Performance Improvement

I was recently asked by a customer to review an UI5 application and suggest improvements. One of its main complaint was performance. I thought of blogging my experience here so that it may be useful to fellow community members. So here it goes.

Reason for the slow performance can be put into two broad buckets.

1. Application: Application itself taking log time to respond, meaning slowness due to javascript code and libraries

2. Services: Slow performance of the data supplying services (REST services)

So it is important to identify the issues to find out the bottleneck and take actions.

The first step would be to open Chrome Development Tool and run the application. Go to Network Tab

See the below screenshot


All files starting with …./resources/sap/ are SAPUI5 library files. As you can see loading sap-ui-core.js itself has taken 1.52 seconds. SAPUI5 library is a heavy library and loading of this depends on the libraries you choose in your index file.

See the snippet below


In the above snippet, I have used controls both from desktop and mobile libraries hence browser has to load both the libraries which will delay your application load. Ensure that you do not have unwanted modules mentioned here.

Advice 1: It is better to avoid mixing the controls and also ensure that only required modules are specified in index file.

It is also possible that you might be using many third party libraries. Trying to load all of them initially (synchronously) would make your initial application load too slow. In such cases load libraries when required and also consider asynchronously loading libraries.

Read on how to load libraries asynchronously here written by Konstantin Anikeev.

Other options to explore are minification, and compression of files by the server before sending. Note that SAP Netweaver system’s ICM component supports GZIP compression.

Advice 2: Explore asynchronous loading of JS libraries. Also think about distributed library loading using, fnCallback), minification and compression.

You may also explore using cache buster mechanism to cache your application’s resources permanently. This feature seems to be useful for static resources like fonts, icons, images etc. (new thing to try!)

Both the above advises will speed-up the initial application load. Since the browser caches these files, further loading of the application does not get impacted by this.

Let us look at the second bucket of reasons. REST Services

We will consider REST services from SAP Netweaver Gateway system here.

In the application I was reviewing, I saw that there was an extra call to a Collection before every Insert/Update/Delete action. That was for getting the CSRF token. Calling a data intensive Collection just to get a CSRF token is not a right approach. Instead a READ should be employed, so that there is less load on the system and network. Also note that if you use methods of sap.ui.model.odata.ODataModel, you can completely avoid this call. When you create an instance of ODataModel, it fetches the CSRF token and automatically handles refetching and supplying with edit operations.

In Chrome Developer Tool, in the Network tab you can also see REST service calls. The other option is to use Gateway Performance Trace. Goto Transaction Code ‘/IWFND/TRACES’ in your Hub system. Activate the trace for the user, perform an operation on your application and find out number of calls to the OData service.

So here comes Advice 3: To fetch the CSRF token, use a least resource intensive call. Think about using ODataModel to avoid this call all together.

The other aspect with REST services is the amount of data fetched as well as sent.

Think about a data table, or a list where you are showing a array of data. At a time you may not be showing more than 100 rows for example. So it makes sense to use a $top=100 system query option. If you use UI5 APIs this will be default many a time. You need to ensure that the implementation of $top is right and efficient.

In the application I was reviewing, I saw that a Select was done fetching more than 20,000 entries, an authorization check made on them to filter those records and then only 100 records were returned. That was so non-efficient!!

So the Advice 4: Ensure that right amount of data is fetched and transmitted. Make sure to use $top and paging options and implement them right in the service.

Added on 24th Mar 2015

Advice 5: When adding a custom UI5 app into Fiori Launchpad, ensure that you add it as a ‘SAPUI5 Fiori App’. Not as ‘Other SAP Fiori App’.

If you add your app as ‘Other SAP Fiori App’, SAPUI5 library will be loaded again, thus significantly slowing the first loading of the app.

Let me know your comments and experiences.

You must be Logged on to comment or reply to a post.
    • Thanks Harish.

      $select is a tough one. Implementing $select in backend means dynamic select queries or many if-else conditions. Also if you are using BAPI's(like most cases) then you will not be able to make use of $select. It would reduce the amount of data over http, but so far I do not think it is worth the pain. Instead I would concentrate on designing the OData model efficiently.

      • Hi Krishna,

        SAP Netweaver Gateway's framework offers $select feature by default. So framework will take the pain of extracting the requested fields. I still feel that $select should be used to fetch the right amount of data.



  • Hi Krishna,

    Since UI 5 JS libraries are not cached by default when the creating a UI5 project in Eclipse, might I suggest using Cache Buster i.e.

    • resources/sap-ui-cachebuster/sap-ui-core.js

    Subsequent refreshes show a huge improvement in load times. See here for more details, SAPUI5 SDK - Demo Kit



    • Hi Raj, Thanks for the comment.

      You said 'Since UI 5 JS libraries are not cached by default ', but I do not agree with that. Browser always caches the libraries and refers from the cache, even if cache buster mechanism is not used.

      But it is possible that cache might have an expiry time and beyond which application will try to load it again from the server. So cache buster will help in permanently caching the library until an explicit trigger to refresh is received.

      I will add this suggestion to the blog. Thanks.

  • A wonderful post which provides an insight for performance improvement SAPUI5 applications. I have been looking for such an article since a long time. I personally found the SAPUI5 demos slow, so it seemed like it was loading too much and too many things together. However, it seems that it takes a long time for charts and graphs to render. I would like to hear your comments on that.

  • Hi Krishna,

    Thanks for the article. In our application we have GET  call to fetch the token and then we post the request. After reading your blog I changed the code to odata.create. I dint see any change in time taken as the call to GET the token is handled by create. Does it improve the performance or its to follow good coding practice.



  • Hi Krishna, thanks for the article!

    Another tools of Chrome Development Tool are Profiler and Timeline to check slow performance of application. In this tools we can see the consumptions of methods.

    An interesting article about that: