Research on performance in modern client-side web-frameworks.

Ratushniak Evgenii Alekseevich ORCID: 0009-0006-3609-4194 Student; Faculty of Software Engineering and Computer Technology; ITMO National Research University 197101, Russia, St. Petersburg, Petrogradsky district, Kronverksky ave., 49 evgrat123@mail.ru

Introduction

The rapid development of web technologies is transforming user expectations: content should appear almost instantly, and the interface should respond without noticeable delays. Google estimates that increasing the Largest Contentful Paint (LCP) by just 100 ms leads to a 1.3% decrease in the online store's conversion rate. Consequently, the issue of choosing a framework goes beyond taste preferences and becomes a factor in the financial effectiveness of the product. Statistics show that React, Angular and Svelte form the most "lively" circle of developers and the highest satisfaction ^[2]. In scientific discourse, priority is given to frameworks with an active ecosystem – React, Angular and, more recently, Svelte. These frameworks also have different approaches to detecting changes: React – Virutal DOM ^[3], Angular – Incremental DOM ^[4], Svelte - transfers calculations from runtime to the compilation stage ^[5]. The use of frameworks and libraries significantly speeds up application development and reduces their cost by 30% ^[13], and the performance of web frameworks remains one of the important parameters ^[14]. All of the above leads to the need for a comparative analysis of frameworks, and also justifies the relevance of the work.

The purpose of the article is an empirical comparison of the rendering performance of React, Angular and Svelte in typical scenarios for building and updating a user interface. To achieve this goal, the task of developing a unified set of test scenarios, automating the collection and analysis of experimental data to identify the disadvantages and advantages of frameworks is being solved. The subject of the study is the rendering performance of three frameworks — React, Angular, and Svelte — in typical scenarios for building and updating user interfaces in web applications. The scientific novelty of the research lies in the development and application of an automated methodology for comparative performance analysis of React, Angular and Svelte frameworks in various operational scenarios of web applications, which allows us to identify their advantages and disadvantages.

Development of test software

As part of the experimental study, a single‑page client ^[8] web application is being created that visualizes a hierarchical selection of data in tabular form. An example of the implementation of a table row is shown in Figure 1. Each logical record is displayed using a uniform string template: the table row container is divided into four cells, sequentially displaying the element ID, its title and text description, as well as a set of buttons with control actions. The add and remove buttons are decorative, and programmatic methods are used to update the table data, namely– updating the internal data representation to test the performance of frameworks. The designed row, being an atomic visual module, organizes event flows, isolates rendering, and serves as a universal unit of performance measurement: fixed styles and the same composition of DOM nodes ensure comparability of metrics for build, update, and delete times for different frameworks. The experiment also has two data structures: binary – emulates real sites with high nesting, linear – emulates large tables. Such an organization of the experiment makes it possible to strictly record the latency and volume of DOM operations when scaling the number of records, which, in turn, allows an objective assessment of the effectiveness of optimization strategies used in frameworks.

Figure 1 – implementation of the test table row

In the browser model, the event loop is the only reliable way to capture the moment when the first visual frame has already been rendered, using the requestAnimationFrame sequentially and then the timer task with zero delay. Therefore, the label placed inside such a call captures the time until the frame appears, bypassing the entire critical rendering path ^[1]. If a timeout call with a delay of 0 is placed inside the animation frame request handler, a separate task is created. It will be processed in the next iteration, that is, after the browser has rendered the completed frame. Thus, the interval between the labels taken immediately after the state change and at the beginning of the timer task covers the full signal path ‑ the work of the framework, the generation of patch operations, the calculation of styles, the calculation of markup, rendering — and therefore serves as a correct measurement of the "data → first frame" time for any modern JavaScript frameworks. This is the criterion for the greatest redrawing of the LCP ^[7].

The experimental setup consists of a multicomponent architecture (shown in Figure 2), which includes a client layer on each of the three frameworks and a reference application based on "pure" JavaScript, an Express JS-based server and an automated statistics collection module. Each client application requests input data along the /testcase/next path, performs the required operation, and transmits the measured execution time back to the server via /testcase/benchmark. This cycle is repeated for all scenarios without human intervention, which ensures full reproducibility and eliminates the effects of third-party delays associated with manual browser control ^[6]. Progress counters are maintained on the server, allowing you to consistently complete the entire volume of tests; upon completion, CSV files and an adaptive HTML report are generated, where the results are compiled into summary tables with automatically calculated averages and standard deviations. The automatic browser "driver" implemented on Puppeteer starts the browser interactively, waits for the moment when the experiment completion flag is set, and, if necessary, repeats the run when exceptions occur, thereby guaranteeing stability even in case of accidental network or browser failures.

