런타임 성능은 페이지가 로드되는 것이 아니라 실행 중일 때 페이지의 성능을 나타냅니다. 이 튜토리얼에서는 Chrome DevTools 성능 패널을 사용하여 런타임 성능을 분석하는 방법을 설명합니다. RAIL 모델과 관련하여 이 가이드에서 배운 기술은 페이지의 응답, 애니메이션, 유휴 단계를 분석하는 데 유용합니다.
시작하기
이 튜토리얼에서는 라이브 페이지에서 DevTools를 열고 성능 패널을 사용하여 페이지에서 성능 병목 현상을 찾습니다.
- 시크릿 모드에서 Chrome을 엽니다. 시크릿 모드를 사용하면 Chrome이 깨끗한 상태에서 실행됩니다. 예를 들어 여러 확장 프로그램을 설치한 경우 이러한 확장 프로그램으로 인해 성능 측정에 노이즈가 발생할 수 있습니다.
시크릿 창에서 다음 페이지를 로드합니다. 이 데모는 프로파일링할 데모입니다. 페이지에 여러 개의 작은 파란색 사각형이 위아래로 움직입니다.
https://googlechrome.github.io/devtools-samples/jank/Command+Option+I (Mac) 또는 Control+Shift+I (Windows, Linux)를 눌러 DevTools를 엽니다.
그림 1. 데모(왼쪽), DevTools(오른쪽)
모바일 CPU 시뮬레이션
휴대기기는 데스크톱이나 노트북보다 CPU 성능이 훨씬 낮습니다. 페이지를 프로파일링할 때마다 CPU 제한을 사용하여 휴대기기에서의 페이지 성능을 시뮬레이션할 수 있습니다.
- DevTools에서 Performance 탭을 클릭합니다.
- 스크린샷 체크박스가 사용 설정되어 있는지 확인합니다.
- Capture Settings
를 클릭합니다.
DevTools에서 성능 측정항목을 캡처하는 방법과 관련된 설정을 표시합니다. CPU로 2x 속도 저하를 선택합니다. DevTools가 CPU를 제한하여 평소보다 2배 느리게 합니다.
그림 2. 파란색 윤곽선의 CPU 제한
데모 설정
이 웹사이트의 모든 독자에게 일관되게 작동하는 런타임 성능 데모를 만들기는 어렵습니다. 이 섹션에서는 특정 설정과 관계없이 환경이 이 튜토리얼에 표시되는 스크린샷 및 설명과 상대적으로 일치하도록 데모를 맞춤설정할 수 있습니다.
- 파란색 사각형이 전보다 크게 움직일 때까지 10 더하기를 계속 클릭합니다. 고급형 머신에서는 클릭이 20회 정도 필요할 수 있습니다.
최적화를 클릭합니다. 파란색 사각형은 더 빠르고 부드럽게 움직입니다.
최적화 해제를 클릭합니다. 파란색 사각형이 천천히 움직이고 다시 버벅거림이 더 많이 발생합니다.
런타임 성능 기록
페이지의 최적화된 버전을 실행하면 파란색 사각형이 더 빠르게 움직입니다. 이유가 무엇인가요? 두 버전은 동일한 시간 내에 각 정사각형을 동일한 공간만큼 이동해야 합니다. 성능 패널에서 기록을 진행하여 최적화되지 않은 버전에서 성능 병목 현상을 감지하는 방법을 알아보세요.
DevTools에서 Record
를 클릭합니다. DevTools는 페이지가 실행될 때 성능 측정항목을 캡처합니다.
그림 3: 페이지 프로파일링
몇 초 동안 기다립니다.
중지를 클릭합니다. DevTools가 기록을 중지하고 데이터를 처리한 후 Performance 패널에 결과를 표시합니다.
그림 4: 프로필 결과
어마어마한 양의 데이터가 될 겁니다. 걱정하지 마세요. 곧 모두 이해될 것입니다.
결과를 분석합니다.
페이지 성능에 관한 기록을 얻으면 페이지 성능이 얼마나 나쁜지 측정하고 원인을 찾을 수 있습니다.
초당 프레임 수 분석
애니메이션의 성능을 측정하는 기본 측정항목은 초당 프레임 수 (FPS)입니다. 사용자는 애니메이션이 60FPS로 실행될 때 만족합니다.
FPS 차트를 확인합니다. FPS 위에 빨간색 막대가 표시되면 프레임 속도가 너무 낮아서 사용자 환경에 유해할 수 있음을 의미합니다. 일반적으로 녹색 막대가 높을수록 FPS가 높습니다.
그림 5: 파란색 윤곽선의 FPS 차트
FPS 차트 아래에 CPU 차트가 있습니다. CPU 차트의 색상은 성능 패널 하단에 있는 요약 탭의 색상과 일치합니다. CPU 차트에 색상이 가득하다는 것은 기록 중에 CPU가 최대 한도에 도달했음을 의미합니다. CPU가 장시간 소진된 것을 볼 때마다 작업을 더 적은 방법을 찾는 신호입니다.
그림 6: 파란색 윤곽선으로 표시된 CPU 차트 및 요약 탭
FPS, CPU 또는 NET 차트 위로 마우스를 가져갑니다. 그러면 DevTools에서 해당 시점의 페이지 스크린샷을 표시합니다. 마우스를 좌우로 움직이면 녹화 내용을 다시 볼 수 있습니다. 이를 스크러빙이라고 하며 애니메이션의 진행 상황을 수동으로 분석하는 데 유용합니다.
그림 7: 기록의 2,000ms 부근에 위치한 페이지의 스크린샷 보기
프레임 섹션에서 녹색 사각형 중 하나 위로 마우스를 가져갑니다. DevTools는 해당 프레임의 FPS를 표시합니다. 각 프레임은 아마도 목표인 60FPS보다 훨씬 낮을 수 있습니다.
그림 8: 프레임 위로 마우스 오버
물론, 이 데모를 보면 페이지가 제대로 작동하지 않는 것이 분명합니다. 하지만 실제 시나리오에서는 그렇게 명확하지 않을 수 있으므로 이러한 모든 도구를 사용하여 측정하는 것이 유용합니다.
보너스: FPS 측정기 열기
또 다른 편리한 도구로는 페이지가 실행될 때 FPS의 실시간 추정치를 제공하는 FPS 측정기가 있습니다.
- Command+Shift+P (Mac) 또는 Control+Shift+P (Windows, Linux)를 눌러 Command 메뉴를 엽니다.
- 명령 메뉴에
Rendering을 입력하고 렌더링 표시를 선택합니다. 렌더링 탭에서 FPS 측정기를 사용 설정합니다. 표시 영역의 오른쪽 상단에 새 오버레이가 나타납니다.
그림 9: FPS 측정기
FPS 측정기를 사용 중지하고 Esc 키를 눌러 렌더링 탭을 닫습니다. 이 튜토리얼에서는 사용하지 않습니다.
병목 현상 찾기
애니메이션이 잘 작동하지 않는지 측정하고 확인했으므로 이제 답은 그 이유는 무엇일까요?
요약 탭을 확인합니다. 이벤트를 선택하지 않으면 이 탭에 활동 분석이 표시됩니다. 페이지 렌더링에 대부분의 시간을 사용했습니다. 성능은 작업을 줄이는 기술이므로 목표는 렌더링 작업에 소요되는 시간을 줄이는 것입니다.
그림 10: 파란색 윤곽선으로 표시된 요약 탭
Main 섹션을 펼칩니다. DevTools에서 기본 스레드의 활동 Flame Chart를 시간 경과에 따라 확인할 수 있습니다. X축은 시간 경과에 따른 기록을 나타냅니다. 각각의 막대는 이벤트를 나타냅니다. 막대가 넓을수록 이벤트가 더 오래 걸렸음을 의미합니다. y축은 호출 스택을 나타냅니다. 이벤트가 서로 쌓여 있다면 상위 이벤트로 인해 하위 이벤트가 발생했다는 의미입니다.
그림 11: 파란색 윤곽선의 기본 섹션
녹음에 데이터가 많습니다. FPS, CPU, NET 차트가 포함된 섹션인 개요 위로 마우스를 클릭한 상태로 드래그하여 단일 Animation Frame Fired 이벤트를 확대합니다. Main 섹션과 Summary 탭에는 선택한 기록 부분에 관한 정보만 표시됩니다.
그림 12: 단일 애니메이션 프레임 실행 이벤트에서 확대
Animation Frame Fired(애니메이션 프레임 실행됨) 이벤트의 오른쪽 상단에 있는 빨간색 삼각형을 확인합니다. 빨간색 삼각형이 표시될 때마다 이는 이 이벤트와 관련된 문제가 있을 수 있다는 경고입니다.
Animation Frame Fired(애니메이션 프레임 실행됨) 이벤트를 클릭합니다. 이제 요약 탭에 해당 이벤트에 대한 정보가 표시됩니다. reveal 링크를 확인합니다. 클릭하면 DevTools에서 Animation Frame Fired 이벤트를 시작한 이벤트가 강조표시됩니다. app.js:94 링크도 참고하세요. 클릭하면 소스 코드의 관련 줄로 이동합니다.
그림 13: 애니메이션 프레임 실행 이벤트에 대한 추가 정보
app.update 이벤트 아래에 보라색 이벤트가 여러 개 있습니다. 폭이 더 넓으면 각 막대에 빨간 삼각형이 있는 것처럼 보입니다. 이제 보라색 레이아웃 이벤트 중 하나를 클릭합니다. DevTools의 Summary 탭에서 이벤트에 대한 자세한 정보를 확인할 수 있습니다. 실제로 강제 리플로우 (레이아웃의 다른 단어)에 관한 경고가 있습니다.
요약 탭의 레이아웃 강제 사용에서 app.js:70 링크를 클릭합니다. DevTools에서 레이아웃을 강제한 코드 줄로 이동합니다.
그림 13: 강제 레이아웃을 일으킨 코드 줄
휴! 많은 내용을 다룰 수 있었지만, 이제 런타임 성능 분석을 위한 기본 워크플로의 탄탄한 기반을 마련할 수 있었습니다. 수고하셨습니다.
보너스: 최적화된 버전 분석
방금 배운 워크플로와 도구를 사용하여 데모에서 최적화를 클릭하여 최적화된 코드를 사용 설정하고 다시 성능 기록을 수행한 후 결과를 분석합니다. 프레임 속도 개선부터 Main 섹션의 Flame Chart의 이벤트 감소에 이르기까지 최적화된 버전의 앱이 훨씬 적은 작업을 실행하여 성능이 향상된 것을 확인할 수 있습니다.
다음 단계
성능을 이해하기 위한 기반은 RAIL 모델입니다. 이 모델은 사용자에게 가장 중요한 성능 측정항목을 알려줍니다. 자세한 내용은 RAIL 모델로 성능 측정을 참조하세요.
Performance(성능) 패널에 더 익숙해지려면 연습이 완벽합니다. 자신의 페이지를 프로파일링하고
결과를 분석해 보세요. 결과에 대해 궁금한 점이 있으면 google-chrome-devtools 태그가 지정된 Stack Overflow 질문을 여세요. 가능하면 스크린샷이나 재현 가능한 페이지의 링크를 포함하세요.
런타임 성능의 전문가가 되려면 브라우저에서 HTML, CSS, JS를 화면의 픽셀로 변환하는 방법을 알아야 합니다. 렌더링 성능 개요부터 시작하는 것이 가장 좋습니다. 자세한 내용은 프레임 분석을 참조하세요.
마지막으로, 런타임 성능을 개선하는 다양한 방법이 있습니다. 이 튜토리얼에서는 특정 애니메이션 병목 현상을 집중적으로 다루어 성능 패널을 통해 둘러보기를 집중적으로 안내하지만 이는 발생할 수 있는 여러 병목 현상 중 하나일 뿐입니다. 렌더링 성능 시리즈의 나머지 부분에는 다음과 같이 런타임 성능의 다양한 측면을 개선하기 위한 유용한 팁이 많이 있습니다.