performance · medium priority
Chrome DevTools 실무 활용
Performance, Memory, Network 탭 — 성능 문제를 찾고 해결하는 방법
학습 개요
탄생 배경
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“자동차 OBD 진단기”
DevTools는 자동차에 연결하는 OBD 진단기입니다. "이상한 소리가 나는데 원인을 모르겠어요"가 아니라 "3번 실린더에서 점화 실패"처럼 구체적인 문제를 알려줍니다. 성능 문제를 추측이 아닌 데이터로 찾을 수 있습니다.
핵심 개념
Performance 탭 분석 방법
CPU 스로틀링 설정
실제 사용자 환경 시뮬레이션. 4x slowdown이 일반적
프로파일링 시작/종료
Record 클릭 → 문제 상황 재현 → Stop
Summary 확인
Scripting, Rendering, Painting 비율 확인. 어느 단계가 시간을 많이 차지하는지
Long Tasks 찾기
빨간 삼각형이 있는 Task. 50ms 이상 태스크가 메인 스레드를 점령
Call Tree 분석
시간이 많이 걸리는 함수 식별. Bottom-Up 탭에서 expensive function 찾기
Layout Thrashing 패턴
JavaScript에서 DOM을 읽고 즉시 쓰는 패턴(예: element.offsetHeight 읽기 → style.height 쓰기를 반복)은 강제 레이아웃을 일으킵니다. Performance 탭에서 "Forced reflow" 경고로 나타납니다. 읽기와 쓰기를 분리하거나 requestAnimationFrame으로 배치 처리하면 해결됩니다.
실무 적용
어떤 상황에서 사용하는가
프로덕션 앱이 특정 페이지에서 버벅인다는 사용자 불만 접수
어떻게 적용하는가
Lighthouse로 전반적 성능 점수 확인. Performance 탭에서 CPU 4x 스로틀링 후 녹화 → Long Task와 Layout Thrashing 확인. Network 탭에서 불필요한 큰 번들이나 순차 요청 찾기. Memory 탭에서 페이지 이동 반복 후 메모리 증가 여부 확인.
흔한 실수와 안티패턴
- DevTools를 열면 성능이 약간 달라짐 — 프로파일링은 DevTools 탭을 닫은 상태에서
- Performance 탭 녹화 시간이 길면 분석이 어려움 — 짧게 특정 동작만 녹화
- CPU 스로틀링 없이 프로파일링하면 실제 사용자 경험과 차이
- Lighthouse 점수에 집착하지 말고 실제 사용자 경험 지표(Core Web Vitals) 집중
면접 질문
답변 방향 힌트
체계적인 접근 방법, 사용 도구
반드시 언급할 키워드
- Performance 탭으로 Long Task 확인
- Layout Thrashing 감지
- scroll 이벤트 핸들러 분석
예상 꼬리 질문
- Lighthouse와 실제 사용자 성능 데이터(RUM)의 차이는?
- React DevTools Profiler와 Chrome DevTools의 차이는?