Skip to Content
Author's profile photo Frederic Berg

SAPUI5 Application Startup Performance – Advanced Topics

After covering some of the basic aspects on how to improve the startup performance of SAPUI5 applications in my last post, I will cover some more advanced topics which nonetheless should apply to almost all applications.

Here’s the link to the post covering the basic aspects:

Basic Setup

We will start with a typical application which you can download right here:

I will deploy this application to HCP in a location rather far away from where I am located to get a real impression of how latency will affect the load times of this app.

The application itself will connect to the Northwind OData Service (V2 – Read Only). More information on this service can be found right here:

The data will be shown on the first page of the application directly when the app starts. This is a screenshot of the final application:

And here is the application structure.

This is a typical application structure (compare with the application which we set up in the first post:

Let’s see how this application performs right now:

Note: 29 requests, Finish in about 3,5s (uncached). 

This application is already using all performance optimizations described in the post linked above and still has some room for improvement. Let’s look at some common issues and fix them one by one.

1. Asynchronous Component Loading

Modern UI5 applications should attempt to completely remove synchronous processing (which is not yet completely possible, but we’re working on it).

Components however can be loaded asynchronously and this is the new best practice approach. Here’s the updated index.html inline script content:

		sap.ui.getCore().attachInit(function () {

				var oCompContainer = new sap.ui.core.ComponentContainer({
					height : "100%"

				new sap.m.Shell({
					app: oCompContainer,

				var oComponent = sap.ui.component({
					name: "myapp",
					manifestFirst: true,
					async: true


Let’s try to understand what is happening here.

We first create a component container (which is needed to render a component). Next, we pass the component container to our Shell control and directly start to render the Shell (using the placeAt function). This means, the Shell will become visible already very early on

Next we create our Component instance, specifying the asynchronous behaviour (async:true) and also make sure that SAPUI5 attempts to first load the manifest.json (manifestFirst:true). This is important since this file contains a list of all dependencies which can be loaded in parallel to the component preload and other files.

The Component provides a promise which will resolve eventually giving us the chance to finally connect the component container with this component instance. At this point in time, the component’s inner content will be rendered.

To sum this up:

  • We now load the component asynchronously
  • We also load all relevant dependencies in parallel to the component itself (based on the manifest dependencies)
  • The rendering of the Shell can already start while the other files are being loaded asynchronously

Note: manifest first, component-preload later

2. Language fallback causing 404s for properties files

The application I have created is not translated and currently only has one file. I simply do not plan to make this a multi-language application which is quite typical for standalone applications. However, this usually causes an issue when such an application is deployed on HCP since the platform does not perform a so called language fallback on the server.

Let’s have a closer look at the network trace again for my i18n file:

Oops. We just spent about 560ms trying to load the file since two additional requests were sent out and caused 404s (which by the way will not be cached and thus hurt our performance every time!).

The reason for this is that SAPUI5 is by default looking primarily at the language set in the browser which in my case happens to be en_US. The runtime will then try to load the best match and in case it does not find this file, falls back to just plain English (en). Since this file is also not part of the deployed application, the last fallback is to load the plain file.

We can easily fix this by chosing our prefered language of choice and setting up our application correctly.

First step, let’s rename our i18n file to

Next, let’s configure SAPUI5 to only use this language from now on:

	<!-- Bootstrapping UI5 -->
	<script id="sap-ui-bootstrap"
			data-sap-ui-resourceroots='{"myapp": "."}'>

Note: data-sap-ui-language=”en”

With this in place, let’s check out the network trace again:

Alright, much better. And with the latency we just eliminated we just saved between 340 – 520ms startup time (cached respectively uncached behavior).

3. Usage of OData Model V2

The application above already uses the automatic model creation feature based on a configuration in the manifest.json file. Here’s the setting:

		"models": {
			"i18n": {
				"type": "sap.ui.model.resource.ResourceModel",
				"settings": {
					"bundleName": "myapp.i18n.i18n"
			"": {
				"type": "sap.ui.model.odata.ODataModel",
				"dataSource": "mainService"

Note: The type “sap.ui.model.odata.ODataModel” 

The above namespace indicates that an outdated OData Model implementation will be used. This implementation had several defaults which e.g. caused synchronous requests for metadata files and other operations which were changed in the updated implementation which can be used with the corresponding namespace:


Let’s see how this affects our timeline:

Note: $metadata is synchronous, no parallel requests or JS processing possible for close to 220ms:

Let’s fix this by referencing the right V2 namespace in our manifest.json (alternatively, you can also omit the namespace – it’s the default now):

			"": {
				"type": "sap.ui.model.odata.v2.ODataModel",
				"dataSource": "mainService"

Here’s the new network trace:

Note: Parallel requests to the $metadata request.

That’s 220ms well spent with additional JS processing or parallel requests. Yeah!

4. Use model preload feature

Our OData model needs its metadata – I really cannot do much without it. So it would be beneficial to the overall performance if this request is send as early as possible (we don’t want to wait for this request to return later on when we try to load data or render something on the screen).

SAPUI5 has introduced a way to preload a model, effectively causing the metadata request to be sent out earlier than before.

Let’s add this to our manifest.json (and make sure you have switched to async component loaded as done before for this to work):

			"": {
				"type": "sap.ui.model.odata.v2.ODataModel",
				"dataSource": "mainService",
				"preload": true

Alright, let’s see the network trace again:

Note: The $metadata request is issued even before the component preload.

Great! This request can become potentially quite a bottleneck but is now issues as early as possible.

With all of these changes in place, the rednering already feels much smoother. Looking at the current network trace, there is still some smaller enhancement to our app:

Note: Two 404s which must be eliminated.

5. Eliminate all 404s

This step will depend a lot on your application. However, you should strive to understand the reason for every 404 which occurs as part of your application startup and attempt to get rid of it.

Keep in mind: 404s are not cached and their runtime will hit every user every time they start the application, even when all other resources are already in the browser cache.

I have applications waste around 2s due to 6(!) uncached 404s with a latency of roughly 350ms each. Now that is time wasted truly for nothing.

sap.m.Image: Density Awareness

I placed an image in the application content which should display a file called stars.png. SAPUI5 has a great feature by which the current screen resolution will be checked and if a high density screen has been detected, a higher resolution version of a certain image will automatically be loaded.

In my case, I have not provided this version (and I don’t plan on doing so). This causes an unecessary request to this high-res version of the image and simply be turned off (densityAware):

			<Image src="image/stars.png" height="20px" width="100%" densityAware="false"/>

Northwind read-only: Turn off token handling

Normally, OData operations are always sent to the server using a POST request which makes the usage of an XSRF token necessary for security reasons. Northwind does not support this feature which causes a 501 response. Let’s fix this by turning token handling off:

			"": {
				"type": "sap.ui.model.odata.v2.ODataModel",
				"dataSource": "mainService",
				"preload": true,
				"settings": {
					"tokenHandling": false

Note: XSRF tokens are required for accessing SAP Gateway Services


Conclusion and final performance measurement

Let’s have a final look at our cached performance of the application:

Note: Loaded in 1.1s, fully finished in 1.4s (with latency and OData calls).

This loading performance feels great, no more 404s, all files cached except for those which need to be read from the server for data access. Early initial rendering also improves the perceived performance.

Remember: This application loads its index.html from another continent (causing almost 200ms delay) and reads data from the Northwind service, adding another 220ms).

With all of the above in place, applications which do not require an OData call for their initial screen can aim for sub-second initial cached load times. The same is true if the inital screen only requires data which can be bundled in the application preload.
I hope these additional best-practices and hints will help you to further optimize your applications. Let me know in the comments in case you have any questions.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mike Doyle
      Mike Doyle

      Thanks Frederic for another great blog, full of practical tips.  It's great to see that improving performance is seen as a priority.  Modern users have high expectations for load times, even more so on mobile devices.

      I've noticed that with Fiori Cloud (i.e. running on HCP) the file versioning is based on the active version of the html5 application, rather than a timestamp for that file (as with the on-premise UI5 cache buster).  That means that the users will need to download every file again, even if I have only changed one.  Are there any plans to revisit that?

      Author's profile photo Kiran J
      Kiran J

      Thank you Federic.

      Author's profile photo Andrew WU
      Andrew WU

      Hi Frederic,

      I just found out that if you put the 'name' parameter inside the ComponentContainer like below, the Component.js will be initialized twice. Could you let me know why this happens?

      var oCompContainer = new sap.ui.core.ComponentContainer({
                                                    height : "100%"
                                                    name: "myapp"


      Author's profile photo Guru Raj
      Guru Raj


      How can i do this for on cloud application. I mean running application with Component.js and manifest.json only (no Index.html)

      <!-- Bootstrapping UI5 --> <script id="sap-ui-bootstrap" src="" data-sap-ui-libs="sap.m" data-sap-ui-theme="sap_belize" data-sap-ui-compatVersion="edge" data-sap-ui-preload="async" data-sap-ui-language="en" data-sap-ui-resourceroots='{"myapp": "."}'> </script>

      Gururaj Enamate

      Author's profile photo Prasim Jain
      Prasim Jain

      Very Helpful.. Thanks Frederic.

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer

      Great blog!

      I've been playing with UI5 performance as well. I think SAP has a long way making UI5 apps faster, but things started to get better. Your blog's a good example of it.

      I'd add one more thing in your example. You can also load your i18n files async:

      "models": {
      	"i18n": {
      		"type": "sap.ui.model.resource.ResourceModel",
      		"settings": {
      			"bundleName": "myapp.i18n.i18n"
      		"async": true


      Author's profile photo Venkatesha N
      Venkatesha N



      I tried giving '  "async": true'  for i18n--> it is still not supporting.


      Author's profile photo Mike Doyle
      Mike Doyle

      Another 404 that might come up is the request for the favicon.ico file.  I’ve written a blog about how to get rid of that one: Complete the branding of your UI5 apps with a favicon

      Author's profile photo Ronghai Huang
      Ronghai Huang


      Frederic Hi Fredreic, my customer draws already attention to your awesome blogs! 😀