• English日本語한국어
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하십시오.

문제 신고

실습 파트 4: 애플리케이션의 프런트엔드 속도 저하 디버그

이 절차는 New Relic을 사용하여 웹 앱 문제를 해결하는 방법을 가르치는 실습의 일부입니다. .

랩의 각 절차는 마지막 절차를 기반으로 하므로 이 절차를 시작하기 전에 마지막 절차 인 애플리케이션의 오류 디버그 를완료했는지 확인하십시오.

애플리케이션에서 JavaScript 오류를 수정한 후 귀하와 귀하의 팀은 자신감을 느낍니다. 다운 타임을 준비하고 소셜 미디어로 이동하지만 Twitter를 확인하고 혼란스러워하는 고객을 봅니다.

어 오! 고객이 행복해 보이지 않습니다. 지연의 원인을 찾기 위해 New Relic 브라우저 모니터링을 사용할 때입니다.

중요

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 브라우저 모니터링을 사용하여 다음을 수행했습니다.

  1. 사이트의 핵심 웹 바이탈 관찰
  2. 속도 저하 원인 좁히기

숙제

잘하셨어요! 이제 모니터링을 시작했으므로 여정의 다음 단계를 수행하는 데 도움이 되는 몇 가지 문서가 있습니다.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.