Skip to Content
Technical Articles
Author's profile photo Luca Falavigna

Fiori performance parameters

SAP Fiori is a very complex web-based front-end, and sometimes users could notice a slower interaction with it if compared to fat clients (think of SAP GUI or SAP Business Client). This becomes even more evident in case of high network latency, which of course Fiori can’t be blamed for, but from an end user point of view it’s all Fiori’s fault 🙁

Luckily, there are a few options which you can enable to increase performances, especially if you’re running SAP S/4HANA 1809 or newer, which has all the options mentioned below readily available for you to try them out.

 

 

HTTP/2

HTTP/2 protocol is designed to bring new features to increase speed and performance over its predecessor HTTP/1.1, such as multiplexing of requests and prioritization.

In order to activate it on S/4HANA, we need to act on these parameters in either gateway or web dispatcher, depending on your landscape configuration:

 

Let’s test the performance by tracing the execution using Chrome DevTools, Performance function. I executed a simple scenario by opening two Fiori apps, one WebGUI app and finally one WDA app.

Before parameter changes After parameter changes
HTTP/2%20before HTTP/2%20after

We can see a slightly decrease in Scripting (-18%) and System time (-16%), which could lead to less waiting time for the screen to fully render.

 

 

In-place navigation

With in-place navigation is possible to open GUI and WDA apps in the same browser tab of Fiori Launchpad, mimicking what happens with Fiori UI5 apps.

In order to activate it on S/4HANA, we need to act on these parameters in FES system:

 

Let’s test the performance by tracing the execution using Chrome DevTools, Performance function. I executed a simple scenario by opening one GUI app and one WDA app.

Before parameter changes, GUI app Before parameter changes, WDA app
In-place%20before%20GUI In-place%20before%20WDA
After parameter changes, GUI app After parameter changes, WDA app
In-place%20after%20GUI In-place%20after%20WDA

We can see a dramatic performance improvement with significant decreases in Scripting (-70%) and System (-80%). This great performance gain is mostly due to the extra overhead saved when spawning another browser tab, which also does not impact anymore on the used RAM of the browser.

 

 

Stateful container

With stateful containers is possible to reuse the same application container used for a previously open app for subsequent execution of any GUI app, either the same app or a totally different one.

In order to activate it on S/4HANA, we need to act on these parameters in FES system:

 

Let’s test the performance by tracing the execution using Chrome DevTools, Performance function. I executed a simple scenario by opening one GUI app twice, measuring performances for the second app launch.

Before parameter change After parameter change
Stateful-Containers_Before Stateful-Containers_After

We can see a significant performance improvement with decreases in Scripting (-65%). This performance gain is due to the application container being reused for another application.

 

Final words

These parameters are quite easy to enable and bring immediate benefit, also noticeable from an human eye perspective. I hope they are useful to improve user experience for your users too 🙂

Assigned tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      Love it! We know and recommend these parameters… so wonderful to see some detailed measurements to encourage others. Thanks Luca! Great work