Skip to Content

Why I want my Fiori to run like a Ferrari

Ever since SAP announced the release of Fiori earlier this year I’ve been excited by the prospect of a renaissance in SAP’s UX/UI future.  The apps look gorgeous and the fact that they are positioned around HTML5 technologies (SAPUI5) and multi-channel support (eg. smartphones, tablets, desktops) makes them well positioned for the future.


And I was further impressed to see SAP make bold statements such as this one when I attended SAP TechEd 2013 in Las Vegas (the below from the session ‘TEC149 – SAP UX Strategy and UI Roadmap’) …

“All applications & UI technologies to converge to the Fiori concept.  The roadmap beyond the initial Suite applications is yet to be defined.”

(Source: Slide TEC149 page 62, SAP TechEd 2013 Las Vegas)

Oh, let’s not forget the fine print … “This is the current state of planning and may be changed by SAP at any time”.

But ever since I saw the first live demonstration of Fiori apps by an SAP representative, there is one thing that I’ve been a little uneasy about, and its this … I noticed it took a fair amount of time (and by that I mean well over 10 seconds) for the app to appear on a mobile device after being launched.  And I cast my mind back over a decade to the words of the usability guru Dr Jakob Nielson in his book ‘Designing Web Usability’ from 1999, where he makes this important observation based on usability studies …

“Download times rule the Web, and since most users have access speeds on the order of 28.8 kbps, Web pages can be no more than 3 KB if they are to download in one second …. Users do not keep their attention on the page if downloading exceeds 10 seconds, corresponding to 30 KB at modem speed. “

Source: Dr Jakob Nielson, ‘Designing Web Usability’ 1999

Now of course over a decade on from those observations, we no longer operate in a world of modems or 30KB websites.  Yet the world of mobile and slow or brittle networks has brought back similar challenges, and once again we need to be mindful of the need for lean web delivery.  Indeed some have taken it a little far with statements such as this (below someone quoting on Twitter what they heard at a conference) …

“You should never use a JavaScript library that you couldn’t store in the RAM of a Commodore 64.” (Source: unknown)

On a side note … if you are my vintage, you may remember that whilst a Commodore 64 had 64K or RAM, the available amount for the user was only 38K.  And if you want to be really nostalgic, try out this Commodore 64 emulator that someone wrote in HTML5 and JavaScript  But back to my point …

The current literature on the web describes Fiori as a set of ‘lightweight’ consumer-friendly applications from SAP.  But my anecdotal observations had me asking myself just how lightweight are these apps, from a client payload perspective?  So, I have had debates recently about how lean the Fiori apps (and the underlying SAPUI5 libraries) really are.  Or more accurately whether they should be leaner to improve the time to load Fiori app resources into the browser, and by extension improve the user experience.  Of course, that’s easier said than done when you want to build in a wealth of ‘enterprise-grade’ features … but that is the challenge for the engineers at SAP to tackle.

I discussed this with Njål Stabell from Neptune Software who I met at TechEd and has deep experience with SAPUI5.  He wrote a blog providing his analysis of how a custom SAPUI5 app would outperform an equivalent Web Dynpro ABAP app here … Performance comparison of ABAP WebDynpro and SAPUI5 with Neptune Application Designer.  But what was still missing was an analysis of Fiori apps against the equivalent Web Dynpro ABAP counterparts.

So recently I had the opportunity to implement some SAP Fiori apps for trial purposes, and at the same time measure such things as the performance and download size of the apps.  I was also able to compare against the equivalent Web Dynpro ABAP app provided by SAP.  Here are my findings…

Firstly I examined the payload to download the out-of-box SAP Fiori leave request app to a browser with an empty cache. 

Fiori leave request payload 1.png

In the above test (which I repeated half a dozen times) I noticed that a whopping 1MB (after 72% compression) of download with 84 separate HTTP requests is received the first time a browser attempts to render the Fiori leave request app.  Similar measurements were obtained for others, such as the leave approval app. In the above test the payload takes 14 seconds to retrieve over a high speed LAN.  However I also tested the worst case (which mobiles can sometimes exhibit) … satellite access with 600ms latency.  In this worst case scenario, the download took closer to 100 seconds to retrieve.

Next I examined the payload to download the equivalent out-of-box Web Dynpro ABAP leave request app with an empty browser cache.

WDA leave request payload 1.png

So the Web Dynpro ABAP leave request app delivered by SAP renders with around 280K of payload over 65 HTTP requests.  In the above test the data takes 9 seconds to retrieve. 

Effectively the Fiori leave app had a payload of almost four times that of the equivalent Web Dynpro ABAP leave app, with almost 30% more HTTP requests.  When the browser cache is full (ie. after first load), performance for both the Fiori app and Web Dynpro app is much better.

What I want to see in Fiori

I am an advocate of HTML5 (see my recent presentation on it) and by extension I believe that SAP’s foray into HTML5-based apps with Fiori and SAPUI5 is the appropriate approach, especially when combined with pace layering enablers such as NetWeaver Gateway. However, here’s what I would like to see in Fiori …

