React 컴포넌트 성능 비교: Gravity UI vs 다른 라이브러리

저는 Gravity UI의 코어 개발자이며, 팀에는 우리 라이브러리 @gravity-ui/uikit의 React 컴포넌트 성능에 대한 질문이 주기적으로 들어옵니다. 저는 이 주제에 대해 간단한 조사를 해보기로 했고, 아래에 적힌 내용은 향후 추가 연구를 위한 출발점이자, Gravity가 왜 느린지에 대한 질문에 답해 보려는 시도입니다.

보통 이런 문의는 별다른 추가 정보 없이 올라오기 때문에, 저는 성능 문제의 주요 원인 중 하나(물론 유일한 원인은 아니지만)가 긴 렌더링 시간이라고 가정했습니다. 이번 연구에서는 격리된 환경에서 각 라이브러리의 개별 컴포넌트에 대한 첫 렌더링 비용을 살펴봤습니다. 비교 대상으로는 @adobe/react-spectrum, @mui/material, antd 라이브러리를 선택했습니다.

연구 방법론

기술 스택:

• Playwright — 다양한 브라우저에서 코드를 자동으로 테스트하기 위한 프레임워크.
  자세히 보기
• PerformanceObserver API — 성능을 측정하기 위한 브라우저 API.
  자세히 보기

테스트 실행 조건:

• 각 테스트는 별도의 브라우저 컨텍스트에서 실행됩니다.
• 한 번에 하나의 테스트만 실행합니다(Playwright 설정의 workers 값). 이를 통해 각 테스트에 동일한 양의 리소스가 할당됨을 보장합니다.
• 각 테스트는 50회 반복합니다.
• 테스트는 서로 다른 노드 수(10, 100, 1000)로 수행됩니다.

단일 테스트 수행 순서:

• 브라우저에서 새 페이지 열기.
• PerformanceObserver 초기화.
• 메트릭 수집 시작.
• 컴포넌트 렌더링.
• 메트릭 수집 종료.

측정 과정:

각 테스트 시작 시 'measure' 타입 이벤트를 추적하는 PerformanceObserver를 생성합니다. 수집된 모든 메트릭은 전역 객체 __PERFORMANCE_METRICS__에 저장됩니다. Observer는 메트릭 이름, 이벤트 타입, 시작 시간, 지속 시간 등을 포함해 작업 수행 시간에 대한 데이터를 자동으로 수집합니다. measure 이벤트를 사용해 total-render-time 측정 값을 로깅합니다.

결과

측정 결과에는 절대적인 수치가 포함되어 있지 않습니다. 환경에 따라 당연히 달라질 수 있습니다. 하지만 이 수치만으로도 몇 가지 경향을 확인하고 그에 기반해 결론을 내리기에 충분합니다:

• @gravity-ui/uikit은 경쟁력 있는 결과를 보여줍니다:

  • 대부분의 테스트에서 상위권에 위치합니다.
  • 노드 수가 달라도 렌더링 시간이 안정적입니다.
  • Button, Checkbox, Switch 컴포넌트에서 특히 효율적입니다.
  • TextArea 컴포넌트의 렌더링 시간에는 문제가 있습니다.

• @mui/material도 좋은 결과를 보여줍니다:

  • 노드 수가 적을 때 Text, Label 등 거의 모든 카테고리에서 선두를 차지합니다.
  • 노드 수에 따라 렌더링 시간이 눈에 띄게 증가합니다.

• antd와 React Spectrum:

  • 대부분의 테스트에서 더 긴 렌더링 시간을 보입니다.
  • 최소/최대 시간 간 편차가 더 큽니다.

이 도구를 사용하면 로컬 머신에서 성능 측정을 수행할 수 있으며, 아직 없는 컴포넌트에 대한 테스트도 추가할 수 있습니다. 여러분이 직접 설치해 실행해 보고, 자신의 컴퓨터에서 얻은 결과를 PR로 보내주시면 큰 도움이 됩니다.

이 글에서는 우리가 라이브러리로 작업하는 방식의 한 가지 예를 소개했습니다. 하지만 커뮤니티의 피드백은 우리에게 매우 중요합니다. Gravity UI가 다른 라이브러리보다 훨씬 나쁘게 동작하는 구체적인 사례가 있거나, 우리의 테스트 방법론에 오류가 있다고 생각된다면 이 글의 댓글로 오시거나 이슈를 생성해 주세요. 함께 논의하겠습니다. 그리고 프로젝트에 별을 주는 것도 잊지 마세요!