리렌더링 원인 추적

리렌더 원인 판별 기준

state 위치, props identity, context value, memoization boundary 항목을 측정 관점에서 나누고, 화면 상태와 사용자 조작이 어느 컴포넌트에서 바뀌는지 표시합니다.

측정

state 소유권과 memo 적용 경계

리렌더링 문제는 부모 컴포넌트, provider value, callback/object 생성 위치, memo 적용 지점을 나눠 측정합니다. 같은 조작에서 렌더 횟수와 commit 시간을 비교합니다.

렌더 원인

불필요한 리렌더링 방지의 실패 조건

값은 같아 보이지만 참조가 매 렌더마다 바뀌면 하위 트리가 반복해서 그려집니다. 같은 입력을 빠르게 반복해 render count가 어디서 증가하는지 확인합니다.

최적화 경계

Profiler commit 비교 결과

마지막에는 render count, Profiler commit 시간, props diff, memo 적용 전후 비교를 남겨 느린 입력이 어느 컴포넌트에서 줄었는지 다시 확인합니다.

close

렌더 원인

리렌더링은 state, props, context 변경 뒤 컴포넌트 함수를 다시 실행하는 과정입니다 느린 화면을 보기 전에 어떤 값이 바뀌어 어떤 하위 트리까지 다시 계산되는지 render count와 props diff로 좁힙니다.

render count

측정 범위

입력 지연, commit 시간, 하위 컴포넌트 렌더 횟수를 같은 조작으로 비교합니다 검색어 입력, 탭 전환, 목록 선택처럼 실제 사용자가 반복하는 동작을 기준으로 최적화 전후의 체감 지연을 확인합니다.

Profiler

측정 대조

Memoization은 참조가 안정적이고 렌더 비용이 클 때만 이득인지 확인합니다 React.memo, useMemo, useCallback 적용 뒤 stale 값, 빠진 의존성, 비교 비용 증가가 생기지 않는지 같은 시나리오로 다시 측정합니다.

before/after

불필요한 리렌더링 방지 검증 지점

측정된 개선 같은 입력에서 commit 시간이 줄고, 바뀌지 않은 하위 컴포넌트의 render count가 유지되며, 화면 결과는 그대로인지 확인합니다.

무효 최적화 부모에서 새 객체와 새 함수를 계속 만들면 memo가 매번 깨지므로 props identity가 안정적인지 먼저 확인합니다.

성능 기록 Profiler flamegraph, commit duration, 느린 입력 재현 영상을 함께 남겨 이후 변경에서 같은 병목이 돌아오는지 비교합니다.

성능 디버깅 점검

질문: 어떤 state, props, context 변경이 불필요한 하위 렌더를 만드는가
순서: state 변경이 렌더를 부르는 조건 파악하기 -> Profiler로 느린 commit과 원인 컴포넌트 묶기 -> memoization 적용 전후를 같은 조작으로 비교하기
위험: 측정 없이 memo를 붙이면 참조 흔들림은 그대로 남고 의존성 관리 비용만 늘어납니다.