Basically, we find that whilst this first release of Fiori apps brings gorgeous design and an appropriate way forward, more attention needs to be paid to the user experience from the perspective of time to load the app.  All is well if you operate with fast networks to desktops.  But if serving these apps to remote locations or mobile devices, then other measures (eg. wrapping the Fiori apps in PhoneGap or SAP’s Kapsel) may be necessary (with the associated complexities and costs, such as potentially implementing SAP Mobile Platform if the use of Kapsel is desired).  In fact, that may explain why in recent SAP demonstrations of Fiori on mobiles, I have seen SAP demo with precisely this wrapping implemented – there is no initial delay in rendering the app.  Of course, when comparing with SAP’s Web Dynpro ABAP we are looking at a much more mature technology.  And SAP sought to optimise WDA over time … such as with the introduction of lightspeed rendering. (and in an ironic twist, Andreas Kunz tells me the original codename for SAPUI5 was ‘Phoenix’, and that name was derived based on what is faster than light speed …. being warp speed, which any Trekkers amongst you know was achieved by the spaceship Phoenix in the movie ‘Star Trek: First Contact’).

What would I like SAP to do? Well, provide a mechanism in the ICF to only serve what is necessary, and to consolidate resources to minimise HTTP requests and minify resources. For instance, a mechanism to automatically combine and minify JavaScript and CSS files etc.  Don’t think it is possible?  Well Google engineers pulled it off with their open source contribution of Google PageSpeed Module for Apache and Nginx web servers.  So I’m sure SAP’s engineers would be equally capable.  Or the open source community might.  In fact in the blog 13 reasons why SAP should open-source SAPUI5 by Jan Penninkhof there is a similar comment provided by M.Saad Siddiqui

Blog comment.png

In the course of research for this blog I noticed also similar concerns were raised by Tobias Hofmann in this blog … Remember, all I’m offering is the truth – nothing more – week 5

So there we have it.  Fiori delivers great looking apps. But from my perspective, if SAP is to be successful in the long run with Fiori, it needs to be lean, fast, and perfectly tuned for the environment it is built for …. to run better, like a Ferrari!  Lets hope SAP can take us there ….. fast.

