
Performance Comparison of React Components: Gravity UI vs Other Libraries
Performance Comparison of React Components: Gravity UI vs Other Libraries
I’m a core developer of Gravity UI, and from time to time our team gets questions about the performance of React components from our library @gravity‑ui/uikit. I decided to run a small study on this topic, and everything written below is a starting point for further research and an attempt to answer the question of why Gravity feels slow.

Usually this question comes without any additional details, so I’m assuming that one (though, of course, not the only) major performance issue is long render time. As part of this study, we looked at the cost of the initial render of individual components from each library in an isolated environment. For comparison, we chose @adobe/react‑spectrum, @mui/material, and antd.
Research methodology
Tech stack:
- Playwright — a framework for automated testing across different browsers.
Learn more - PerformanceObserver API — a browser API for measuring performance.
Learn more
Test conditions:
- Each test is run in a separate browser context.
- Only one test runs at a time (the
workerssetting in the Playwright config), which guarantees the same amount of resources allocated to each test. - Each test is repeated 50 times.
- Tests are run with different numbers of nodes (10, 100, 1000).
Steps for a single test run:
- Open a new page in the browser.
- Initialize
PerformanceObserver. - Start collecting metrics.
- Render components.
- Stop collecting metrics.
Measurement process:
At the beginning of each test, a PerformanceObserver is created to listen for events of type 'measure'. All collected metrics are stored in a global object __PERFORMANCE_METRICS__. The observer automatically collects data about operation execution time, including the metric name, event type, start time, and duration. Using the measure event, we log our total‑render‑time measurement.
Results
The measurement results don’t include absolute numbers. From one environment to another they can, of course, vary. But these figures are sufficient to see some patterns and draw conclusions based on them:
-
@gravity‑ui/uikit shows competitive results:
- In most tests it ranks near the top.
- Demonstrates stable render time across different node counts.
- Particularly effective for Button, Checkbox, and Switch components.
- Has issues with the render time of the
TextAreacomponent.
-
@mui/material also shows good results:
- Leads in almost all categories (e.g., Text, Label) with a small number of nodes.
- Shows a noticeable increase in render time as the number of nodes grows.
-
antd and React Spectrum:
- Show higher render times in most tests.
- Have a larger spread between minimum and maximum times.
Using this tool, you can run performance measurements on your local machine and add tests for components that aren’t covered yet. It would help us if you deploy it on your side and send a PR with the results from your machine.
In this article, I shared one example of how we work with the library. But community feedback is very important to us: if you have a specific case where Gravity UI performs significantly worse than other libraries, or if you notice an issue with our testing methodology, come to the comments under this post or create an issue — let’s discuss it. And don’t forget to star the project!

Evgeny Alaev
Gravity UI Core Developer
In this article: