안녕하세요. IMQA 개발팀 남상우 선임연구원입니다.
IMQA에서는 네이티브, 웹뷰, 하이브리드 앱 모두 성능 모니터링이 가능한데요. 이 중 성능 이슈가 많은 부분은 단연 웹뷰입니다.
IMQA는 모든 성능 데이터를 수집, 모니터링하고 있는데요. IMQA에서 수집된 많은 웹뷰 데이터를 IMQA의 전문 컨설턴트의 컨설팅처럼 정확하게 분석할 수 있도록 도움을 드리면 좋겠다고 생각했습니다. 그래서 실제 성능 컨설팅 방법을 기반으로 웹뷰 성능 개선이 필요한 부분을 어떻게 찾고, 추적해야 하는지 정리해 보았습니다.
이번 IMQA로 웹뷰 성능을 추적하는 포스팅으로 조금이나마 사용자에게 도움이 되었으면 좋겠습니다.
Step 1. 문제 상황 확인하기
앱의 성능 현황은 어떻게 파악할 수 있을까요? 전체 성능 현황을 가장 쉽게 파악하는 방법은 바로 MPM의 보고서 기능을 활용하는 것입니다. 보고서의 항목별로 데이터를 읽 어 보면, 쉽게 성능 현황을 파악할 수 있을 뿐만 아니라 문제 상황도 찾을 수 있습니다.
보고서 분석하기
보고서에서는 화면 로딩시간의 구간별 비율부터, 웹뷰 화면로딩시간 하위 20개의 페이지까지 항목별로 일일 성능 현황을 상세히 확인하실 수 있습니다.
* 보고서 기능에 대한 내용은 다음 포스팅에서 자세히 확인하실 수 있습니다.
[보고서] 메뉴에서 확인이 필요한 버전의 날짜를 선택하고 [적용] 버튼을 누르면 아래와 같은 리포트를 받을 수 있는데요. 아래 예시 보고서를 통해 데이터를 읽고, 성능 현황을 파악해 보겠습니다.
- 네이티브 화면 로딩시간은 빠른 편입니다. 100ms 안에 대부분 로딩시간이 끝납니다.
- 웹뷰 화면 로딩시간을 보면 42.553%의 사용자가 1,000~3,000ms간의 시간 동안 화면이 나타나길 기다리고 있습니다. 웹뷰에서 사용자가 3초간 기다리고 있다는 이야기가 됩니다. 개선이 필요합니다.
- 응답시간은 1초 이내에 응답하는 비율이 98%입니다. 아주 양호하네요.
- CPU와 메모리는 옅은 회색 박스(기준치) 보다 낮으니 크게 걱정할 부분은 없습니다.
전체적으로 보았을 때 해당 서비스는 응답시간보다 웹뷰 자체에서 화면 로딩하는 시간이 느리다는 것을 확인할 수 있습니다.
웹뷰 화면 로딩시간 분석
아래로 스크롤을 내려 보시면 [웹뷰 화면 로딩시간 하위 20] 데이터를 보여주는 표를 확인할 수 있습니다. 화면과 페이지는 아래와 같이 정의할 수 있습니다.
- 화면: 네이티브 액티비티
- 페이지: 네이티브 액티비티에 연결된 웹뷰 페이지
여기서 P95(하위 5%)와 평균이 동일하면 1건의 수집만 발생한 것이니 특정 상황*이라고 볼 수 있습니다.
(특정 상황은 사용자의 환경에서 인터넷이 느렸거나 앱 충돌 등 여러 이유로 문제가 되어 데이터가 느리게 수집될 수 있는 경우입니다.)
앞서 보고서에서 발견한 느린 웹뷰를 찾아야하기에 표에서 중복으로 발견되고, 평균과 P95가 다른 데이터들이 있습니다. 표에서는 중복적인 페이지들이 보입니다.
로그인, 회원가입 관련 화면과 상품 쪽 관련 화면이 많이 수집되었네요. 문제가 되는 화면 위주로 데이터를 체크해야 한단 걸 확인할 수 있습니다.
응답시간 분석
아래로 조금 더 스크롤을 내려보시면 응답시간도 체크할 수 있습니다.
해당 앱 버전은 응답시간에 대한 문제가 크게 부각되지 않았지만, 아래 표를 보면 부분적으로 느린 API가 수집되는 걸 확인할 수 있습니다.
여기서 화면로딩에 영향을 주는 API가 발견되기도합니다. API 요청 후 응답받은 값을 기준으로 화면을 그려주는 형태로 개발이 되었다면, API 속도가 느리면 화면로딩시간에도 영향을 줄 수도 있습니다.
저는 보고서에서 제품과 관련된 하위 20개의 API가 수집되어 API 동작 후 화면 랜더링에 영향을 줄 것 같다는 예상을 하고 데이터를 좀 더 확인 해야 할 것 같았습니다.
Step 2. 문제 상세 확인하기
우선 지금까지 [보고서] 메뉴에서 예상한 내용을 정리해 보겠습니다. 우리가 예상한 이슈 화면은 로그인, 회원가입, 상품 페이지입니다.
그리고 영향을 끼칠 수도 있는 API는 제품 쪽과 관련된 API입니다.
해당 앱 버전에 대한 전체적인 분석을 하였으니 이제 디테일하게 예상된 케이스들을 확인을 해야합니다. 화면을 기준으로 분석해야 하는데요. 아까 이슈가 있던 화면 중 상품 관련 페이지를 확인해 보겠습니다.
대시보드 실시간으로 확인
[대시보드] 메뉴로 진입하면 화면별 성능 현황을 확인할 수 있습니다. 대시보드는 30분간의 데이터를 실시간으로 보여줍니다.
보고서에서 수집된 데이터들이 해당 앱 버전의 문제일 때, 30분간의 데이터에서도 동일한 문제가 확인되면 현재도 관련 화면이 문제라고 예상할 수 있습니다.
[대시보드] 화면별 성능 현황에서 상품 상세 화면이 보이네요. 상품 상세 화면 카드를 클릭하면 해당 화면을 기준으로 상세한 상황을 볼 수 있습니다.
화면 성능 분석과 성능 상세 분석 페이지에 대한 기능 및 사용법은 아래 포스팅에서 확인하실 수 있습니다.
히트맵 파악하기
화면 상세 분석 페이지에서는 6가지의 히트맵을 볼 수 있습니다. 네이티브의 로딩시간, 응답시간과 웹뷰의 로딩시간, 응답시간 그리고 CPU, 메모리의 히트맵을 확인할 수 있는데요.
네이티브, 웹뷰 각자만의 이슈만 히트맵에 표현이 될 수도 있지만 히트맵 간에 데이터들이 엮여서 문제가 발생하는 경우를 파악할 수 있습니다.
우리가 확인해 본 앱 버전의 보고서에서는 웹뷰 쪽이 문제이기 때문에 웹뷰 쪽 히트맵인 웹뷰 로딩시간과 웹뷰 응답시간을 확인해야 합니다. 아래 이미지와 같이 동일 시간에 응답시간과 로딩시간이 같이 문제가 발생한 것을 볼 수 있습니다.
두 히트맵을 비교해서 보면 응답시간으로 인하여 로딩시간에 영향을 끼쳤다는 걸 알 수 있습니다. 화면 로딩시간이 느리고 응답시간이 느린 것을 따로 볼 수도 있지만 이렇게 같은 시간대에 함께 히트맵이 튀어 오른다면 두 데이터간에 연관성이 있을 수도 있습니다.
응답시간의 빨간박스안에 히트맵을 클릭 혹은 드래그하게 되면 아래와 같은 상세 팝업창이 뜨게 됩니다.
Step 3. 상세 원인 파악하기
문제가 있는 부분을 찾았다면 이제 히트맵의 상세 페이지에서 정확한 원인을 찾아야 합니다.
웹뷰 응답시간 상세 팝업창
클릭 혹은 드래그한 히트맵에 대한 수집된 화면 데이터를 상세 팝업창에서 확인할 수 있습니다.
해당 화면에서 수집된 API를 확인할 수 있습니다. 이 API는 보고서에서 하위 20개 안에 문제가 되었던 API인데요. 이 API가 화면 로딩시간에서도 문제가 되는지 확인이 필요했습니다.
웹뷰 화면로딩시간 상세 팝업창
화면 로딩시간 히트맵을 클릭 혹은 드래그하여 상세 팝업에서 수집된 데이터를 확인해 보면 아래와 같은 데이터를 볼 수 있습니다.
해당 화면에 같은 기종(디바이스)의 사용자 데이터를 볼 수 있었으며, 해당 화면에 대한 타임라인 기준의 데이터를 아래에서 확인할 수 있습니다. 여기서 수집된 데이터들은 화면에서 어떤 리소스를 불러오는지, 어떤 API를 요청하는지 확인이 가능합니다.
이미지를 자세히 보시면 웹뷰 응답시간에서 수집된 API를 확인하실 수 있습니다. 타임라인에 대한 자세한 내용은 추후 포스팅될 예정입니다. (조금만 기다려 주세요!)
웹 페이지 성능 개선을 다룬 영상과 자료 및 이전에 발행한 화면 성능 저하의 주요 원인과 개선 방법에 대해 정리한 내용도 안내해 드립니다. 함께 확인해 보세요!
