크롬 개발자 도구의 Performance 탭 다루기 - 기본편

이 글은 아래 링크의 글을 바탕으로 작성되었습니다. 당연하지만, 이 글이 웹 프론트엔드 성능 분석의 모든 것을 담고 있는 것은 아닙니다. 하지만 가장 기본이 되는 방법론을 다루고 있습니다.

 

시작해요, 런타임 성능 분석 | Chrome DevTools | Google Developers

시작해요, 런타임 성능 분석  |  Chrome DevTools  |  Google Developers

 

 

Network 패널 or Performance 패널

 

네트워크 패널은 자원들이 제대로 다운로드 되었는지의 여부, 캐시여부, 그리고 다운로드된 자원들의 다운로드에 걸린 시간, 세부 정보들을 보고 싶을 때 유용하게 사용할 수 있는 패널입니다. 만일 초기 렌더링 속도, 애니메이션 속도, 응답 대기 시간 등을 개선하고 싶다면 Network 패널보다는 Performance 패널을 활용하는게 더 현명합니다.

*참고로 성능분석을 실시할 때는 시크릿 모드에서 수행하는 것이 좋습니다. 어떠한 기본 캐시 없이 깨끗한 상태에서 작업을 진행할 수 있기 때문입니다. 다만 브라우저에 확장프로그램이 많이 깔린 상태라면 작업에 영향이 갈 수 있으니 이들을 모두 삭제하기를 권장합니다.

 

 

 

모바일 CPU 시뮬레이션

 

Performance 패널의 설정 아이콘을 클릭해서 CPU 성능을 2배 정도 낮추면 모바일 CPU 와 비슷한 환경으로 만들 수 있습니다.

 

 

 

페이지 녹화 후 성능 분석 데이터 보기

 

성능 분석은 웹 페이지가 동작하고 있을 때 자동으로 되는 것이 아니라 특정 구간을 녹화한 후 그 구간을 분석해서 수행하는 식으로 이루어집니다. 따라서 초기 렌더링 성능을 분석하고 싶다면 웹페이지를 불러오기 전에 녹화 버튼을 누르거나 새로고침 버튼을 누르면 됩니다.

 

 

약 2 ~ 3초 정도의 기간을 녹화하고 stop 을 누릅니다.

 

 

이렇게 하면 어마무시한 양의 데이터를 볼 수 있을 것입니다. 지레 겁먹기 보다는 하나하나 차근차근 분석해나가면 됩니다.

 

 

 

초당 프레임 수 분석

 

애니메이션을 비롯해서, 이용자가 '편안하고 빠른 어플리케이션'이라는 것을 체감하기 위해서는 화면의 초당 프레임 수(FPS)가 높은 것이 필수 입니다. 사용자들은 보통 웹이 60FPS 이상으로 동작할 때 부드러움과 빠른 동작을 체감할 수 있습니다. 따라서 초당 프레임 수를 60FPS 이상으로 유지시키는 것이 중요합니다.

 

 

가장 위에 위치한 빨간 막대와 초록색 바가 초당 FPS 를 나타냅니다. 빨간 색 바가 보인다면 FPS 가 너무 낮아서 사용자가 불편을 느낄 수 있음을 의미합니다. 녹색 막대가 위에 위치할 수록 높은 FPS가 잘 분포하고 있음을 알 수 있습니다.

 

 

바로 아래 부분은 CPU 사용량 분포를 나타냅니다. 주황, 보라, 초록 등 색상으로 뒤섞인 바가 크고 높게 보일 수록, CPU를 많이 사용하고 있다는 것이고, 그만큼 성능이 좋지 않다는 것을 의미합니다. 하단에 위치한 원형 그래프를 보면 같은 색상들이 분포되어 있음을 알 수 있습니다. 원형 그래프 자체는 전체 연산 시간에서 scripting, rendering, painting, 기타 항목들이 얼만큼 처리 시간을 가졌는지를 보여주지만 거기서 나오는 색상들은 CPU 사용량의 분포를 파악하는데에도 활용될 수 있습니다. 예를 들어 주황색이 보라색 위에 있으므로 스크립팅이 렌더링보다 더 많은 CPU 를 사용하게 됨을 알수 있습니다.

 

 

분포에 직접 마우스를 가져다 대면 그 시점에서의 화면을 보여줍니다. 마우스를 움직여 보면서 애니메이션이 어떻게 흘러가는지를 수동으로 관찰할 수 있고, 이를 scrubbing 이라고 부릅니다.

 

 

바로 아래쪽 하단의 녹색 사각형들의 수평 분포를 확인할 수 있을 텐데, 거기서 실제 FPS 수치를 확인할 수 있습니다.

 

 

 

병목지점 확인하기

 

 

이제 이 패널을 개괄적으로 볼 수 있는 눈을 가졌으니 본격적으로 성능 분석의 첫 단추를 꿰어봅시다. 역시 가장 먼저 할 일은 가장 처리가 오래걸리는 일의 시간을 줄이는 것입니다. 이는 위에서 말씀드린 원형 차트에서 바로 확인할 수 있습니다. 차트를 보면 렌더링에 가장 많은 처리 시간이 걸리고 있음을 확인할 수 있습니다. 이렇게 처리 시간이 많은 것부터 차례차례 최적화해나가면 됩니다.

 

 

이제 이렇게 목표를 세운 상태에서 더 세밀하게 파고들어 봅시다. 분석하고 싶은 지점을 마우스 휠이나 막대를 옮겨 좁히고 하단의 main 섹션을 확장해보십시오. 확장했을 때 나오는 차트를 flame 차트라고 부르며, x 축은 시간을, y 축으로 쌓인 막대들은 콜스택을 시각적으로 보여줍니다.

 

 

정말 많은 이벤트들이 있겠지만, 가장 최상단에 위치한 이벤트 막대 중 'Animation Frame Fired' 를 찾아서 클릭해 보십시오. 그리고 원형 차트가 위치했던 summary 탭이 갱신되면 'reveal' 이라 표시된 링크를 클릭하십시오. 이를 통해 정확히 어느 위치의 어떤 코드가 해당 이벤트를 발생시키는지를 추적할 수 있습니다.

 

*성능분석에 숙련되지 않으신 분들은 애초에 이런 이벤트들 자체가 생소한 경우가 많을 것입니다. 애초에 이 글을 쓰고 있는 저도 그렇습니다...이벤트를 이해할 때는 다음의 링크를 참조하시면 도움이 될 것입니다.

 

타임라인 이벤트 참조 | Chrome DevTools | Google Developers

타임라인 이벤트 참조  |  Chrome DevTools  |  Google Developers

 

 

이제 콜스택을 추적하다보면 정확히 어느 함수의 어느 행이 문제를 발생시키는지를 알수 있습니다.

 

 

잘 보면 어느 요소의 style 의 top 속성을 수정하는 코드가 다른 코드들과 비교해서 엄청나게 많은 시간을 잡아먹고 있음을 알 수가 있습니다. 이전에도 말했듯, top 과 같이 요소의 기하학적인 영향을 주는 css 속성을 변경하는 것은 강제 레이아웃을 발생시키기 때문에 이렇게 많은 시간을 잡아먹는 것임을 쉽게 알 수 있습니다.

 

그렇다면 정.확.히 어떻게 코드를 고쳐야 저런 코드를 더 나은 방향으로 고칠 수 있을까요? 그 부분은 후에 '렌더링 성능 최적화'에서 다뤄보도록 하겠습니다.