메뉴 건너뛰기

3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자


크래시율과 더불어 app load time은 매우 중요한 지표입니다. App load time은 고객유치에 매우 밀접한 메트릭이자 모바일 앱에 접근하는 중요한 시간정보입니다. 연구에 따르면 app load time은 50%의 사용자에게 당혹감을 줄 수 있으며 25%의 사용자는 너무 긴 app load time으로 인해 앱을 사용하지 않게 된다고 합니다.


Apteligent를 사용하여 App Load Time을 자동으로 관리하자


여러 고객들에게 메트릭의 중요성에 대해 충분히 설명하면서, Apteligent는 앱 로드 타임을 추가 코드 설정 없이 나타나는 기본 메트릭으로 제공하기로 했습니다. Apteligent SDK를 이니셜라이징 하는 것만으로도 사용자가 앱 아이콘을 눌러 런칭하는 순간부터 사용자가 사용할 수 있도록 로드되는 시간을 모니터하는 것입니다.


3-1.png


Userflows Summary페이지에서는 App Load라는 userflow가 여러분이 설정한 custom flow와 함께 나타나는 것을 확인할 수 있습니다. Apteligent는 항상 사용자가 app을 로드하는 것을 자동적으로 모니터링하여 다음과 같은 주요 메트릭을 수집합니다.


 Volume: app을 로드하는 횟수
 Foreground Time : app을 로드하는 데에 걸리는 시간
 Fail Rate : app이 로드되는 동안 크래시가 발생하는 비율


app 릴리즈와 시간대 별로 메트릭 값 변화의 추이를 비교하고 업계 평균 메트릭과 비교하는 benchmark에서 유용하게 사용될 수 있는 메트릭입니다. Apteligent data에 따르면 좋은 앱은 다음과 같은 app load 메트릭을 보여줍니다.


 Foreground time < 2.0 sec
 Fail rate < 0.25 %


Distribution of Apps by Appload Time (ms)


3-2.png


만일 app load time이 2초가 넘거나 0.25%이상의 크래시율이 나타난다면, App Load userflow를 클릭하여 이슈를 해결하시기 바랍니다.


시간의 흐름과 릴리즈에 유의하여 AppLoad 메트릭을 관리하자


App load 상세 페이지의 상단 차트를 보면 시간 흐름에 따른 메트릭 변화를 볼 수 있습니다. 크래시에 의한 실패 율이나 타임아웃은 새로운 앱 릴리즈, OS릴리즈, 서버 측의 변경에 따라 증가 하기도 합니다. 페이지 상단의 필터를 사용하면 특정 앱 버전 또는 기간에 따른 차트를 볼 수 있습니다.


3-3.png


Breadcrumbs 을 사용하여 실패한 Userflow, 느린 Userflow를 디버깅하자


Userflow의 이슈를 보다 더 깊이 분석하기 위해 userflow 상세 페이지에서는 느리거나 실패한 userflow 의 원인을 파악할 수 있는 두 가지 탭을 제공합니다.


Breadcrumbs탭은 실패한 개별 사용자 세션을 보여줍니다. 이 탭의 시간 흐름에 따른 축적 데이터를 보고 느린 앱로드 시간과 크래시의 원인을 파악할 수 있습니다.


3-4.png



Apteligent는 크래시가 있거나 타임아웃 시간을 초과하는 경우 자동으로 Userflow를 실패로 표시합니다. 실패한 각 세션에 대해 Apteligent에서는 실패로 이어지는 마지막 100개의 이벤트 목록을 표시합니다. 자동 탐색 경로를 통해 Apteligent SDK는 느린 네트워크 호출, 네트워크 연결 변경 및 화면 전환과 같은 일반적인 실패 원인 및 앱 지연현상을 자동으로 추적합니다.

앱로드 시간이 느려지는 원인은 앱마다 다르지만 일반적으로 우리가 경험한 바에 의하면 미디어 자원이나 검색결과를 로드하는 API가 느리거나 써드파티 SDK의 초기화가 느린 것이 주요 원인이었습니다. 또한 때때로 코드가 원인일 수도 있습니다. 그림 7와 같이 앱이 다운될 때까지 동일한 Activity가 2초마다 로드되는 무한루프를 볼 수 있습니다


Bonus Tip


App load userflow에 타임아웃을 120초로 걸어 놓으면 2분 이상 걸리는 app load 수를 측정할 수 있습니다. 여러분의 앱이 평균적인 앱과 대비해 앱 로드에 얼마나 걸리는지 비교해보고, 느린 앱 로드를 자동 브래드크럼 추적 기능을 이용하여 분석하십시오.


3-5.png


3-6.png


App Load 동안 발생하는 Crash를 우선적으로 디버깅하자


앱의 주요 userflow 에서 크래시가 발생하면 사용자 경험과 유치 측면에서 악영향을 줄 수 있습니다. 그리고 가장 중요한 userflow 중 하나는 앱 로드일 것입니다. 앱 실행 중에 크래시가 발생하면 앱을 사용할 수 없습니다.


Root Cause Analysis 탭을 사용하면 앱이 로드되는 동안 발생한 모든 크래시를 확인할 수 있습니다. 성공적인 다음 릴리즈를 위해 크래시의 우선순위를 정하여 픽스합니다.

3-7.png


요약해보면


