Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки

Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос, почему Gravity тормозит.

Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.

Методология исследования

Технический стек:

• Playwright — фреймворк для автоматизации тестирования кода в разных браузерах.
  Подробнее
• PerformanceObserver API — браузерный API для измерения производительности.
  Подробнее

Условия выполнения тестов:

• Каждый тест запускается в отдельном контексте браузера.
• Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.
• Каждый тест повторяется 50 раз.
• Тесты проводятся с разным количеством нод (10, 100, 1000).

Порядок выполнения одного теста:

• Открытие новой страницы в браузере.
• Инициализация PerformanceObserver.
• Начало сбора метрик.
• Рендеринг компонентов.
• Завершение сбора метрик.

Процесс измерения:

В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.

Результаты

Результаты замеров не содержат в себе абсолютных цифр. От окружения к окружению они, конечно же, могут варьироваться. Но этих цифр вполне достаточно, чтобы увидеть некоторые зависимости и сделать на их основании выводы:

• @gravity‑ui/uikit показывает конкурентоспособные результаты:

  • В большинстве тестов находится в верхней части рейтинга.
  • Демонстрирует стабильное время рендеринга при разном количестве нод.
  • Особенно эффективен в компонентах Button, Checkbox и Switch.
  • Имеет проблемы со временем рендера компонента TextArea.

• @mui/material также показывает хорошие результаты:

  • Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.
  • Имеет видимый рост времени рендера в зависимости от количества нод.

• antd и React Spectrum:

  • Показывают более высокое время рендеринга в большинстве тестов.
  • Имеют больший разброс между минимальным и максимальным временем.

С помощью этого инструмента можно провести замеры производительности на своей локальной машине, а также добавить тесты для компонентов, которых ещё нет. Нам поможет, если вы развернёте его у себя и пришлёте в PR результат работы на своём компьютере.

В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!