Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
kammaje_cis
Active Contributor

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 jQuery.sap.require(sModuleName, 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.

11 Comments
Labels in this area