Figure 2 – architecture of the test environment

The source code of the experimental software is posted on GitHub and is available via the link https://github.com/TimeToStop/benchmark .

Implementing a test application using frameworks

The HTML markup loop uses a function that defines the unique identifier of an element; it forces the change detection engine to compare elements by the returned key, so when changing the row order, Angular reuses existing component instances and updates only the changed cells, not the entire collection. This combination reduces both the number of template recalculations and the frequency of "expensive" layout recalculation operations. The code is shown in Figure 3.

To measure performance, the initial label is set at the moment when the input property of the component is programmatically changed with an immediate change detection call, which forces detection only in the current subtree.

Figure 3 – implementation of the node component in Angular

The components shown in Figure 4 are set as pure functions, so with each update, React compares only the result of their call, and not the state of the class instances. The main optimization is shown in the key attribute when traversing descendants: the keys give the matching algorithm a stable identity of the elements, which allows you to limit the recalculation to those nodes for which the data has actually changed. Thus, when adding or deleting rows, React performs point operations instead of completely recreating the subtree. The moment when the start of rendering is fixed is the setState call, which puts the update in the queue and starts the virtual tree matching phase.

Figure 4 – implementation of the node component on React

The component is declared once, but it is deployed by the compiler into an imperative loop, which generates a minimal set of calls to insert and delete elements at the assembly stage — the virtual DOM is not involved at all ^[19]. Therefore, changing the array of descendants leads only to those manipulations with the DOM that are really needed, without intermediate calculation of changes ^[20]. Recursive use of the component preserves a single template and allows the compiler to reapply the generated code at each level of the tree, which minimizes code size and overhead during execution. The beginning of the rendering speed measurement is to call tick(): this function adds a function call that is executed when the compiler has already updated the real DOM nodes. The code is shown in Figure 5.

Figure 5 – Implementation of the node component on Svelte

Analysis of experimental data

The hardware platform includes an Intel Core i7‑8750H processor, 16 gigabytes of RAM and a 64‑bit operating system; the browser is Google Chrome version 126.0.6478.116. Frameworks are used in current stable releases: Angular 16.2.12, React 18.3.1, Svelte 4.2.18. Such a selection guarantees the relevance of conclusions for practice in 2025 and removes compatibility issues with modern browser-based The API. All measurements are performed by the performance.now() function, whose accuracy of about five hundredths of a millisecond is considered sufficient to record performance.

Primary rendering is the formation of the internal representation of components, the construction of the DOM and the execution of the first layout. In a linear structure, a test table of N thousand rows creates a uniform load across the entire width of the window; in a binary structure, on the contrary, recursive branching forms a deep tree with a large number of cross-style dependencies. Under these conditions, the reference application in pure JavaScript naturally fixes the minimum time due to the lack of abstractions, however, React and Svelte turn out to be close to it in the binary case: the difference does not exceed several percent due to the fact that React's virtual DOM and Svelte's compiled calls generate relatively compact sequences of operations, which is consistent with the conclusions of Makitalo et al. ^[10]. Angular demonstrates an increase in LCP by about sixty percent regardless of the structure, which is consistent with its heavier runtime startup and change tracking strategy ^{[9, 12]}. When switching to a linear table, Svelte shows a twenty percent drawdown compared to JavaScript, which is explained by the increase in the amount of code needed to describe each line, while React retains parity due to the optimized transformation of arrays into a set of elements. The experimental results for the primary rendering scenario are shown in Figures 6 and 7.

Figure 6 – results of testing primary rendering in a binary data structure

Figure 7 – results of testing primary rendering in a linear data structure

Re-rendering, that is, a complete redrawing of the same data structure, illustrates how frameworks manage an already built tree. Algorithms for comparing the old and new state are critically important here. In the binary hierarchy, React turns out to be the slowest: calculating changes based on a deep structure leads to a time increase of almost one and a half times relative to Angular and twice relative to Svelte.

The latter benefits from direct changes to specific nodes, since the compiler knows in advance which part of the DOM needs to be touched. In the linear table, the picture is changing: React, which uses element keys to quickly detect movements, becomes a clear leader, ahead of Angular by a third, and Svelte by fifteen percent. This behavior confirms the thesis that the efficiency of the virtual DOM increases with the proportion of identical repeating subtrees, whereas with complex nested structures, the matching costs exceed the benefits of selective updating. The results of the experiment under the scenario of repeated renedring are shown in Figures 8 and 9.

