TypeScript 성능

프로파일링 신호에서 최적화 액션까지

느리다는 느낌을 브라우저, React, Node.js 프로파일러 신호로 쪼개고 코드 변경 전에 병목 위치를 먼저 고정한다.

01

증상 계측

사용자 흐름에서 느린 구간과 기준 시간을 정하고 재현 스크립트를 만든다.

baseline
02

프로파일 캡처

Performance, Profiler, clinic, inspector 중 실행 환경에 맞는 도구로 병목을 잡는다.

근거
03

원인 분류

렌더링, 네트워크, 알고리즘, 메모리, I/O 대기를 서로 분리한다.

bucket
04

효과 검증

수정 전후 p95, bundle size, render count가 목표치로 이동했는지 비교한다.

before/after
memo
props 안정성이 없으면 memo는 비교 비용만 추가한다. useMemo와 useCallback은 참조 안정성이 실제 렌더 차이를 만들 때 쓴다.
render proof required
bundle
초기 로딩 병목이면 코드 분할과 dependency trimming을 먼저 본다. 큰 라이브러리는 route boundary와 dynamic import로 이동한다.
initial JS budget
Node
CPU가 높으면 비동기 전환보다 알고리즘과 직렬화 비용을 먼저 의심한다. event loop lag와 heap growth를 같은 시간축에서 본다.
profile timeline

최적화 전 금지선

측정 없음 금지 수정 전 수치가 없으면 개선도 우연인지 알 수 없다.
전역 캐시 점검 메모리 누수와 사용자별 데이터 섞임을 함께 점검한다.
체감 기준 평균보다 p75, p95와 핵심 화면 완료 시간을 본다.

측정 기록

before: route=/dashboard p95=1420ms bundle=318kb renders=12
after:  route=/dashboard p95=820ms bundle=211kb renders=4