기본 콘텐츠로 건너뛰기

라벨이 useMemo인 게시물 표시

리액트 성능 최적화, 무작정 memo 쓰기 전에 먼저 봐야 할 기준들

리액트 성능 최적화, 무작정 memo 쓰기 전에 먼저 봐야 할 기준들 빠른 답 느린 원인을 확인하기 전에는 memo부터 늘리지 말고 React DevTools Profiler로 병목을 먼저 찾습니다. 상태를 너무 상위에 두면 하위 전체가 자주 리렌더링되므로, 상태 소유권을 필요한 범위로 최대한 좁힙니다. useMemo와 useCallback은 비용이 큰 계산이나 참조 안정성이 실제로 필요한 경우에만 적용합니다. 초기 로딩이 느리다면 라우트 단위 코드 스플리팅부터 검토하는 편이 체감 성능에 더 직접적입니다. 목차 리액트 앱은 왜 느려질까 성능 최적화의 첫 단계: 상태 소유권 좁히기 React.memo, useMemo, useCallback은 무엇이 다를까 초기 로딩이 느리다면 코드 스플리팅부터 보기 Profiler로 먼저 확인할 것 흔한 안티패턴과 디버깅 포인트 무엇부터 적용하면 좋을까 리액트 앱은 왜 느려질까 리액트 앱이 느려질 때 많은 분이 먼저 memo , useMemo , useCallback 부터 떠올립니다. 하지만 실제 병목은 대개 훅이 부족해서가 아니라, 상태가 너무 위에 있거나, 작은 변화가 너무 넓은 화면에 전파되거나, 리스트 렌더링과 정렬·필터링 같은 계산이 반복되기 때문에 생깁니다. 여기서 먼저 구분할 것이 있습니다. 리액트에서 리렌더링은 정상 동작입니다. 상태나 props 가 바뀌면 다시 렌더링하면서 다음 UI를 계산하는 것이 리액트의 기본 모델입니다. 문제는 그 렌더링 범위가 불필요하게 넓거나, 계산 자체가 무겁거나, 실제 DOM 반영 비용까지 커질 때입니다. 즉, 리렌더링이 있다 와 성능 문제가 있다 는 같은 말이 아닙니다. 성능 최적화의 목표는 리렌더링을 무조건 없애는 것이 아니라, 사용자 행동에 비해 과도한 계산과 전파를 줄이는 것입니다. 성능 최적화의 첫 단계: 상태 소유권 좁히기 프론트엔드에서 가장 먼저 봐야 할 것은 데이터 흐름입니다. 리액트는 부모에서 자식으로 내려가는 단방향 흐름을 가지므로, 어떤 상태...