You must be Logged on to comment or reply to a post.
  • Well done, well written and well researched, John.

    And thanks to the Open SAP BI4 course, I can follow what you are saying as well.

    We all want our apps to load fast - 100 seconds takes too long.

    • Hi Tammy,

      Thank you.  Coming from you, that means a lot to me.  Of course, 100 seconds is very much worse case scenario. But I have seen demos take much more than 10 seconds to render the initial screen when using 3G connections.



    • Hi Konstantin,

      Yeah, maybe a poor analogy to use the Ferrari reference.  And in any case, myself I drive a Toyota Yaris 😀 .



  • Nice post, John.

    I like the comparison with WDA, and without wanting to appear too facetious, I assume you also compared WDA and Fiori apps on a smartphone, for UI rendering and UX as well as responsiveness of startup? 😉

    Seriously though, I note your point about this being early days for Fiori as powered by SAPUI5, as compared to the more mature and tweaked WDA.

    Perhaps now that Fiori Wave 2 is almost upon us, I'm wondering if there may be a window of opportunity where things aren't as crazy busy for the teams to turn attention to exactly this sort of tooling and tuning. 

    Not only with HANA, but also everywhere else, is performance tuning as important as it ever was.


      • Hi Tammy / Jan,

        Personally I prefer to see the comment from Andreas Kunz (below) on this rather than from Vishal.  I don't think Vishal would be able to comment to any length other than to say something along the lines of 'we will continue to improve it'.



  • Hi John, nice post.

    I'll reiterate your call for request consolidation and minification. However, I think what this needs is a step up in the development environment for onPrem SAPUI5 builds. It would be much simpler to be able to do things like build a custom .min.js file if it were simple to know which elements were used in a UI5 app. But given that the current modularisation of app development is pretty much a bastardisation of BSP storage, there isn't much in the framework to allow it.

    Perhaps eclipse based tooling to view the UI5 app and visualise it would help (perhaps it would make it worse, I'm not convinced I want an app-designer type solution) but certainly the point that the current solution isn't "smart" in how it throws the pages of a Fiori app together to serve to the end user and could be made a lot "smarter" is one that I'd strongly agree with.

    I hope your call to improve the performance of the solution is heard by SAP and would be very interested if anyone from the SAPUI5 team has any news on if such work is in the current backlog and/or has been identified as a priority by customers/SAP.

    Thanks for re-raising this issue.


  • Hi John,

    I seem to rightly or wrongly recall when Phoenix was a set of cool Enterprise controls we could enable within our own HTML5 applications, and thought - cool - I might use some of these - but have now seen it to effectively be an enterprise UI framework on par with Web Dynpro; and while I can see the reason for this (especially liking the responsive grid, and list/tile controls), I do share the same concerns.

    When so many years ago, Google Web Toolkit was out there providing a true java compiled web development platform that produced highly optimised sites which resulted in applications with minimal roundtrips with caching handled pre-manifest files, automatic optimisation such as concatenated images within a reduced number of single background images with offsets to individual images (as an example); but to extend that example and jump to SAPUI5 today, the only option for leveraging background image offset (that I can tell) seems to be doing your own HTML code. And don't get me started on dealing with javascript files with horrible experience trying to get {[]}() right (noting I've switched to XML views now) - I think we're just trying to dumb down everything down too much for SAP developers rather than trying to open it up for non-SAP developers to get into SAP (which should be the goal IMO).

    That said, I can see a lot of functionality in the bootloader and various areas which show potential optimisation, but not sure how much is actually supported/used in Fiori already. Remember, marketing comes first, and this optimisation is probably not thought about as mandatory untill blogs like this occur and get explained to the powers that be at customers, and upset the marketing message.

    Anyway, hopefully the Kapsel secure browser will be one option before heading completely towards SMP, that may help with the ability to better control HTML5 offline manifest cache files (which I hear will address the concern with current browsers that do not handle caching perfectly (though I haven't experienced this)).

    FYI - Another thing people don't talk about much with Fiori is that it's a web app, so you need to somehow secure your mobile browser to access the corporate network; and that's where the secure browser may be a good fit also.

    Anyway, lots of random thoughts - really like some of the controls (for reference); and in essence, basic apps with SAPUI5 are very easy (though get much harder when you design the app limiting yourself to mostly sap.m libraries but without limiting yourself to just what happens out of the box).



          • Hi Sascha - I think you're coming from a different angle than the one I'm getting at. I care about all the things that make JAVA, .NET, etc; good when developing around compilation, not how it is interpreted (compiled or not) at runtime (though good performance counts).



        • So I had a first go at using CoffeeScript to build an SAPUI5 app. The app on Github is "SAPUI5-Fiori" (should be pretty familiar) and has a master branch with XML views and then two other branches:

          js - with "handcrafted" JavaScript views

          coffee - with CoffeeScript views that are then compiled to JavaScript

          Here's the repo, specifically a link to the 'coffee' branch:


      • My mention of CoffeeScript was more because of the clean syntax that might interest Matt, especially after his comment

        "...horrible experience trying to get {[]}() right"

        rather than the nature of CoffeeScript compiling into JavaScript.


  • There is a blog from John Wargo about Kapsel Enterprise Browser [1] made for Fiori. It looks like a pre-configured Cordova environment with all the Javascript and CSS already included plus some smart caching. Considering SAPUI5 mobile use cases with >80 requests and X MB transfered over the network, looks like SAP found its own workaround to make Fiori usable on EDGE/3G/4G networks.

    [1] posted using Google Chrome and SCN does not want me to be able to insert links when using Chrome, so I had to copy the link. Sorry.

    • Hi Tobias,

      Yes, although it is not obvious I did link off to that same blog from my blog.  As you (and others commenting on this post) say, it looks like this is SAP's current solution for improving the start-up performance of Fiori on mobiles.



  • Well researched and presented, John!

    I guess the KAPSEL Enterprise browser is on short term mitigation, long term there should be actual technology improvements. It's early days for sure, we will also have to come up with a good way of navigating LOTS of Fiori apps on mobile clients...

    • Thanks Frank.

      Yes, the KAPSEL path seems to be the 'work around' as Tobias calls it.  I just hope customers are aware of this that when paying dollars for Fiori, they may need to pay extra dollars if they wish to use KAPSEL (part of SAP Mobile Platform 3.0) to optimise performance of their Fiori apps on mobile devices.  I am aware of one customer that used PhoneGap (Cordova).



  • Hi John,

    Great blog.

    One thing kept nagging my mind though.

    Typically, Webdynpro apps have GZIP compression enabled. (and the source files are already minified as well (they look horrible btw))

    Did you compare the traffic size with a compression on both technologies enabled as well?

    My guess is that GZIP compression will make the minification obsolete.

    But then I'm also wondering if mobile browsers have support for compression.

    (I should look this up, if I weren't so lazy)

    edit: So I did and found some interesting stuff (though quite old already)

    embedding the images in CSS will increase the size of the CSS file, but reduce the number of roundtrips.

    GZIP is supported on all mainstream browsers (mobile and desktop)

    To reduce the number of roundtrips, you could also combine source files...

    These are all tricks you could do yourself, but I see your point that SAP should do it for us... or shouldn't they...? if we want SAPUI5 opensourced, we might as well contribute to it as well.

    • Hi Tom,

      Yes I did also separately trace the payloads using Charles Proxy (to cross-check the numbers I was seeing in HTTPWatch) and found that the Fiori payloads were already GZIP'd (so that means the 1MB is AFTER compression).  It was Charles Proxy that gave me the total compression amount of 72% for the Fiori payload.



  • Hi John,

    Thanks for the mention. Our customers normally package their Apps with Cordova/Phonegap so that the UI5 files are stored locally. We generally see very good performance with SAPUI5 compared to JQM and other frameworks we have used, so quite impressed with SAP there. Also caching of the models reduces the number of http requests and also gives offline capabilities for small apps like wokflow etc.

    Here is a custom UI5 Leave request template you can test networking on (compressed native json).



    • Thanks Njål,

      Sounds like you are the 3rd person in this thread pointing to Cordova/Phonegap or SAP's KAPSEL (which provides secure extensions to Cordova/Phonegap) as the solution to the start-up problem.  I guess customers should be aware of this and the added complexities (eg. deployment etc.) that it brings.



  • Well done John and another very good blog.

    It is important to note that many of the Fiori apps are for HCM therefore a company with 10K employee would have to pay the equivalent of 6 Ferrari's in order to get the functionality.  While I am a fan of the offering and direction I think that making HR Enterprise Software customers pay for this type of functionality in todays age of SaaS based solutions (most of which offer as part of the subscription) is a mistake and it should be funded by the maintenance dollars that customers pay each year.

    • Hi Jarret,

      Yes thanks.  You raise a great point.  Customers may be digging deep to pay big $Ferrari for Fiori and so they should expect Ferrari-like performance.  Yes I am with you that personally I wish SAP rolled out the new user interfaces for free, but that is a separate topic altogether.  It does remind me however of a comment I had from a CIO at a customer who said 'not paying SAP for new UIs.  Ringfencing and relying on .Net and Kony instead'.  If too many customers take this same type of path the UI future for the SAP ecosystem will become fractured with everyone taking their own paths.  Not something I think is good for the future of the product.

      It is perplexing however when you see things like HR Renewals (based on SAPUI5) distributed for no additional cost if you have the appropriate HCM licensing, whereas Fiori leave request and other Fiori HR apps (all based on SAPUI5) are not free.



      • Agree with all comments above. We are having same debate at moment. Why are we being asked to pay More $ if I just want to use employees / managers when we already have employee licenses. Not all HR  businesses will pay extra $ just so casual users can book leave via better UI. With SF, workday, etc offering mobility standard, in HR use case Fiori might be left behind. 

  • Just a quick comment: requests and footprint are one thing on the client, they are even worse on the server side and on the network.

    MB of data transmitted means also: somehow this needs to get delivered to the client. In a LAN, 1 MB is nothing, but having 10.000 users == 10.000 MB. Also, HTTP requests have an impact on the web server.

    Short: instead of utilizing the servers better, you'll have to do a new sizing and add new hardware. This means spending more money. Most probably that amount of money is the equivalent of a Ferrari.

    • Hi Tobias,

      THAT is a really good point.  One that I must admit didn't even register in my mind when I wrote the blog.

      Thanks for adding to the discussion.



    • Hi Tobias,

      I take your point, but that's what caching is for. The ICM's architecture allows is to handle requests to static resources very efficiently, e.g. by serving them out of either its hot in-memory cache or warm disk-based cache.

      I've done some load testing of this about a year ago: 200 requests/sec to an ICM-cached resource, with client-authenticated SSL connections (i.e. the worst kind) and a new TCP/SSL connection for each request resulted in the icman process on that (fairly aneamic dev server) to consume around 15% of CPU time on one core.

      So I wouldn't worry for public, static content. UI5's client-side rendering approach means that the vast majority of resources are static and thus easily cached. And if the ICM's not beefy enough, there's always Varnish 😉

      • Actually, I`d prefer to see ICM being shut down and SAP publish modules for Apache, IIS and the likes. I nice set of modules to integrate / manage the web server of your choice + the chance to use your DevOps tool of choice to control and configure your web server.

        This way customers can benefit from innovations done there, like SPDY, or be capable of utilizing the features available there, like reverse proxy and URL rewrite, instead of waiting for SAP implement this in their own stack (ICM, WD).

        Maybe this way useful tools like a nodejs <-> BAPI connector would have it easier to emerge.

        I guess this is not aligned with the "simplification of layers" approach SAP is seeking to follow, also putting all the layers in one server is centralization

        • Hi Tobias

          Perhaps Sascha Wenninger or John Moy would guess I'd chime in here, so I didn't want to disappoint ... 🙂

          I must ask you: if the ICM is shut down, how do you see the close and very powerful integration with the ABAP stack (via the ICF) working in the scenarios you describe (Apache, IIS, etc)?


          • Why does SAP enforces me to use their web server? Given the right architecture, there won't be a "close and [not so] very powerful" integration needed. Customers, developers could focus on what is important instead of fighting problems created by this "close and very powerful integration".

          • I'm not sure if you're trolling or not, Tobias, but in any case, I'll bite.

            SAP doesn't enforce you, or me, to do anything. I use SAP's ICM/ICF combo, I also use Apache (I guess they call it httpd these days), sometime nginx, etc. You get the idea. If you don't want to use the ICM/ICF, well, err, don't use it.

            The close and powerful integration I was referring to was the short distance between the HTTP request/response processing and the business logic I am dealing with in the back end.

            Can you give me examples of what you mean by "fighting problems created by this 'close and very powerful integration'" ? Perhaps I'm missing something.

          • a) It is not nice to simply accuse someone of trolling.

            b) Looks like I am wrong, please teach me how I can publish a Web Dynpro application to IIS (not as a reverse proxy).

            The time you save when having the web server running on the same instance as your business logic is minimal and is often lost between HTTP server and client.

            Examples? Besides that SAP thought they have to not only focus on the business logic but on the frontend UI too? Leading to UI / UX problems, forcing customers to adjust their UX strategy to include a SAP exception? Making an SAP system isolated in the landscape?

            As soon as SAP started to abandon this concept by opening up the UI access with Gateway and SAP UI5, look what's happening.

          • /
          • What has me answer to your statement that "Eclipse sucks" to do with ITS? Eclipse is an open source project and by its nature depends on a collaborative attitude, like reporting errors. It's OK to use OSS without contributing, but talking bad about it at the same time is not OK.

            Now, please stay on topic and explain to me what is so good that SAP focuses on it's own web server?

  • Very good points John.

    SAPUI5 is a young framework and I'm expecting that SAP now, after the confirmation that this is the next generation UI technology for new developments, will focus on performances.

    Minification of CSS and JS is a must, that have to be accomplished ASAP in order to have a quick advantage in payload size.

    Making SAPUI5 open source will help this process of consolidation and performance improvements getting the support of a large community of JS Ninja...



  • Hi John,

    good to see you are putting lots of thought into this important topic. Basically I completely agree. And I can confirm the topic is very much on the radar inside UI5 development as well.

    So what has already been in place for quite a while is minification of files (may not matter so much with gzip) and the combination of all control files within a library into one single file where control by control is parsed on demand (the code is stored as strings to save JS parsing time).

    But still for each library there are other files (CSS, theme parameters,...) so when several control libs are used, the number of requests will increase.
    More importantly, proper applications are not in a <script> block in index.html, but are modularized on their own, e.g. using the MVC paradigm - which adds requests for View and Controller files. And of course apps want to access backend data. Probably most of the requests you have counted are in the app domain.

    And this is indeed an area which is looked at right now. There is now an approach, targeted first at the new Wave of Fiori apps, to combine as much as possible into one request. Including application Views, Controllers etc. And this not only covers JS, but also CSS.
    This is starting from the internal build process (which is SAP-specific and Maven-based, so it is not documented at the moment) but eventually also to be used externally.
    As a result there should then be very few request, few enough that not the number of requests, but their size is the performance-limiting factor.

    Coming to the size... code that is needed cannot be easily shrunk beyond what minification does. Sure, SAPUI5 in total has lots of code, it is no microframework. But it also includes much more functionality, controls etc. than most other UI libraries.
    Now if you don't need all this functionality, UI5 may not be the best choice for a certain project. If you need it and still use other libraries, you may end up throwing a couple of them together, with the danger of parts not fitting to each other.

    Still, UI5 (even the core, loaded in sap-ui-core.js!) is not constructed as a monolithic block, but very modular, and if you don't need all functionality, it is technically possible to omit those parts. To be honest, I'm not sure whether this removal of unused parts of the UI5 core happens in the build step mentioned above, but there are prototypes for building a custom UI5 core which only has exactly what you need.
    Features which are there tend to be used, though, so I'm not sure how much the UI5 core of a typical application could be stripped down. Sure it needs data binding, translation etc. So this is currently not the most promising way for size reduction.

    And admittedly it's not like you can eliminate EVERY possible feature from the code when you don't need it: controls have right-to-left support, controls offer accessibility (screenreaders, keyboard usage), most controls can be used with touch and mouse interaction; this is code spread all over the controls and you cannot choose to remove one of these features because you do not want to make use of it. So other libraries not supporting all of these features for sure have an opportunity to be smaller.

    Another way to reduce size is to load stuff lazily, on demand. But wait, this is where we are coming from: too many requests! 🙂  There's always the tradeoff between size and number of requests...
    Yeah, there is in fact also a prototype with a minimal 1k bootstrap, loading all modules lazily. Extremely slow. 🙂

    So returning from size specifics to optimized builds in general... you mentioned caching helps a lot. Right, that's the point of caching - but with optimized builds e.g. for each app you virtually disable caching across applications: the optimized set of files (toolkit plus app) for one app will never be the same as for another app, so even the toolkit will be redundantly loaded.
    So obviously the toolkit should be in a separate file from the application to at least be able to use the cache for the toolkit file.
    But still there is the trade-off: optimizing for ONE app vs. optimizing for a number of apps using the same toolkit. Even if one app doesn't use OData, it might be wise to load the toolkit WITH OData support from the same URL where all other apps also load the toolkit, so the toolkit JS file can be cached across apps.
    This is really an argument not to try to strip down the UI5 core as it may be the most likely shared resource between apps. Following this argument, UI5 is likely to be bigger than most libraries and we have to live with that...

    A heavily optimized page like the login screen of facebook will always be much smaller than any app built using a generic toolkit. But certainly the toolkit should still try to be good enough.
    Not sure what good enough is, though... often people demand sub-second for all kind of things. Yes, I as a user completely agree. But is this realistic? Even when I open the "Settings" screen on my Galaxy S2 it takes between 4 and 5 seconds, so does an HTML app on the same device have to load its resources and start within one second? As a user I wish, technically it is hard.

    You mentioned "Kapsel"/Phonegap as hybrid app solution for the issue (and Njål confirmed the effectiveness of this approach)... I think it is an important choice to greatly reduce startup delay. Resources can there also be loaded in a more granular way, reducing load on the JS parser.

    By the way: you mentioned Web Dynpro being four times smaller in terms of initial download. One reason for this is that Web Dynpro actually is a mature framework which has received several rounds of performance optimizations, so all conceptual differences put aside, it actually is good and fast.

    But in general, this comparison is a bit unfair, as in UI5 there is a lot of (toolkit AND app) logic happening in the client. So while Web Dynpro needs a server roundtrip for everything, even for a simple checkbox click that hides an area, this does not need a roundtrip in UI5 and the in-app experience is likely faster.

    And Web Dynpro also transfers only the rendered HTML (and the lightspeed rendering core), not the control logic: the control "behavior" is loaded on demand, causing additional delays later until a displayed control actually reacts. E.g. when a toolbar button is hovered, the files "Toolbar.js" and "Button.js" are loaded and before they are loaded, the Button will not work properly. When hovering a Table cell for the first time it is even five files. A clever approach, no question, but probably not well-suited for the mobile world (no hover, possibly long delays).

    Now this was a lot of text, but the performance topic is not one to easily cover in few sentences. Hopefully it gives a rough picture of what the current thinking is - and a confirmation that this topic is totally on the list.


    • Hi Andreas,

      After all the blogs I've written on SCN, this is probably the most thorough and honest response I've had from the 'inside'.  And it gives me comfort that the best intellectual minds at SAP (which far surpass my own) are working on the problem.

      In relation to the SAPUI5 with Web Dynpro ABAP comparison, I acknowledge that it can be unfair.  This did cross my mind when I wrote the blog.  The architectural lines are very different (eg. where the MVC lines are drawn).  SAPUI5 conforms more to the concept of a 'single page web app' etc etc.  But I then thought about it from an end user perspective.  They don't care about these things.  All they care about is if when launching a function how long it takes for the screen to appear before they can do their work.  And from that simplistic perspective I felt a comparison could be made.

      What I do sense in your response is that SAP is thinking hard about how to optimise this.  Knowing you are familiar with Star Trek, I'll simply quote the immortal words of Captain Jean-Luc Picard ...

      "Make it so" 😉



    • Great reply Andreas,

      As you say it's not necessarily the amount of data which kills performance, but the number of requests and their latency.

      A lot of SAP companies are global and often have one common data centre for their SAP environment. There will be a significant latency for each request and this latency increases as distance from the server grows (expect at least 30-150 ms).

      Mobile complicates the situation even more, with uncertainty in the startup time of the radio and 2g/3g/4g connection times.

      I believe a lot of people underestimate the effect mobile response time and snappiness has on user adoption of app. 1000 ms is often quoted as the target response time of a full page and the video below from Google at SFHTML5 shows some of the challenges on reaching this (well worth watching)

      [embed width="425" height="350"][/embed]

      In order to reach the 1000 ms goal, it is quite clear that the best strategy is to base the solution on one request pr user action.

      With the current versionof Fiori, this very difficult to reach so it's good to hear that action is being taken on the sapui5 side.

      I'm not to concerned about the actual sapui5 libraries,images and files as I would always expect them to be package with the app. However, the fact that the views and controllers are loaded in individual request is a much larger problem.

      When advising Neptune and Njål Stabell on implementing SAPUI5 support we had some good discussions on this topic. We ended up on having a single one page app where the sapui5 code for all screens are present. This meant we could deliver the whole app in one request initially. Then almost all events afterwards will be done through the communication of models between client and server (automatically grouped together and synched with gzip). We could do this since there is a modelling tool on top which takes care of the app structure and ensure easy maintainability.

      IMHO Fiori needs to have the same "request" footprint as the Neptune SAPUI5 solution in order to deliver a great solution for global customers.

      • Thanks Dagfinn,

        We surely needed your expertise implementing our SAPUI5 version of Neptune (Dagfinn Parnas did an amazing job with our SAPUI5 implementation). The reason why it was successful was that the end result was more based on actual end-user experience and less bothered by architectural theoretic's.

        Our partners are today creating fantastic applications with SAPUI5 framework (yes they wrap the heavy initial load of js with Phonegap). And customers are really happy... so SAPUI5 rocks.. just ask Roel van den Berge 😉

        Make it open source 😆

      • Hi Dagfinn,

        Thanks for your comments.

        Dagfinn Parnas wrote:

        A lot of SAP companies are global and often have one common data centre for their SAP environment. There will be a significant latency for each request and this latency increases as distance from the server grows (expect at least 30-150 ms).


        Yep.  A (mining industry) customer with which I am working right now has major operations in Asia and Africa.  Latency to the Asia sites can be 200ms.  Latency to the Africa sites 600ms.  In fact the timing I gave for the 100s in my blog was a real timing out to that site.

        Now this comment ...

        Dagfinn Parnas wrote:

        I'm not to concerned about the actual sapui5 libraries,images and files as I would always expect them to be package with the app.


        But with wrapping, customers need to be aware of the added work to wrap and deploy the app, handle version updates pushed to devices etc.  And here you are only takling the mobile channel (remember one value proposition of Fiori is the multi-channel enablement).  This opens up the whole mobile platform play, which customers may not have realised when first taking on Fiori.  I just hope customers understand this. 

        Also, wrapping doesn't really work for desktop browsers, so that channel still needs an optimisation approach.  As Sergio Ferrari mentions, CDNs are an option.  Or WAN acceleration tools like Riverbed etc.  But all of a sudden things get more and more expensive.  Otherwise I'm wondering if HTML5 application cache is an option.

        Just my added thoughts.



        • Hi John,

          I do not agree with you here. In my experience most customers distribute their mobile SAP applications through apps. The work you mention is not much thanks to cordova/phonegap and updating can be accomplished using Afaria Cloud (1 Euro per device per month) or if that is too expensive you can easily set up an enterprise store yourself.

          Regarding the responsiveness you mention, I am a strong believer in separating Mobile and Desktop UI. Working with touch based devices compared to mouse + keyboard is not the same! Use portal or NWBC for desktop (SAPUI5 has a great desktop library).

          My thoughts 🙂

          Here is Roel van den Berge 's presentation btw


          • Hi Njål,

            Its OK if you don't agree.  If everyone agreed we wouldn't learn anything!  And also I take your opinions very seriously because I know how much real world experience you bring to the table. 

            One thing with respect to the Afaria Cloud option ... it isn't available to all countries yet.  I might not be up to date, but I had thought it wasn't available in Australia as of a few weeks ago.  If anyone from SAP believes it is now available, feel free to add that to this thread.  But as you say other options for deployment are available.

            In relation to the separation of mobile and desktop UI.  That is a valid view, and I'm not passionately for or against that view.  But what you are saying differs from what SAP is selling.  If you look at the SAP image at the top of my blog there is a whopping big desktop there with Fiori on it.  So customers need to really understand the value proposition ... are they really going to bother to use it on desktops or not?  Or only as a mobile channel and in doing so taking a mobile app deployment approach?  I just hope customers are considering all of this.

            Thanks again for adding your thoughts.



          • Hi John,

            Yes it is important to have a discussion. As I told your wife and son in Las Vegas your early blogs on JQM, Phonegap and ICF was a very important spark for our company, so I value your great blogs and insight highly. I think we all want the same thing - a performing great UI for our SAP customers. I met Andreas Kunz at TechEd Amsterdam and that person gives me faith and hopefully SAP strives for the same goal.

    • "custom UI5 core which only has exactly what you need." - Yes please!  Many UI frameworks/utility have tools to do this.

      "But it also includes much more functionality, controls etc. than most other UI libraries" - I think a more accurate comment would be SAPUI5 has all the widgets and control you would expect from a modern JS UI framework nothing new or out of the ordinary. 

      • Hi Kenton,

        just to make sure we are talking about the same thing:

        • There are more than 200 controls (the more exotic libraries like the charts not counted), most of them running on desktop as well as mobile platforms and all of them with support for enterprise standards like screenreaders, keyboard navigation, translation etc.
        • Data access is integrated in a way that allows displaying a Table with paging, sorting, filtering (all executed on the backend) with 5 lines of code.
        • Mock services and unit test framework (qunit) are included.
        • Theming based on LESS with runtime access to theme parameters as well as a WYSIWYG theme designer tool.
        • Integrated supportability tools allow inspecting and modifying the UI structure at runtime, switching between optimized and debug code, easily setting breakpoints in any method of control instances (not the class, like the browser's debugger would) etc.
        • Views along the MVC paradigm can be defined as either JS, XML, or HTML (including mustache templates).

        Agreed, one might expect this range of controls and functionality from a modern JS UI framework. But I'm not sure how large the number of those meeting this expectation would be.

        Putting all these features on the table does not mean to say that UI5 is supposed to be superior to those other frameworks which lack one or the other feature.

        In contrary, others will be better suited for certain use-cases that match their profile. We were just discussing the performance and size and possible ways to optimize it, and there it is important to understand how this size comes together and what the options could be to strip it down if certain features are not needed.



    • Hi Andreas,

      So what has already been in place for quite a while is minification of files (may not matter so much with gzip)

      I don't think this point is actually true, the combination of the two can at least possibly contribute to better performance so better to do both.  A simple example  on stack overflow ( .  I wouldn't want this to be ignored in future sapui5 releases just because gzip exists.

      There are a lot of measures of performance, and time to responsiveness or time to render the first page is important.  If we could get that first page to render and at least have some "loading.." it would be better than a blank page so that is really something to keep in mind over number of requests and is similar to the optimization of keeping all the css to render everything above the fold separate from other css.

      In the bundling and minification, mvc4 has given the power to the developers in which scripts are bundled/minified but I'm sure something similar could be done with grunt. Which leads me to wonder if a reference gruntfile could somehow be integrated into the build of SAPUI5 customer apps so that we don't have to roll our own solution for this and then could have a different build on dev/prod when debugging. Then something like bower could be used to manage dependencies on sapui5 and other submodules.  SAP doesn't need to fully guess what types of apps will be used by the customer if the power is given to the customer to package.

      In many ways I would really have liked to see SAP building upon even more libraries and open source tools and adding on them to work with the rest of the SAP suite (yeoman for sapui5/hana?).

      Anyways I hope that sapui5 gets there and that it's not afraid to use and build upon even more of the amazing tools available in the open source space.  No reason that node.js couldn't live happily beside hana xs, even if node is only on the developer machine.


  • Hi John, thanks for the insight. Without joining the technology bits and pieces on HTML5 (which also far surpass my own) i would like to share some of my other observations in this area.

    Before SAP several other companies tried to follow the "Mobile HTML5 approach" For example Facebook tried to build a full HTML5 client. After some time they decide to go back to native (insight here) Of course this also has to do with the great number of end users but is the SAP range of self services Salesforce tried the same with their introduction of Salesforce Touch in 2011 (details here) During last weeks Dreamforce event they had to admit that this was a wrong approach (details) and now when back to a native salesforce1 app approach (details).

    Reading all the stuff above we put quite some faith in German engineering to overcome all the obstacles. We rely more on german BMW's instead of italian Ferrari 😉

    But seriously i believe SAP made a pretty bold statement on Teched with the harmonisation on Fiori. Especially with their current track record in this area. Customers embrace the concept and are al least very interested to find out more. But SAP has to deliver on the promise fast and the technology they chooses does not yet seem to be a proven one.......

    Cheers, Pim

  • Good one John.

    Due to my surname and location, I like to add a couple of comments.

    That said that I'm completely with you I hope to see SAP adopting a couple of technologies:

    • SPDY to dramatically lower HTTP requests (
    • CDN ( ) . I do not like to see my dear ABAP WebAS distributing basically static content like the SAPUI5 CSS and libraries and icons. With the effort SAP is putting into the Cloud, I expect a proposal for a kind of CDN for its stuff (e.g. each version of SAPUI5 static content available both for HTTP and HTTPS connections)


  • Great article John - to me this is a timely reminder to SAP that they have to keep an eye on the landscape around them.  I've seen a lot of product in the last 5 years where SAP has done a fantastic job on what they set out to achieve - but they have been let down by not addressing the focus areas (another example from me would be WCEM being launched without any SEO capability).  Having said that, however,  I can't wait to see what happens if the focus on this area continues!


  • Great Blog!!!

    Good research. Nothing like providing facts. Nice.

    One question I have is about overall speed. The initial app load is much greater in UI5 (yes it could be leaner, agreed), but the goal is to transfer a lot of the UI manipulation to the client. In other words, I would expect a heavier initial load, but then after I would expect faster interaction (in comparison to an equivalent webdynpro).

    Have you done tests on that? Anything to share? Is my expectation correct?



    Load Order creation APP = 10 seconds

    Create a PO (in 5 steps) = (sum of all steps = 5 seconds, including save)

    Webdynpro (if we could find a similar application that requires a similar number of steps)

    Load Order creation APP = 5 seconds

    Create a PO (in 5 steps) = (sum of all steps = 15 seconds, including save)


    • Hi Leo,

      Yes I did do rudimentary tests for the follow-on performance for both the UI5 and Web Dynpro leave request when you subsequently work to submit a transaction.  I didn't document all the results (I do have some), and right now don't have the time to collect it again.  What I DID find was that both performed reasonably well once the initial load of web resources occurs.  Although from reading the thread it seems the Neptune folks have optimised the UI5 interaction further in their custom solutions.  Also Andreas indicates some shortfalls in the Web Dynpro interactions compared with UI5, but from an end user perspective they were not nearly as obvious as the initial load time.  Basically, the performance lag did not scream out to me in either case, as much as the original time to load the UI5 app did (and in your example above, 10 seconds for the UI5 app is optimistic, unless of course you are using a wrapped app in PhoneGap/Cordova).  So in this blog I focussed soley on that.



  • HI John,

    Starting a POC in our sandpit next week on Fiori employee apps. 3 standard & 2 custom.

    Custom are HR-PS leave booking to update I0573 and a recruitment job search.

    Will keep a close eye on performance.


  • Kind of late to this blog, but from my experience with SAPUI5 apps this is still a problem. Even a very simple split view app takes several seconds to load on a mobile device, and the user has to look at a blank screen with no indication of what is happening.

    SAPUI5 is great, the UI is beautiful but I hope SAP continues to look into how to solve this very real problem with framework.

      • Hi Robin,

        Interestingly enough, running that code in Australia takes over 3.5 seconds before the splash page is displayed because of the time it takes to just load sap-ui-core.js!  On Cordova, or locally deployed UI5 libraries this isn't an issue, but would be good if someone altered the JSBIN code to allow the sap-ui-core file to be part of the post display splash page content...I'm too JS green to attempt to interpret how to change that initialisation SAPUI5 script in a way that could still work, though I'm sure it's easy for JS experts.