화면이 반응을 느릴 때 상태 업데이트 최적화하기

사용자가 화면의 어떤 버튼을 눌렀을 때만 그 다음 화면이 3초 늦게 나타난다고 했다. 다른 동작은 빠른데 왜 이것만 느릴까?

운영 환경에서 보는 현상과 로컬 개발 환경의 차이를 파악해야 한다. 로컬에서는 빠르지만 배포 후 느린 경우가 대부분이다.

사용자 입장에서 보는 흐름

사용자가 버튼을 눌렀을 때:

1. 버튼이 변하는가? (로딩 상태 표시)
2. API 요청이 나가는가? (개발자 도구의 네트워크 탭)
3. 응답이 오는 데 얼마나 걸리는가?
4. 응답받은 후 화면이 갱신되는 데 얼마나 걸리는가?

각 단계의 소요 시간을 따로 측정한다.

성능 측정

React DevTools의 Profiler를 사용해서 렌더링 시간을 본다.

npm run build
# 프로덕션 빌드에서 측정

Production 빌드는 Development와 성능이 크게 다를 수 있다. 반드시 프로덕션으로 측정해야 한다.

키보드 입력과 마우스 이벤트

모바일과 데스크톱에서 입력 방식이 다르다. 마우스로는 빠르지만 터치에서는 느릴 수도 있다.

# 모바일 기기에서 실제 테스트
# 또는 브라우저 개발자 도구에서 모바일 뷰포트 시뮬레이션
# Slow CPU 3x도 활성화해서 테스트

렌더링 최적화

상태 업데이트 후 불필요한 컴포넌트까지 다시 그리고 있지는 않은가?

// 부모 상태 업데이트
setLoading(true);
// -> 자식 컴포넌트들도 모두 다시 렌더링

// 최적화: memo() 또는 useMemo
const MyComponent = React.memo(({ data }) => {
  return <div>{data}</div>;
});

React DevTools에서 "Highlight updates when components render"를 활성화하면, 렌더링되는 컴포넌트가 흰색으로 표시된다. 불필요한 컴포넌트가 렌더링되고 있다면 그걸 최적화한다.

API 응답 속도

브라우저 개발자 도구에서 네트워크 탭을 보면, 실제 응답 시간을 알 수 있다.

• 대기 시간 (TTFB): 요청을 보낸 후 서버 응답까지의 시간
• 다운로드 시간: 응답 본문을 다운로드하는 시간

TTFB가 3초라면, 프론트엔드가 아무리 최적화해도 소용이 없다. 백엔드를 최적화해야 한다.

로컬과 배포의 성능 비교

로컬:

• 데이터: 테스트 데이터 (적음)
• 네트워크: localhost (지연 없음)
• CPU: 고사양 개발 머신

배포:

• 데이터: 실제 데이터 (많음)
• 네트워크: 실제 인터넷 (지연 있음)
• CPU: 서버 (낮을 수 있음)

따라서 배포 환경에서 느린 건 정상이다. 그것에 맞게 최적화해야 한다.

최적화 순서

1. 백엔드 API 응답 시간 개선 (캐싱, 쿼리 최적화)
2. 프론트엔드 번들 크기 최소화 (동적 import, tree-shaking)
3. 불필요한 렌더링 제거 (memo, useMemo, useCallback)
4. 가상 스크롤 (큰 리스트인 경우)

마지막으로, 성능 문제는 측정하지 않으면 보이지 않는다. 주관적인 "느리다"는 판단이 아니라, 정확한 숫자로 어느 단계가 느린지 파악해야 한다. 그래야 올바른 최적화를 할 수 있다.