Comparative Web Performance evaluation of Vue & React using JSWFB
Table of Contents
DOM & Virtual DOM
This paper provides an insight into these frameworks. Each one of them will be investigated and evaluated based on pre-deﬁned criteria: DOM Manipulation, Startup Time & Memory Allocation.
DOM & Virtual DOM
The Document Object Model (DOM) is an interface that treats an HTML document as a tree structure where each node is an object representing a part of the document. The DOM represents a document like a logical tree of nodes.
Searching and updating the DOM is a huge bottleneck in web application performance because the DOM tree can have thousands of nodes in modern applications. This is the reason Virtual DOM is created.
Both React and Vue use virtual DOM to archive a higher performance.
React is according to the Stack Overflow Developer Survey 20201 the most commonly used (41,3%) and most wanted & desired (25%) Web Framework by all developers.  React is loved for its
Evan You created Vue mainly for UI design and development, where its main purpose lies in handling the view of the software. Vue can be easily integrated into any JS project for UI development while using other JS frameworks for developing complex Frontend operations. Vue allows working with animation, unlike React and it uses Vuex for managing states.  One needs to install lots of additional libraries, for Vue to be on the same level of functionality depth as React.
In Stack Overflow Developer Survey 2021, the most commonly cited positive aspects of Vue were that it is easy to learn, lightweight, has a nice programming style, documentation, and fast performance. 
This section deﬁnes the methodology & criteria that are going to be measured.
JS Web Frameworks Benchmark
|Specs:||2 GHz Quad-Core Intel Core i5||Intel Iris Plus Graphics 1536 MB||16 GB 3733 MHz LPDDR4X||macOS Big Sur|
The following operations are benchmarked for each framework:
create rows: Duration for creating 1,000 rows after the page loaded (no warmup).
replace all rows: Duration for replacing all 1,000 rows of the table (with 5 warmup iterations).
partial update: Time to update the text of every 10th row for a table with 10,000 rows (with 5 warmup iterations).
select row: Duration to highlight a row in response to a click on the row. (with 5 warmup iterations).
swap rows: Time to swap 2 rows on a table with 1,000 rows. (with 5 warmup iterations).
remove row: Duration to remove a row for a table with 1,000 rows. (with 5 warmup iterations).
create many rows: Duration to create 10,000 rows (no warmup)
append rows to large table: Duration for adding 1,000 rows on a table of 10,000 rows (no warmup).
clear rows: Duration to clear the table filled with 10,000 rows. (no warmup)
ready memory: Memory usage after page load.
run memory: Memory usage after adding 1,000 rows.
update memory: Memory usage after clicking 5 times update for a table with 1,000 rows.
replace memory: Memory usage after clicking 5 times create 1,000 rows.
repeated clear memory: Memory usage after creating and clearing 1,000 rows for 5 times.
update memory: Memory usage after clicking 5 times update for a table with 1,000 rows.
consistently interactive: The lighthouse metric TimeToConsistentlyInteractive: A pessimistic TTI – when the CPU and network are both definitely very idle. (no more CPU tasks over 50ms)
script bootup time: The lighthouse metric ScriptBootUpTtime: The total ms required to parse/compile/evaluate all the page’s scripts
main thread work cost: The lighthouse metric MainThreadWorkCost: Total amount of time spent doing work on the main thread. includes style/layout/etc.
total byte weight: The lighthouse metric TotalByteWeight: Network transfer cost (post-compression) of all the resources loaded into the page.
For all benchmarks, the duration is measured including rendering time.
For the benchmark to work the computer needs to have these installed: npm, node >10.16.3 and for some frameworks java > v8.
The benchmark will mainly be created using Terminal and Visual Studio Code. The terminal will be used to create the webserver and run the benchmark. Visual Studio Code will be used to optimize and enhance the test. After the benchmark has been downloaded/forked and entered in the folder using Terminal, the first step is to install global dependencies to be able to create a web server and start it. This command has to be executed in the root directory:
There is going to be a list of all the possible frontend benchmarks on http://localhost:8080/index.html.
To build and view a single framework one can navigate using terminal command into the framework folder:
The Test environment consists of 6 Buttons. Create 1000/10000 Rows, Append 1000 Rows, Update every 10th Row, Clear and Swap Rows.
After optimising the .vue & .jsx files and testing that the framework work, the benchmark can be operated. The benchmark driver for JSWFB works completely automated. The driver uses the chromedriver to measure the duration for each operation using chrome’s timeline. The steps to run this operation looks as follows:
The benchmark will iterate through all the cases to get a definitive answer and post the results on http://localhost:8080/webdriver-ts/table.html. The results can be submitted to the official results page to further the accuracy.
Test application code structure
To test how long the frameworks take time to create, update and remove data in the DOM, there needs to be a way to a large data collection. This was easily accomplished by creating a function that iterates over three arrays with each having different size arrays. The function would then randomly create a string out of three random pairs out of the aforementioned array. By letting this function run 1000 times.
As expected the react test application is written in a .jsx file whereas the vue test application was written in a .vue file.
Duration in milliseconds ± 95% confidence interval (Slowdown = Duration / Fastest)
The purpose of this test was to measure the time it took for the framework to create, update and remove data in the DOM. The DOM manipulation test was performed by creating an array of a given size and ﬁlling it with a randomly generated array of three strings out of another array. After the array was ﬁlled there was a switch that activate the rendering to the DOM by iterating through the array. This operation was done for a while. Once the rows were created the updating & clearing of the rows began. After that, the next test was to change the value of every element in the array and ﬁnally the last test was to remove the entire array. This is done by appending another 1000 rows, updating every 10th row, or swapping rows. The last test is to clear rows. These operations happen in a matter of Milliseconds in the Browser.
Startup Time (lighthouse with mobile simulation)
Startup time means the time it takes from entering a page until it was completely loaded and ready to use.
Memory Allocation in MBs ± 95% confidence interval
The purpose of this test was to measure the time it took for the framework to move data from one array to another. The memory allocation test was performed by creating an array ﬁlled with data and by pressing a button to copy the array into a new array.
This section will present the data gathered for each framework. By performing the collection of tests, an adequate amount of data was gathered, which is analyzed in this section. The frameworks received points based on how well they performed for each criterion. These points were to form the basis upon which the analysis got performed and provide the answer to the research question.
The purpose of this test was to measure the time it took for the framework to create, update and remove data in the DOM. The DOM manipulation test was performed by creating an array of a given size and ﬁlling it with a randomly generated array of three strings out of another array. The study was performed using two diﬀerent array sizes, 10000, and 1000. This was done to observe if either of the frameworks would perform better or worse for diﬀerent sizes of operations.
Vue & React performed at similar speeds for creating elements that get rendered to the DOM. Vue marginally edged out React overall but to such a small extent that it might as well have been due to inconsistencies in the tests. Both frameworks are therefore considered equal when rendering elements to the DOM.
For changing elements in the DOM the result of the diﬀerent frameworks varies quite signiﬁcantly in speed, Vue was the best while React was worse at changing the DOM.
For removing elements from the DOM, Vue got a slightly better score than React. The diﬀerence between React and Vue on average was very marginal and was therefore considered equal in removing elements from the DOM.
With all the tests ﬁnished, it was time to determine the ﬁnal score. This was done by taking the percentage diﬀerence between the frameworks. This was done for all the sub-test results 10000 and 1000 rows for each of the three diﬀerent measurements create, change and remove. By converting these percentages into actual scores by following the acceptance range we could get how much that a given framework had scored better or worse than the other framework. Based on these scores, the ﬁnal score got determined by taking the average. This was the process used for the other performance evaluations.
Startup Metrics (lighthouse with mobile simulation)
The startup time test was divided into three different tests, one for the consistently interactive, one for the script bootup time and one for the total kilobyte weight. React and Vue had a similar startup time on consistently interactive and script bootup time, but Vue was faster in total kilobyte weight.
Memory allocation in MBs ± 95% confidence interval
The memory allocation test was studied by moving elements from one array to another. this study was, like the DOM test performed on the array sizes 10000 and 1000 to observe if they performed diﬀerently with various sizes of operations.
The memory allocation test showed quite similar speeds, Vue was a little faster on large and slow arrays. The memory allocation speed was very similar for React and Vue but there is a winner. Vue was much faster on larger arrays than React.
Even though it was not easy to compare two of the fastest web frameworks, one is faster, Vue. Vue is the winner in all three Performance tests. The only point where React is faster is at selecting rows. React took 26ms less than Vue highlighting a selected row.
In general, Vue’s geometrical mean of all factors of 1,02 at DOM Manipulation, 1,00 at Startup Time and Memory Allocation is outstanding. Vue is therefore 36% faster at DOM manipulation than React. Furthermore, Vue was faster by 19% at startup time and 21% better at memory allocation.
There is no clearer way to display how better Vue is at creating high performative web applications than React.
 „Stack Overflow Developer Survey 2021“, Stack Overflow. https://insights.stackoverflow.com/survey/2021/ (zugegriffen 16. Januar 2022).
 „Introducing JSX – React“. https://reactjs.org/docs/introducing-jsx.html (zugegriffen 18. Januar 2022).
 F. Adamakis, „Vue Virtual Dom“, Vue.js Developers, 20. Mai 2020. https://medium.com/js-dojo/vue-virtual-dom-13af62d2be41 (zugegriffen 18. Januar 2022).
 „Virtual DOM and Internals – React“. https://reactjs.org/docs/faq-internals.html (zugegriffen 18. Januar 2022).
 „DOM Elements – React“. https://reactjs.org/docs/dom-elements.html (zugegriffen 18. Januar 2022).
 „Vue.js“. https://vuejs.org/ (zugegriffen 18. Januar 2022).
 S. Krause, js-framework-benchmark. 2022. Zugegriffen: 17. Januar 2022. [Online]. Verfügbar unter: https://github.com/krausest/js-framework-benchmark