Technical Articles
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:
- icm/HTTP/support_http2 set to TRUE
- wdisp/support_http2_to_backend set to TRUE
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:
- NAVIGATION_GUI_INPLACE set to TRUE
- NAVIGATION_WDA_INPLACE set to TRUE
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:
- NAVIGATION_GUI_STATEFUL_CONTAINER set to TRUE
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 🙂
Love it! We know and recommend these parameters… so wonderful to see some detailed measurements to encourage others. Thanks Luca! Great work
Hi Jocelyn, those recommendations have not made its way to my company 😉 I'm "just" a usability guy at my firm so I cannot help answering technical questions. However, I'd like to be able to point more to articles like Luca's in order to make my colleagues aware of performance tweaks that are ready to use.
I'd like to understand:
Best,
Hannes
Bonus 3.: (Consulting) companies make money with solving customer problems. If the problem is killed in the crib the company would no longer have a business case. To me this looks like a conflict of interest: companies are not that much interested in addressing root causes as this would render them obsolete? This is an issue where I'd like to have a more positive perspective on instead of being suspicious.
Hi Hannes
Thanks for your thoughts!
The general approach for most SAP solutions is to minimize disruption when upgrading. So we tend not to override existing settings by default.
Plus it usually takes some time between introducing a new setting and reaching agreement that this should be "best practice".
That said, we do try to introduce new best practices via our task lists and also increase awareness via blogs and videos. For example, these settings are now defaulted when running task list SAP_FIORI_FOUNDATION_S4 - see SAP Note 2712785 - Fiori Setup: Initial Setup for Fiori Applications S/4 e.g. via task Configure FLP for navigation.
As further options I would recommend my colleague Leslie's recent blog post SAP Fiori for SAP S/4HANA – Performance Optimization and Best Practice – Part 1 Tools and Tracing
Best
Jocelyn