Skip to Content
Author's profile photo Jerry Wang

Use Chrome development Tool to compare Rendering performance between SAPUI5 and React

I have been working as a Fiori application developer and nowadays I have read quite a lot of blogs which introduce how to build web application using React.  React is an open-source JavaScript library providing a view for data rendered as HTML. You can find more information from Wikipedia and its source code from github.

Most of those blogs have mentioned that React has quite good performance but don’t contain detail performance data. Since I have been using SAP UI5 framework in my daily work, I am curious about the performance comparison between SAPUI5 and React regarding the topic of page rendering.

Comparison environment setup

I have implemented a most simple application separately via UI5 and React to measure their page rendering performance difference.

The application has the following appearance: it consists of a TextField with a given numbers of TextArea. The number of TextArea is controlled via code. Every time you type something in the TextField, the text you have typed will be written in all of the TextField as well.


The UI5 implementation

I use Json view to implement this application. The source code of “sample.view.js” has been listed below. The variable “_NUMBER” controls the number of TextAreas.

sap.ui.jsview("compareReact.sample", {
_NUMBER: 100,
_textAreas: [],
getControllerName : function() {
  return "compareReact.sample";
createContent : function(oController) {
  var that = this;
  var oInput1 = new sap.ui.commons.TextField('input1');
   // console.log('Text changed to :'+ oInput1.getValue());
   for( var i = 0; i < that._NUMBER; i++){
  this.oLayout = new sap.ui.layout.VerticalLayout("Layout1", {
  for( var i = 0; i < this._NUMBER; i++){
   var oInput = new sap.ui.commons.TextArea('text' + i);
  return this.oLayout;

The React implementation

The source code could be found from my github.

For those who are not familiar with React, let me briefly introduce this source code:

When I studied React for the first time, I was confused by the “syntax error” for example in line 28 and 32~36. Actually this is the supported syntax on script tag with type “text/babel” ( in line 10 ). Using this JSX grammar, it is allowed to insert native HTML markup into JavaScript code.


And keep in mind, such JSX code will be translated to native JavaScript when the page is rendered, by browser.min.js. For steps how to get and debug converted JavaScript source code, please refer to my blog How to get and debug converted source code in React.

In line 12, a customized ReactComponent is created which encapsulates the logic how the view should be rendered and what is the data source of this view. For me, I would like to treat the function render() as createContent() in SAPUI5 Json view, and setState() as the ClientModel handling in SAPUI5. You see the line 33 “value={value}” and shouldn’t this be the same logic as SAPUI5 data binding? 🙂

When there is live-change event occurred, the callback function “this.handleChange” specified in line 33 will be called, which will then trigger ReactComponent.setState and finally render() will be called to refresh the page.

The created ReactComponent could be used the same way as native HTML tag to insert into the page.


The code above has exactly the same logic as what we do in every UI5 application:


Use Chrome timeline to measure performance

I will use the tab “TimeLine” to measure performance. There is already a good article introducing how to use this tab by Google.

UI5 application result

I start comparison by specifying the number of TextArea as 100. First start UI5 application. I type “3” for six times and I get the following measurement result:

1. The six areas marked with black bold underline represent the performance data for each of the six “3” type action. As I only focus on rendering stuff, I can ignore the orange color for “Scripting”. So the total rendering time for scenario with 100 TextArea are 36.3ms and Painting time is 6.9ms.


You might be confused by the terms “layouting”, “rendering” and “painting”? Read this awesome blog How browsers work-Behind the scenes of modern web browsers to understand their exactly meaning.

And have you noticed the small red icon for “Long frame”?


You can click the hyperlink “jank” to know more detail about “Long frame“.

By clicking the corresponding rectangle with different color, you can get a detail view under tab “Event Log”.


For example, below detail view shows that the code in line 416 of TextField.js:formatted has triggered the style recalculation which consumes 1.8ms.


Click the hyperlink and we are eable to see the exact line with its context. In this case, we first get the native HTML DOM node in line 399 and fill its attribute value in line 416 with the character we have typed.


And how is this 36 FPS ( frame per second ) calculated? 36 FPS = 1 / 27.7ms * 1000, means 36 frames per second.


According to Google documentation, “Each of those frames has a budget of just over 16 ms (1 second / 60 = 16.66 ms). In reality, however, the browser has housekeeping work to do, so all of your work needs to be completed inside 10 ms. When you fail to meet this budget the frame rate drops, and the content judders on screen. This is often referred to as jank, and it negatively impacts the user’s experience.“, this is the reason why this frame with duration 27.7 ms is marked with red indicator for “Long frame”.

React application result

We can easily find that there is no Long frame for the six frames rendered in React, total rendering time is 19.5 ms ( while UI5 is 36.3 ms  ) and painting time 5.4 ms ( UI5 6.9 ms ).


React has much better performance than UI5 ( 63 FPS vs 36 FPS ).


Actually there is no apparent difference between UI5 and React on Layouting; The bottleneck for UI5 lays in the T.setValue which consumes the 46.2% of total time.


In React, the code to change the native HTML node value, setTextContent in react.js:16904, only consumes 0.6ms.


The pixel pipeline

As documented by Google, “Most devices today refresh their screens 60 times a second. If there’s an animation or transition running, or the user is scrolling the pages, the browser needs to match the device’s refresh rate and put up 1 new picture, or frame, for each of those screen refreshes.  Each of those frames has a budget of just over 16 ms (1 second / 60 = 16.66 ms). In reality, however, the browser has housekeeping work to do, so all of your work needs to be completed inside 10 ms.

That is to say, for any frame, it is better to avoid the total duration of the five mentioned steps ( 1. JavaScript 2. Style calculation 3. Layout 4. Paint 5. Composite ) not exceed 10 ms.


Further reading

For your convenience, I list all the document which I think worth further reading into this part:

I am also considering to rewrite the UI5 sample with model binding ( bind the value of both TextField and TextArea to a Json model field ) and then re-compare the rendering performance difference.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Kimmo Jokinen
      Kimmo Jokinen

      Thanks Jerry for sharing your findings. Seems that there's still some work to do in optimizing UI5. Maybe it could be related to accessing the DOM using jQuery which is sometimes a lot slower than using native Javascript.

      Performance is one of the most important things for OpenUI5, or really any Javascript library, to focus on to gain more foothold. And then Javascript and pixel pipeline rendering if only one part of the performance. Another thing is the size of the assets that need be loaded, which need to be small enough to make it possible to attain those sweet 2 seconds of first page rendering when opening up a web site.


      Author's profile photo Andreas Kunz
      Andreas Kunz

      Hi Jerry,

      first of all thanks for the detailed explanation how the Chrome developer tools can be used to analyze performance!

      However, while I agree that further performance work is needed in UI5 (and it is being done as we speak), I'm sure you'll also agree that this article is very much comparing apples to oranges.

      To explain what I mean, a couple of questions about the React implementation:

      • Does it have any CSS applied, any theme? (you know that a visual theme is needed for nice apps and that browsers need time to apply the CSS) Is this theme prepared to be customizable, but still stable and keeping the customer changes across CSS updates?
      • Does a screenreader correctly announce the UI elements for blind people? Or would you have to extend the HTML with some ARIA annotations, which would of course make rendering take a bit more time?
      • Would the handcrafted HTML like in your React implementation support massive parallel development of hundreds of apps that look very consistent? And would a design and structure change (like the one for Fiori 2.0) after a year be possible to be done centrally or would all the apps have to be adapted? Or would you rather have to create a sort of re-use library on top of React that would of course eat some performance?
      • If a customer wants to extend the list via customizing, would he be able to do so without modifying the application code and without loosing his extensions when the application is updated?
      • Is the React implementation automatically translatable, localizable, and working well in right-to-left mode for people in countries that write that way?
      • Does it support validation of entered data out of the box? Would the border around the input turn red and display a warning when the entered data is invalid or would something need to be added to achieve this?

      Of course I could continue this list for a long time, but I think it's sufficient to make the following point: comparing hand-crafted HTML to re-use components in a comprehensive library will always end up with the latter being slower (be it significantly or just slightly).

      And of course everyone wants good performance and it is important. But it is not an option in real-life business applications to ignore all the other requirements like internationalization, accessibility, security, theming, extensibility, maintainability, developer productivity and more.

      Of course all these things happen mostly under the hood and cannot be seen by taking a glance at the UI. But that's exactly what makes comparing an existing framework to a extremely limited prototype so dangerous: one risks to forget about those invisible things that take 90% of the implementation time and of course also eat some performance, but are still extremely important.



      Author's profile photo Jerry Wang
      Jerry Wang
      Blog Post Author

      Hello Andreas,

      First of all, as always, it is good to have comment from UI5 experts as you 🙂

      The original purpose of this blog is that I would like to share with those SCNers who haven't been familiar with Chrome timeline tool before. As the details steps have already been introduced in Google documentation, I would like to find some real example. While I am using UI5 to build web application in my daily work, as said by Mark Twain, “To a man with a hammer, everything looks like a nail.", so in order to avoid this, I would like to study some other UI framework in my spare time and curious about the difference between SAPUI5 and those other open source frameworks.

      I fully agree with you: performance is only one aspect which influences our decison on which framework should be chosen, especially when we need to build Enterprise web application. My personal feeling about using SAPUI5 to build SAP CRM Fiori application is that thanks to this great framework, most of the product standard stuff as you mentioned have already been covered by framework itself, then we application developer can concentrate ourselves to implement business logic.

      Back to the two samples used in this blog, I admitted that it might be "unfair" to compare them: For UI5 one, as I am using TextField and TextArea, many product-standard related features have been encapsulated within the control implementation themselves. However for React one, per my very limited knowledge on React as a beginner, they have to be implemented by application development themselves. For example, I am very curious how Facebook has achieved accessibility on their applications built on top of React.

      In my opinion it does not make sense to say "framework A is better than B" or "framework A has better performance than B" without concrete context or use case. This is the reason why I personally didn't agree with some opinions in these two articles:

      Best regards,