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');
oInput1.setValue("Hello!");
oInput1.attachLiveChange(function(event){
// console.log('Text changed to :'+ oInput1.getValue());
for( var i = 0; i < that._NUMBER; i++){
that._textAreas[i].setValue(event.getParameter("liveValue"));
}
}
);
this.oLayout = new sap.ui.layout.VerticalLayout("Layout1", {
content:[oInput1]
});
for( var i = 0; i < this._NUMBER; i++){
var oInput = new sap.ui.commons.TextArea('text' + i);
this.oLayout.addContent(oInput);
this._textAreas.push(oInput);
}
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:
- React in wikipedia
- React source code in Github
- React vs AngularJS vs KnockoutJS: a Performance Comparison
- JSX
- Google document: How to measure performance via timeline tool
- How browsers work-Behind the scenes of modern web browsers
- What does Long Frame mean
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.
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.
-Kimmo
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:
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.
Regards
Andreas
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,
Jerry