테마
Chrome Performance Tab 활용
Chrome DevTools의 Performance 탭을 사용하여 런타임 성능을 분석하고, 타임라인 기록 해석, 프레임률/CPU/네트워크 활동 시각화, 그리고 Long Tasks와 Layout Thrashing 같은 병목 지점을 식별하는 방법을 학습한다.
학습 목표
- Chrome DevTools Performance 탭의 역할과 주요 기능을 이해한다
- 타임라인 기록(Record)과 프로파일 기록(Reload) 방법을 익힌다
- 기록된 프로파일의 각 섹션(Overview, Network, Main, Frames 등)을 해석할 수 있다
- Long Tasks, Layout Thrashing 등 성능 병목 패턴을 식별할 수 있다
- 마이크로프론트엔드 환경에서 주의해야 할 성능 이슈를 파악한다
1. Performance 탭 소개
Chrome Performance 탭은 웹페이지의 런타임 성능을 실시간으로 분석하고 시각화하는 도구다. Lighthouse가 자동화된 "감사"라면, Performance 탭은 개발자가 직접 행동을 기록하며 미시적으로 분석하는 "현미경"이다.
1.1 Performance 탭 vs Lighthouse
| 비교 항목 | Performance 탭 | Lighthouse |
|---|---|---|
| 분석 방식 | 수동 기록, 직접 분석 | 자동 감사, 점수화 |
| 분석 깊이 | 개별 함수 호출까지 추적 | 카테고리별 종합 점수 |
| 적합한 상황 | 특정 상호작용의 병목 분석 | 전반적 성능 평가 |
| 결과물 | 타임라인 + 콜 스택 | 점수 + 개선 제안 |
1.2 주요 기능
- 타임라인 뷰: 페이지 로드와 상호작용에 대한 시간별 세부사항을 제공한다
- 프레임 레이트 차트: 초당 프레임 수(fps)를 시각화하여 애니메이션의 원활함을 확인한다
- CPU/네트워크 리소스: JavaScript 실행, 레이아웃 계산, 렌더링, 리소스 로딩 등의 CPU 사용량과 네트워크 활동을 보여준다
- 콜 스택 추적: 어떤 함수가 언제, 얼마나 오래 실행되었는지 추적한다
2. Performance 탭 사용 방법
2.1 접근 방법
1. Chrome 브라우저에서 분석할 페이지 열기
2. F12 또는 Cmd+Option+I (Mac) / Ctrl+Shift+I (Windows)
3. 상단 탭에서 "Performance" 선택2.2 기록 방법
두 가지 기록 방법이 있으며, 목적에 따라 선택한다.
방법 1: Record (수동 기록)
- 녹화 버튼 클릭 후 관심 있는 상호작용 수행
- 완료 후 Stop 버튼 클릭
- 특정 사용자 행동(클릭, 스크롤 등)의 성능을 분석할 때 적합
방법 2: Reload (페이지 로드 기록)
- 새로고침 아이콘 버튼 클릭
- 페이지가 자동으로 새로고침되면서 로딩 과정을 기록
- 초기 페이지 로드 성능을 분석할 때 적합
2.3 기록 전 설정
- CPU throttling: "4x slowdown"으로 저사양 디바이스를 시뮬레이션할 수 있다
- Network throttling: "Fast 3G"로 느린 네트워크를 시뮬레이션할 수 있다
- Screenshots: 활성화하면 기록 중 화면 변화를 스크린샷으로 캡처한다
- Memory: 활성화하면 메모리 사용량 추이를 함께 기록한다
3. 프로파일 해석
기록이 완료되면 여러 섹션으로 구성된 프로파일이 표시된다.
3.1 Overview (개요 영역)
가장 상단에 위치하며, 기록 전체의 CPU 사용량, 네트워크 활동, FPS를 요약 그래프로 보여준다.
- CPU 차트: 영역 그래프로 표시되며, 색상별로 작업 유형을 구분한다
- 노란색: JavaScript 실행
- 보라색: 렌더링 (Layout, Recalculate Styles)
- 초록색: 페인팅
- 회색: 기타 작업
- 빨간색 막대: 프레임 드롭이 발생한 구간을 표시한다
3.2 Network (네트워크)
각 리소스의 로딩 시간을 수평 막대로 표시한다.
- 파란색: HTML 문서
- 노란색: JavaScript 파일
- 보라색: CSS 파일
- 초록색: 이미지
- 막대의 왼쪽 부분(연한 색)은 대기(TTFB) 시간, 오른쪽(진한 색)은 다운로드 시간이다
3.3 Frames (프레임)
각 프레임의 렌더링 시점과 지속 시간을 보여준다. 클릭하면 해당 시점의 스크린샷을 확인할 수 있다. 애니메이션이 매끄럽게 동작하는지 확인할 때 유용하다.
3.4 Timings (타이밍)
FP, FCP, LCP, DCL(DOMContentLoaded), Load 등의 이벤트 시점이 세로 마커로 표시된다.
3.5 Main (메인 스레드)
가장 중요한 섹션이다. JavaScript 함수 호출 스택이 화염 차트(Flame Chart) 형태로 표시된다.
- 상단의 넓은 막대: 상위 태스크
- 아래로 갈수록: 호출된 하위 함수
- 막대의 너비: 해당 함수의 실행 시간
- 빨간 삼각형: Long Task (50ms 이상 메인 스레드를 차단하는 태스크)
3.6 Bottom-Up / Call Tree / Event Log
- Bottom-Up: Self Time(자기 자신만의 실행 시간)이 가장 긴 함수부터 정렬한다. 실제 병목 함수를 찾는 데 가장 효과적이다.
- Call Tree: 콜 트리 구조로 Total Time이 긴 루트부터 펼쳐 나간다.
- Event Log: 기록된 이벤트를 시간순으로 나열한다.
4. 병목 지점 식별
4.1 Long Tasks
메인 스레드를 50ms 이상 연속으로 차단하는 태스크다. Performance 탭의 Main 섹션에서 우측 상단에 빨간 삼각형으로 표시된다.
Long Task의 영향:
- 사용자 입력에 대한 응답이 지연된다 (INP 악화)
- 애니메이션이 끊기거나 버벅인다
- 레이아웃이 밀리거나 스크롤이 멈추는 현상이 발생한다
해결 방법:
- 큰 작업을 작은 청크로 분할 (
requestIdleCallback,setTimeout(fn, 0)) - Web Worker로 CPU 집약 연산을 오프로드
- 불필요한 동기 작업 제거
4.2 Layout Thrashing
JavaScript에서 DOM 스타일을 변경한 직후 레이아웃 정보(offsetHeight, getBoundingClientRect 등)를 읽으면, 브라우저가 강제로 동기 레이아웃 재계산을 수행한다. 이것이 반복문 안에서 발생하면 심각한 성능 저하를 일으킨다.
javascript
// Layout Thrashing - 잘못된 패턴
for (let i = 0; i < elements.length; i++) {
elements[i].style.width = box.offsetWidth + "px"; // 읽기 -> 쓰기 반복
}
// 개선된 패턴 - 읽기와 쓰기를 분리
const width = box.offsetWidth; // 한 번만 읽기
for (let i = 0; i < elements.length; i++) {
elements[i].style.width = width + "px"; // 쓰기만 반복
}Performance 탭에서 보라색 "Layout" 블록이 빈번하게 나타나면 Layout Thrashing을 의심할 수 있다.
4.3 강제 리플로우 (Forced Reflow)
Performance 탭에서 "Recalculate Style" 또는 "Layout" 옆에 경고 아이콘이 표시되면, 강제 동기 레이아웃이 발생한 것이다. 클릭하면 원인이 된 코드 위치를 확인할 수 있다.
5. 마이크로프론트엔드에서 주의할 성능 이슈
마이크로프론트엔드 환경에서는 Performance 탭 분석 시 다음 항목에 특히 주의해야 한다.
5.1 remoteEntry.js 로딩 체인
Network 섹션에서 각 마이크로앱의 remoteEntry.js 로딩 시점과 후속 청크 파일의 워터폴을 확인한다. 워터폴이 깊으면 <link rel="preload">로 선제 로딩을 적용한다.
5.2 중복 라이브러리 실행
Main 섹션에서 동일한 라이브러리(React, ReactDOM 등)의 초기화 코드가 여러 번 실행되는지 확인한다. Module Federation의 shared 설정이 제대로 작동하는지 검증하는 데 유용하다.
5.3 마이크로앱 전환 시 성능
마이크로앱 A에서 B로 전환할 때의 기록을 분석한다. B의 모든 코드를 새로 로드하는지, 캐시된 리소스를 재사용하는지 확인한다.
5.4 장애 전파 확인
하나의 마이크로앱에서 발생한 Long Task가 다른 마이크로앱의 렌더링을 차단하는지 확인한다. 모든 마이크로앱은 동일한 메인 스레드를 공유하기 때문에, 하나의 앱에서 발생한 무거운 연산이 전체 페이지에 영향을 줄 수 있다.
6. 실전 분석 팁
6.1 CPU 쓰로틀링 활성화
개발자의 고성능 머신에서는 문제가 발생하지 않지만, 사용자의 저사양 디바이스에서는 심각한 성능 문제가 나타날 수 있다. 4x slowdown 옵션을 켜고 분석하면 실제 사용자 환경에 가까운 결과를 얻을 수 있다.
6.2 시크릿 모드 사용
브라우저 확장 프로그램이 Performance 프로파일에 노이즈를 추가할 수 있다. 시크릿 모드에서 DevTools를 열고 분석하면 순수한 애플리케이션 성능만 측정할 수 있다.
6.3 반복 측정
한 번의 측정으로 결론을 내리지 말고, 최소 3회 이상 측정하여 일관된 패턴을 확인한다.
6.4 Preserve Log 활용
Network 탭의 "Preserve log"를 활성화하면 페이지 전환 시에도 네트워크 기록이 유지된다. 마이크로앱 전환 시의 네트워크 활동을 추적할 때 유용하다.
핵심 정리
- Performance 탭은 런타임 성능의 현미경이다: Lighthouse가 자동 감사라면, Performance 탭은 특정 구간의 함수 호출까지 추적하는 미시적 분석 도구다
- Main 섹션의 화염 차트가 핵심이다: 어떤 함수가 얼마나 오래 실행되었는지, Long Task가 어디서 발생하는지를 파악할 수 있다
- Long Tasks와 Layout Thrashing이 주요 병목 패턴이다: 50ms 이상의 메인 스레드 차단과 읽기/쓰기 교차 반복을 탐지하고 해결해야 한다
- Bottom-Up 분석으로 실제 병목 함수를 특정한다: Self Time 기준으로 정렬하면 가장 시간을 많이 소비하는 함수를 빠르게 찾을 수 있다
- 마이크로프론트엔드에서는 추가 분석 포인트가 있다: remoteEntry.js 워터폴, 라이브러리 중복 실행, 앱 전환 비용, 장애 전파를 반드시 확인해야 한다
다음 단계
- 다음: React DevTools 프로파일링 - React 컴포넌트 수준의 렌더링 성능 분석과 최적화 방법을 학습한다