Skip to Content

UI5ers Buzz #29: Asynchronify your App

Asynchronous loading is one of the main drivers for improving the performance of your UI5 application. With asynchronous loading files are retrieved quickly in parallel.
Synchronous loading, on the other hand, fetches each file sequentially. This makes synchronous requests much slower and can even delay important tasks in the browser. The app will not respond to user interaction until the request is completed.

To avoid this, UI5 offers several areas where asynchronous behavior can be switched on and off.
The most prominent are of course setting data-sap-ui-preload=”async” in the bootstrap of the index.html and adding “async: true” to the creation of a sap.ui.component or a sap.ui.core.ComponentContainer.

But these are not the only places where this feature can speed up your app’s performance. Another very effective location for asynchronicity is the manifest.json, where you can enable asynchronous loading of views:

By adding “async”: true to the rootView section of sap.ui5, you ensure that the root view is loaded asynchronously.

"sap.ui5": {
  "rootView": {
    "viewName": "sap.ui.demo.worklist.view.App",
    "type": "XML",
    "async": true,
    "id": "app"

For all other views just add an “async” flag to the config section of routing in sap.ui5

"sap.ui5": {
  "routing": {
    "config": {
      "routerClass": "sap.m.routing.Router",
      "async": true,
      "viewType": "XML",
      "viewPath": "sap.ui.demo.worklist.view",

In preparation for upcoming changes that are part of the UI5 Evolution process, we also recommend that you refactor your code:
Simply follow the new asynchronous module definition syntax to get rid of synchronous APIs.

This means that you should not use and any longer, because they load and evaluate modules synchronously.

We recommend to use sap.ui.define or sap.ui.require instead, so that you don’t have to rely on global namespaces or lazy library loading.

Here is a small example on how such a refactoring could look like:

Within the UI5 framework there are some functionalities where synchronous requests are used internally. For most of them you can already use asynchronous alternatives in shape of JavaScript Promises, or you can change the synchronous behavior as shown below.

Whenever you want to load something after instantiating the UI5 app, add the async flag and run the code in the then part of the Promise.

Example: The loading of an additional library


should be written as

    sap.ui.getCore().loadLibrary("sap.m", {
     async: true

Another example: The request of a resource bundle

    var oBundle ={ 
     url: "" 

can be improved by{ 
     url: "", 
     async: true 
    }).then(function(oBundle) { ... }); 

At first it might look like lots of work to refactor existing code to asynchronous behavior. But it will be worth it! By transforming the modules you can make sure that you benefit from future enhancements of the UI5 evolution.

Previous Post: UI5ers Buzz #28

Have a great day,


Arnd is an Expert Developer at SAP. He discovered the art of programming on pocket calculators, legacy home computers and game consoles. Today his focus is mainly on Web development technologies and UI5.


You must be Logged on to comment or reply to a post.
  • I've tried to configure the asynchronous view loading as shown above, but it still produces synchronous XHRs via loadSyncXHR() if the views are not packed into Component-preload.js. Is this intended?

    • The loadSyncXHR might be triggered by the remaining APIs which don't have any asynchronous alternative yet. For example:

      • LocaleData, while being instantiated, fetches the CLDR file still synchronously: issue#2345.
      • sap/ui/core/Fragment.load is not async: issue#2462 (Fixed in 1.84).
      • Embedded views are loaded with sync XHR: issue#3112.
      • Models loaded with preload: true require sap/ui/thirdparty/* synchronously: issue#3134.
      • JS resources declared in manifest.json: sap.ui5/resources/js are fetched synchronously: issue#3137.

      As mentioned by Arnd vom Hofe, an mcve would help us greatly finding the issue quickly.