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 |
 |
 |
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 |
 |
 |
After parameter changes, GUI app |
After parameter changes, WDA app |
 |
 |
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 |
 |
 |
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
🙂