요약해보면 app load는 사용자가 앱을 처음 사용하기 위한 단계로 좋은 첫인상을 주어야 하는 시점입니다. 여러분의 앱을 사용하는 사용자를 위해 앱 로드 시간을 일반적인 평균치인 2초 미만, 0.25%이하의 크래시율을 유지하십시오. Apteligent userflow기능은 모든 앱 릴리즈에 대해 시간별로 위의 두 메트릭을 제공합니다. 느린 앱 로드 시간을 수정하고 breadcrumb 추적을 통해 느린 네트워크 콜과 같은 문제점을 특정지을 수 있습니다. 마지막으로 root cause analysis툴을 사용하여 load시 발생하는 크래시의 우선순위를 정해 해결합니다.


앱 로드는 앱의 주요 userflow 중 하나입니다. 이 외에도 로그인, 새 계정 등록, 구매 등 중요한 userflow가 있을 수 있습니다. 다음 장에서는 성능이슈를 어떻게 측정하고 모니터링 하며 해결할 수 있는지에 대해 알아보겠습니다.

Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

?

 


  1. 3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자

    3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자 크래시율과 더불어 app load time은 매우 중요한 지표입니다. App load time은 고객유치에 매우 밀접한 메트릭이자 모바일 앱에 접근하는 중요한 시간정보입니다. 연구에 따르면 app load time은 50%의 ...
    Date2018.02.19 ByNeO Reply0 Views585
    Read More
  2. 2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자

    2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자 앞서 Best Practice #1의 방법으로 top 10 크래시를 수정한다면, 0.25% 이하의 크래시율을 유지하는 데에 매우 큰 도움이 될 것입니다. 전체 크래시율을 낮추는 것 외에도 주요 Userflow의 크래시...
    Date2018.02.05 ByNeO Reply0 Views443
    Read More
  3. 1. 매 스프린트에서 Top 10 크래시를 잡자

    1. 매 스프린트에서 Top 10 크래시를 잡자 모바일 앱을 모니터링할 때 가장 중요한 지표 중 하나는 전체 크래시율입니다. 크래시율이란 전체 세션 대비 크래시가 발생한 비율을 의미합니다. 앱의 품질을 평가하는 데에 크래시율은 전체 릴리즈 프로세스에...
    Date2018.01.30 ByNeO Reply0 Views508
    Read More
  4. No Image

    모바일앱 최적화를 위한 7가지 (0)

    본 문서는 다음 문서를 번역한 글입니다. http://www.apteligent.com/white_paper/7-best-practices-optimizing-mobile-app-experience/ 이 문서를 게시하기 전에 모바일앱 모니터링 툴의 종류와 특성에 대한 개요를 작성하고자 하였으나, 많은  mAPM이나 ...
    Date2018.01.29 ByNeO Reply0 Views375
    Read More
  5. Is NoOps the End of DevOps? Think Again (2) 결론

    In conclusion, DevOps is forever DevOps의 완성형이라고 일컬어짐에도 불구하고 NoOps는 DevOps의 종착역은 아닙니다. 사실 NoOps는 DevOps를 통해 달성할 수 있는 혁신의 시작이라고 볼 수 있습니다. DevOps가 이름을 갖기 훨씬 전부터 시작된 NoOps...
    Date2018.01.02 ByNeO Reply0 Views343
    Read More
  6. Is NoOps the End of DevOps? Think Again (1) DevOps가 사라지지 않는 7가지 이유

     7 Reasons DevOps Is Not Dying 이제 DevOps의 시작에 대해 알았으니 본래의 질문으로 돌아가봅시다. NoOps가 DevOps의 종착역일까요? 그렇지 않습니다!  1. DevOps is a journey 어떤 Devopsdays에 참석하더라도 “DevOps is a jo...
    Date2018.01.02 ByNeO Reply0 Views398
    Read More
  7. Is NoOps the End of DevOps? Think Again (0) IT Operation, DevOps, NoOps 의 간략한 역사

    이 문서는 다음 링크의 글을 일부 번역했습니다. https://blog.appdynamics.com/engineering/is-noops-the-end-of-devops-think-again/ 제일 앞 부분의 DevOps와 NoOps 운동에 대한 논란은 관심있으신 분은 직접 링크를 따라가며 읽어보시면 좋을 것 같습...
    Date2018.01.02 ByNeO Reply0 Views496
    Read More
  8. Monoliths - Module, Allocation, Runtime Monolith

    이 문서는 다음 링크의 글을 번역했습니다. http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html 모노리스와 대비하여 마이크로서비스를 이야기하는 강한 트렌드가 있습니다. 그리고 모노리스를 마이크로서비스로 나누는 방법에 대...
    Date2017.12.13 ByNeO Reply0 Views628
    Read More
  9. No Image

    Microservices, Monoliths and Self-Contained Systems (3) Self-contained system과 결론

    Self-Contained System Self contained system은 모노리스와 마이크로서비스 중간쯤에 있는 블록형 아키텍처입니다. 여러 개의 마이크로서비스를 하나의 엔티티로 나타내면서도 모노리스보다는 작은 규모를 가지는 형태입니다. 만일 매우 연관성이 높아 ...
    Date2017.12.13 ByNeO Reply0 Views492
    Read More
  10. No Image

    Microservices, Monoliths and Self-Contained Systems (2) Microservices

    Microservices 상대적으로 마이크로서비스는 많은 장점을 가져다 주는 반면 단점이 적은 편입니다. 마이크로서비스는 커다란 어플리케이션의 일부분이라고 할 수 있으며 독립적인 어플리케이션이라고 할 수 있겠습니다. 예를 들어 웹 상에 스토어를 운영...
    Date2017.12.13 ByNeO Reply0 Views257
    Read More
Board Pagination Prev 1 2 3 Next
/ 3