랩
이 절차는 New Relic 브라우저 모니터링으로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다.
랩의 각 절차는 마지막 절차를 기반으로 하므로 이 절차를 시작하기 전에 마지막 절차 인 애플리케이션의 오류 디버그 를완료했는지 확인하십시오.
애플리케이션에서 JavaScript 오류를 수정한 후 귀하와 귀하의 팀은 자신감을 느낍니다. 다운 타임을 준비하고 소셜 미디어로 이동하지만 Twitter를 확인하고 혼란스러워하는 고객을 봅니다.
어 오! 고객이 행복해 보이지 않습니다. 지연의 원인을 찾기 위해 New Relic 브라우저 모니터링을 사용할 때입니다.
애플리케이션의 속도 저하 디버그
New Relic 홈페이지에서 Browser 로 이동하여 Relicstaurants 애플리케이션을 선택합니다.
여기에서 Page views with JavaScript errors[JavaScript 오류가 있는 페이지 보기], Core web vitals[핵심 웹 바이탈], User time on the site[사이트의 사용자 시간], Initial page load and route changes[초기 페이지 로드 및 경로 변경]등을 포함하여 브라우저 애플리케이션과 관련된 모든 데이터를 볼 수 있습니다.
LCP(Largest Contentful Paint)에 주목하십시오.
LCP(Largest Contentful Paint)는 웹 페이지의 기본 콘텐츠가 로드되는 속도를 나타냅니다. 이상적으로는 콘텐츠를 로드하는 데 1-2초 이상 걸리지 않아야 합니다. 여기에서 사이트가 5초 이상 로드되는 것을 볼 수 있습니다. 사용자가 불평하는 것도 당연합니다!
하지만 이 지연의 원인은 무엇입니까? 백엔드?
아래로 스크롤하여 Front end vs. back end[프런트 엔드 대 백엔드] 그래프를 확인합니다.
Back end (time to first byte) (50%)를 클릭하여 그래프를 필터링하고 백엔드가 로드되는 데 걸리는 시간을 확인합니다.
그래프는 백엔드가 최악의 경우 요청을 처리하는 데 최대 140밀리초가 걸렸음을 나타냅니다. 이것은 프런트 엔드가 지연을 유발한다는 것을 의미합니까?
프런트 엔드(창 로드 + AJAX)(50%)를클릭합니다.
문제가 있습니다! 그래프는 프런트 엔드에서 지연이 발생하고 있음을 나타냅니다.
프런트 엔드 지연의 원인을 좁히려면 Initial page load and route change[초기 페이지 로드 및 경로 변경] 그래프를 자세히 살펴보십시오.
Initial page load (Window load + AJAX)[초기 페이지 로드(창 로드 + AJAX)]를클릭합니다.
그래프는 Initial page load (Window load + AJAX)[초기 페이지 로드(Window 로드 + AJAX)] 가 5-6초 걸리는 것을 나타냅니다.
자세한 내용을 보려면 Initial page load and route change[초기 페이지 로드 및 경로 변경을] 클릭하십시오.
그러면 Page views[페이지 보기]로 이동합니다.
Most time-consuming[가장 시간이 많이 소요되는] 페이지를 기준으로 페이지를 정렬합니다.
초기 페이지를 로드하는 데 거의 90%의 시간이 걸립니다.
그것을 클릭하면 세부 정보를 볼 수 있습니다.
이 페이지는 Page view breakdown[페이지 조회수 분석], Median initial page load time[중간 초기 페이지 로드 시간] 및 기타 중요한 세부 정보를 보여줍니다. Page view breakdown[페이지 보기 분석] 그래프는 페이지가 더 오래 걸리는 이유와 위치를 좁히는 데 도움이 되므로 여기에서 특히 중요합니다. 이 그래프를 자세히 살펴보면 Page rendering[페이지 렌더링이] 5000밀리초만큼 오래 걸리는 것을 볼 수 있습니다.
이제 초기 페이지를 렌더링하는 데 시간이 오래 걸리므로 응용 프로그램이 느려지는 것을 알 수 있습니다. 다음으로 Session traces[세션 추적을] 관찰하여 무엇이 렌더링 프로세스를 느리게 하는지 파악합니다.
오른쪽 상단 모서리에 있는 X를 클릭하여 이 보기를 종료합니다.
왼쪽 탐색에서 Session traces[세션 추적] 으로 이동하여 Page load[페이지 로드]내림차순으로 정렬합니다.
여기에서 Page load[페이지 로드] 시간 순서로 정렬된 세션 추적을 볼 수 있습니다.
목록에서 첫 번째 항목을 클릭합니다.
이렇게 하면 Session traces[세션 추적] 세부 정보 페이지로 이동합니다.
여기에서 특정 세션에 대한 전체 추적을 볼 수 있습니다. 이 페이지에는 Backend, Dom Processing, Page Load및 기타 추적 관련 정보도 표시됩니다.
Page load[페이지 로드가] 예상보다 오래 걸립니다. 로드에 대한 자세한 타임라인이 필요합니다. 좌우의 포인터를 스크롤하여 타임라인을 조정합니다.
추적을 스크롤하여 시간 창을 이동하고 이 세션 동안 개별 이벤트의 세부 정보를 확인합니다.
특정 이벤트는 5초 이상 소요됩니다.
이벤트를 클릭하면 세부 정보를 볼 수 있습니다.
이미지라는 점에 유의하십시오. 특히 로드하는 데 5 - 6초가 걸리고 지연을 유발하는 애플리케이션의 배경 이미지입니다.
이러한 결과를 바탕으로 여기에서 배경 이미지가 범인이라는 가설을 세웁니다. 최적화되지 않은 고해상도 이미지는 웹 사이트 속도 저하의 가장 일반적인 원인입니다. 좋은 소식! 이제 이유를 알았으므로 문제를 해결할 수 있습니다.
요약
요약하면 애플리케이션의 속도 저하를 관찰하고 New Relic 브라우저 모니터링을 사용하여 다음을 수행했습니다.
- 사이트의 핵심 웹 바이탈 관찰
- 속도 저하 원인 좁히기
숙제
잘하셨어요! 이제 모니터링을 시작했으므로 여정의 다음 단계를 수행하는 데 도움이 되는 몇 가지 문서가 있습니다.