성능 문제는 추측하지 말고 측정해야 해. React DevTools Profiler로 느린 상호작용을 찾고, 필요한 곳만 고친 뒤 멈추는 흐름을 익혀.
React DevTools의 두 화면
Profiler는 일정 시간 동안 어떤 컴포넌트가 왜 다시 렌더링됐고 얼마나 걸렸는지 기록해. Components 탭은 선택한 컴포넌트의 props, 상태, 훅 값을 보여 줘. 하나는 성능의 시간 흐름을 보고, 다른 하나는 특정 렌더링의 입력을 확인하는 도구야.
찾아야 할 신호
- Prop이 바뀌지 않았는데 부모 때문에 반복해서 렌더링되는 컴포넌트.
- 한 번 렌더링하는 데 오래 걸리는 계산이나 너무 큰 자식 트리.
- Context value나 높은 위치의 상태 하나가 넓은 트리를 깨우는 연쇄 렌더링.
원인에 따라 React.memo, 안정적인 prop, useMemo, virtualization, 상태 위치 조정 같은 다른 해법을 골라야 해.
Suspense와 concurrent 업데이트 보기
Profiler에서는 컴포넌트가 언제 중단됐고 프로미스가 이행될 때까지 얼마나 걸렸는지 확인할 수 있어. 업데이트가 긴급한 작업인지 transition인지도 구분할 수 있으므로, 의도했던 transition이 실제로는 긴급 업데이트로 실행되는 문제를 찾기 좋아.
Profiler의 세 보기를 함께 읽어
Flamegraph는 한 commit에서 어느 컴포넌트가 오래 걸렸는지 보여 주고, Ranked view는 비용이 큰 순서로 정렬해. Commit timeline을 보면 한 상호작용이 몇 번의 commit을 만들었는지 알 수 있어. 문제를 재현할 짧은 상호작용만 record해 잡음을 줄여.
왜 렌더링됐는지 확인해
Prop 변경, state 변경, Context 변경, 부모 렌더링 중 무엇이 원인인지 DevTools의 표시를 확인해. 원인이 다르면 React.memo, state 위치 조정, Context 분리, virtualization, 계산 메모이제이션처럼 해법도 달라.
고친 뒤 같은 시나리오를 다시 측정해
개발 빌드는 StrictMode와 추가 검사가 있어 절대 시간 비교에 잡음이 생길 수 있어. 같은 환경에서 변경 전후 commit 시간과 렌더링 횟수를 비교하고, 프로덕션 preview에서도 사용자 입력이 실제로 부드러워졌는지 확인해.