렌더 추적과 성능 튜닝

읽는 시간 약 11

이 문서에서 배우는 것

  • 렌더 추적기를 켜고 읽는 법
  • 갱신이 넓게 번지는 세 가지 원인
  • 최적화를 멈춰야 할 지점

추적기 켜기

개발 빌드에는 렌더 추적기가 들어 있습니다. 켜면 갱신이 일어날 때마다 어떤 상태가 어떤 자리를 깨웠는지 콘솔에 남습니다.

import { trace } from 'loopkit/dev';

trace.enable({ log: 'updates' });

출력은 상태 이름 → 갱신된 자리 수 형태입니다. 버튼 한 번에 자리 수가 수백으로 찍힌다면, 화면이 큰 게 아니라 의존 관계가 넓게 걸려 있을 가능성이 큽니다.

넓게 번지는 세 가지 원인

첫째, 큰 객체 하나를 통째로 상태에 담고 매번 새 객체를 넣는 경우입니다. 객체의 어떤 필드를 봤는지와 무관하게 모든 독자가 깨어납니다. 필드별로 상태를 나누면 사라집니다.

둘째, 템플릿 최상단에서 상태를 읽고 그 값을 아래로 흘려보내는 경우입니다. 읽는 지점이 위로 올라갈수록 갱신 단위가 커집니다. 값을 실제로 쓰는 자리에서 읽으세요.

셋째, 이펙트가 상태를 쓰고 그 상태가 다시 이펙트를 깨우는 순환입니다. 추적기 로그에 같은 이름이 연달아 찍히면 이 경우입니다.

// 넓게 번지는 형태
const profile = state({ name: '', email: '' });

// 좁게 유지되는 형태
const name = state('');
const email = state('');

주의

목록 항목을 메모이제이션하기 전에 키부터 확인하세요. 키가 불안정하면 아무리 메모해도 항목이 매번 새로 만들어집니다.

언제 멈출까

추적기 숫자가 사용자에게 보이는 지연으로 이어지지 않는다면 거기서 멈추는 게 맞습니다. 대부분의 화면에서 병목은 렌더가 아니라 네트워크와 이미지입니다. 최적화 코드는 읽기 비용을 남기므로, 측정한 이득이 없다면 되돌리세요.

요약

  • 추적기는 “무엇이 무엇을 깨웠는가”를 알려 준다.
  • 상태를 잘게 나누고, 값을 쓰는 자리에서 읽는다.
  • 측정된 이득이 없는 최적화는 되돌린다.