Comparação de desempenho de componentes React: Gravity UI vs outras bibliotecas

Sou desenvolvedor core do Gravity UI e, periodicamente, chegam para a nossa equipe perguntas sobre a performance dos componentes React da nossa biblioteca @gravity‑ui/uikit. Decidi fazer um pequeno estudo sobre esse assunto, e tudo o que está escrito abaixo é um ponto de partida para pesquisas posteriores e uma tentativa de responder à pergunta: por que o Gravity fica lento.

Normalmente esse pedido chega sem detalhes adicionais, então parto da suposição de que um (mas, claro, não o único) dos principais problemas de performance é o longo tempo de renderização. No escopo deste estudo, analisamos o custo do primeiro render de componentes individuais de cada biblioteca em um ambiente isolado. Para comparação, foram escolhidas as bibliotecas @adobe/react‑spectrum, @mui/material e antd.

Metodologia do estudo

Stack técnico:

• Playwright — framework para automatizar testes de código em diferentes navegadores.
  Saiba mais
• PerformanceObserver API — API do navegador para medir performance.
  Saiba mais

Condições de execução dos testes:

• Cada teste é executado em um contexto separado do navegador.
• Apenas um teste é executado por vez (configuração workers no config do Playwright), o que garante a alocação da mesma quantidade de recursos para cada teste.
• Cada teste é repetido 50 vezes.
• Os testes são realizados com diferentes quantidades de nós (10, 100, 1000).

Ordem de execução de um teste:

• Abrir uma nova página no navegador.
• Inicializar o PerformanceObserver.
• Iniciar a coleta de métricas.
• Renderizar os componentes.
• Encerrar a coleta de métricas.

Processo de medição:

No início de cada teste, é criado um PerformanceObserver que rastreia eventos do tipo 'measure'. Todas as métricas coletadas são salvas no objeto global __PERFORMANCE_METRICS__. O observer coleta automaticamente dados sobre o tempo de execução das operações, incluindo o nome da métrica, o tipo de evento, o tempo de início e a duração. Usando o evento measure, registramos a nossa medição total‑render‑time.

Resultados

Os resultados das medições não trazem números absolutos. Dependendo do ambiente, eles podem, claro, variar. Mas esses números são suficientes para observar algumas relações e tirar conclusões com base nelas:

• @gravity‑ui/uikit mostra resultados competitivos:

  • Na maioria dos testes, fica na parte superior do ranking.
  • Demonstra tempo de renderização estável com diferentes quantidades de nós.
  • É especialmente eficiente nos componentes Button, Checkbox e Switch.
  • Tem problemas com o tempo de render do componente TextArea.

• @mui/material também apresenta bons resultados:

  • Lidera em quase todas as categorias (por exemplo, Text, Label) com um pequeno número de nós.
  • Apresenta um aumento visível do tempo de render conforme cresce a quantidade de nós.

• antd e React Spectrum:

  • Mostram tempo de renderização mais alto na maioria dos testes.
  • Têm maior variação entre o tempo mínimo e o máximo.

Com a ajuda desta ferramenta é possível medir performance na sua máquina local e também adicionar testes para componentes que ainda não existem. Vai nos ajudar se você a executar por conta própria e enviar em um PR o resultado obtido no seu computador.

Neste artigo eu apresentei um exemplo de como trabalhamos com a biblioteca. Mas o feedback da comunidade é muito importante para nós: se você tiver um caso específico em que o Gravity UI se sai muito pior do que outras bibliotecas, ou se você enxergar algum erro na nossa metodologia de testes, apareça nos comentários deste post ou crie uma issue, vamos discutir. E não se esqueça de dar estrelas ao projeto!