React DevTools: 렌더 원인 추적

컴포넌트 트리 읽기

component tree에서 실제 렌더된 이름과 계층을 확인하고, 의심 컴포넌트의 props/state가 어느 조작에서 바뀌는지 따라갑니다.

측정

props와 state 변화

Components 탭에서 hooks 값과 props diff를 비교하면 상태가 부모에서 내려왔는지, 컴포넌트 안에서 갱신됐는지 분리해 볼 수 있습니다.

렌더 원인

Profiler 기록

클릭, 입력, 라우트 이동을 짧게 녹화하고 flamegraph에서 commit 시간과 자주 렌더된 컴포넌트를 먼저 봅니다.

최적화 위치

최적화 전후 비교

memo, useMemo, 상태 위치 변경을 적용하기 전후의 캡처를 비교해야 체감이 아니라 측정값으로 개선을 말할 수 있습니다.

profile diff

Components 탭

선택한 컴포넌트의 props, state, hooks 값을 확인한다 화면에서 보이는 값과 DevTools의 내부 값이 다르면 렌더 조건이나 파생 상태부터 의심합니다.

props/state

Profiler 탭

사용자 조작 한 번을 녹화하고 commit 단위로 본다 느린 화면은 전체 페이지가 아니라 오래 걸린 commit과 자주 렌더된 컴포넌트부터 좁힙니다.

flamegraph

렌더 원인

왜 다시 렌더됐는지 props 변경과 state 변경을 분리한다 부모 렌더 전파인지, 새 객체 props인지, 로컬 state 변경인지 구분해야 최적화 위치가 보입니다.

render reason

DevTools로 확인할 장면

상태 변경 추적 입력 한 번 뒤 바뀐 state와 화면 문구가 같은 컴포넌트 트리에서 설명되는지 확인합니다.

불필요한 렌더 값이 바뀌지 않은 자식이 반복 렌더되면 props identity와 memo 적용 위치를 비교합니다.

캡처 기록 Profiler 스크린샷과 조작 순서를 함께 남기면 나중에 같은 느림을 다시 재현할 수 있습니다.

성능 디버깅 점검

질문: 이 렌더는 어떤 props나 state 변화 때문에 발생했는가
순서: Components 탭에서 값 확인 -> Profiler 녹화 -> render reason 비교 -> 최적화 전후 캡처
위험: 측정 없이 memo를 추가하면 느린 컴포넌트는 그대로 두고 코드만 복잡해질 수 있습니다.