Figure 8 – Results of re-rendering testing in a binary data structure

Figure 9 – Results of testing re-rendering in a linear data structure

The element update operation simulates small changes while the application is running. Performance here is determined by a combination of the node update rate, the number of redraws called, and the severity of style synchronization. The results obtained demonstrate a clear advantage of Svelte: in a deep binary tree, the compiled code is addressed directly to the target node, changing only the affected attributes and minimizing latency. In the linear table, React approaches Svelte indicators due to the linear algorithm for detecting changes and reuse of existing elements, but it is still inferior in the binary case. Angular remains predictably slower than both competitors: the change detector runs through the entire component hierarchy regardless of the scale of the change, which adds a noticeable delay even when modifying a single row, which is consistent with the conclusions in the article ^[11]. The experimental results for the series update scenario are shown in Figures 10 and 11.

Figure 10 – Test results of updating a row in a binary data structure

Figure 11 – Test results of updating a row in a linear data structure

Removing elements reveals the downside of optimizations. In the binary structure, Svelte demonstrates minimal time, as it pointwise deletes the branch and immediately releases the associated event handlers. React and Angular, on the contrary, are forced to recalculate the impact of deletion on neighboring nodes, which lengthens the operation by about fifty percent. In a linear table, React is ahead of the curve: the presence of keys simplifies the search for a deleted node and reduces traversal of the collection, whereas Svelte, without having built-in virtualization of large lists ^[18], spends time updating indexes, which lags behind React by an average of one hundred and forty percent. This result highlights the need for third-party virtual scrolling libraries in Svelte projects where massive line deletion or addition is observed. The experimental results for the row deletion scenario are shown in Figures 12 and 13.

Figure 12 – Test results for deleting a row in a binary data structure

Figure 13 – Test results for deleting a row in a linear data structure

The qualitative interpretation of the revealed patterns is based on the features of internal mechanisms. In React, the cost of calculating differences in the virtual DOM is a critical factor. With a flat collection, unique keys make it possible to reduce the search for changes to a linear pass; with a deep hierarchy, on the contrary, the number of comparisons grows exponentially with depth, which makes the algorithm a bottleneck. Angular uses a change detector that is guaranteed to bypass all components at any event, ensuring stability and predictability, but instead loads the processor with unnecessary repetitive calculations. Svelte avoids runtime analysis: the compiler generates update functions that physically change only those properties that may have changed. This approach works brilliantly as long as the amount of code remains moderate; with long lists, the number of calls generated becomes significant in itself, which explains the speed loss with a linear table. The data spread and conclusions about the stability of React and Svelte are consistent with the conclusions in the article ^[16].

The experimental results are presented in Table 1.

Ta Blitz 1 – test results of modern ORC frameworks

The practical application of the results boils down to the formulation of recommendations. For systems dominated by long, homogeneous collections of records with frequent insertion and deletion operations, it is advisable to choose React, while it is necessary to include component memoization and use list virtualization to keep the algorithm for determining differences within linear time. In corporate solutions with a complex hierarchical structure that require strict typing and unified patterns, Angular remains a convenient tool, but developers should strictly use the OnPush strategy and the trackBy function to reduce the number of unnecessary passes through the tree. For projects focused on instant first rendering and deep nested interfaces, Svelte is optimal, but efficiency is maintained only while reducing the size of lists through virtual scrolling and pagination.

Conclusion

The study demonstrates that none of the popular frameworks has universal superiority. Svelte minimizes the time of the first rendering and benefits from binary changes by compiling components, React leads the way in re-updating long lists by optimizing the difference detection algorithm, Angular ensures architectural integrity at the cost of a higher LCP. The prospects for further research are related to the inclusion of SvelteKit and React Server Components server rendering, as well as the analysis of energy consumption on mobile devices.

Recommendations: focus React on applications with long dynamic lists, necessarily using keys, memoization and virtualization; choose Svelte for interfaces with deep nesting and the requirement of ultra-fast first rendering, complementing it with virtual scrolling libraries for large datasets; apply Angular in corporate systems where typing and the built-in stack are prioritized, strictly activating trackBy, OnPush and differential loading. There is no universal leader; the choice of technology should be based on the analytical profile of operations and interface topology. The presented measurement methodology provides a reproducible basis for further comparison of new library versions. The use of WebAssembly technology ^[15] to increase productivity, as well as the use of adaptive hydration ^[17] in further research, looks promising.