렌더 추적과 성능 튜닝
읽는 시간 약 11분
이 문서에서 배우는 것
- 렌더 추적기를 켜고 읽는 법
- 갱신이 넓게 번지는 세 가지 원인
- 최적화를 멈춰야 할 지점
추적기 켜기
개발 빌드에는 렌더 추적기가 들어 있습니다. 켜면 갱신이 일어날 때마다 어떤 상태가 어떤 자리를 깨웠는지 콘솔에 남습니다.
import { trace } from 'loopkit/dev';
trace.enable({ log: 'updates' });출력은 상태 이름 → 갱신된 자리 수 형태입니다. 버튼 한 번에 자리 수가 수백으로 찍힌다면, 화면이 큰 게 아니라 의존 관계가 넓게 걸려 있을 가능성이 큽니다.
넓게 번지는 세 가지 원인
첫째, 큰 객체 하나를 통째로 상태에 담고 매번 새 객체를 넣는 경우입니다. 객체의 어떤 필드를 봤는지와 무관하게 모든 독자가 깨어납니다. 필드별로 상태를 나누면 사라집니다.
둘째, 템플릿 최상단에서 상태를 읽고 그 값을 아래로 흘려보내는 경우입니다. 읽는 지점이 위로 올라갈수록 갱신 단위가 커집니다. 값을 실제로 쓰는 자리에서 읽으세요.
셋째, 이펙트가 상태를 쓰고 그 상태가 다시 이펙트를 깨우는 순환입니다. 추적기 로그에 같은 이름이 연달아 찍히면 이 경우입니다.
// 넓게 번지는 형태
const profile = state({ name: '', email: '' });
// 좁게 유지되는 형태
const name = state('');
const email = state('');주의
목록 항목을 메모이제이션하기 전에 키부터 확인하세요. 키가 불안정하면 아무리 메모해도 항목이 매번 새로 만들어집니다.
언제 멈출까
추적기 숫자가 사용자에게 보이는 지연으로 이어지지 않는다면 거기서 멈추는 게 맞습니다. 대부분의 화면에서 병목은 렌더가 아니라 네트워크와 이미지입니다. 최적화 코드는 읽기 비용을 남기므로, 측정한 이득이 없다면 되돌리세요.
요약
- 추적기는 “무엇이 무엇을 깨웠는가”를 알려 준다.
- 상태를 잘게 나누고, 값을 쓰는 자리에서 읽는다.
- 측정된 이득이 없는 최적화는 되돌린다.
