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

랩

이 절차는 뉴렐릭 을(를) 사용하여 웹 앱 문제를 해결하는 방법을 알려주는 실습의 일부입니다.

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

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

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

중요

New Relic에서 데이터를 보려면 이 절차에 대해 브라우저 모니터링을 활성화해야 합니다.

아직 하지 않았다면 브라우저 에이전트로 앱을 계측하십시오.

애플리케이션의 속도 저하 디버그

뉴렐릭 홈페이지에서 Browser 으로 이동하여 Relicstaurants 를 선택하세요.

여기에서는 Page views with JavaScript errors, Core web vitals, User time on the site, Initial page load and route changes 등을 포함하여 브라우저 애플리케이션과 관련된 모든 데이터를 볼 수 있습니다.

largest contentful paint (LCP) 에 주목하세요.

콘텐츠가 포함된 최대 페인트(LCP)는 웹 페이지의 기본 콘텐츠가 로드되는 속도를 나타냅니다. 이상적으로는 콘텐츠를 로드하는 데 1-2초 이상 걸리지 않아야 합니다. 여기에서는 사이트가 5초 이상 로드되는 것을 볼 수 있습니다. 사용자가 불평하는 것도 당연합니다!

하지만 이 지연의 원인은 무엇입니까? 백엔드?

아래로 스크롤하여 Front end vs. back end 그래프를 확인하세요.

그래프를 필터링하고 백앤드를 로드하는 데 걸리는 시간을 확인하려면 Back end (time to first byte) (50%) 을 클릭하세요.

그래프는 백엔드가 최악의 경우 요청을 처리하는 데 최대 140밀리초가 걸렸음을 나타냅니다. 이것은 프런트 엔드가 지연을 유발한다는 것을 의미합니까?

Front end (Window load + AJAX) (50%) 을 클릭합니다.

문제가 있습니다! 그래프는 프런트 엔드에서 지연이 발생하고 있음을 나타냅니다.

프론트엔드에서 지연이 발생하는 원인을 좁히려면 Initial page load and route change 그래프를 자세히 살펴보세요.

Initial page load (Window load + AJAX) 을 클릭합니다.

그래프는 Initial page load (Window load + 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밀리초까지 걸리는 것을 알 수 있습니다.