프론트엔드, 성능 측정 왜 해야 할까?
아카마이에서 발표한 이커머스 업계 성능 현황 보고서에 따르면 지연속도가 늘어날수록 이탈률이 급격하게 증가하고, 구매 전환률 역시 감소한다고 합니다.
2초 지연 시 최소 62%의 이탈률 증가와 25%의 구매 전환률 감소를 하고 있으며 이는 꽤 큰 비율입니다.
실제로 핀터레스트는 성능 최적화를 통해 대기시간 40% 감소, SEO 트래픽 15% 증가 그리고 가입 전환율 15% 증가를 이루어냈습니다.
이처럼 성능은 서비스 이용률 및 기업의 이익에 영향을 미칩니다.
즉, 프론트엔드에서 성능 측정이 필요한 이유는 사용성 개선을 통한 이익 증대를 끌어내기 위해서라고 할 수 있습니다.
프론트엔드에서 측정해야 하는 성능은 무엇일까?
프론트엔드에서 측정할 수 있는 성능으로는 크게 로딩 시간, 렌더 시간 그리고 메모리 누수 확인이 있습니다.
로딩 속도
로딩 속도를 측정하는 기준은 크게 세 가지가 있습니다.
FCP (First Contentful Paint)
첫 요소가 로드될 때까지 걸리는 시간
FMP (First Meaningful Paint)
사용자에게 의미 있는 첫 요소가 로드될 때까지 걸리는 시간
LCP (Largest Contentful Paint)
주요 콘텐츠가 로드될 때까지 걸리는 시간
FCP의 경우 로딩 바가 첫 요소가 되는 경우가 많은데, 실제 콘텐츠와 무관한 로딩을 보는 것이 사용자에게 지연 시간으로 느껴질 수 있어 FMP를 로딩 속도의 기준으로 사용했었으나 현재는 약 20%의 항목에서 정확하지 않다는 연구 결과가 있어 LCP를 기준으로 로딩 속도를 측정합니다.
구글이 제시되는 기준에 따르면, LCP가 2.5초 미만이면 좋음(Good), 2.5초에서 4.0초 미만이면 개선이 필요함(Needs Improvement) 그리고 4초 이상이면 형편없음(Poor)으로 분류합니다.
렌더링 성능
60은 사람이 자연스럽다고 느끼는 초당 화면 수를 의미합니다. 이를 계산해보면 약 한 화면이 그려지는 시간이 16ms 미만이어야 자연스럽게 보인다는 것을 알 수 있습니다.
브라우저에서 렌더링은 아래와 같은 순서로 진행합니다.
- Javascript: 페이지에 DOM 요소 추가 등 시각적 변화를 일으키는 작업 처리
- Style: CSS를 어떤 DOM 요소에 적용해야 할 지 계산
- Layout: 각 요소의 너비나 위치를 계산해 화면상에 배치
- Paint: 각 요소에 배경색, 글자, 색, 그림자 등과 같이 픽셀 채우기
- Composite: 이전 과정에서 생성된 레이어 병합
이런 과정을 통해 한 화면이 그려지게 됩니다.
브라우저 렌더링 과정이 16ms를 초과하게 된다면, 초당 프레임 수가 줄어들어 사용자는 움직임이 자연스럽지 않다고 느끼게 될 것입니다. 이렇게 브라우저 렌더링 과정이 얼마나 걸리는지를 측정함으로써 렌더링 성능을 측정할 수 있습니다.
메모리 누수
메모리 누수는 할당된 자원이 제때 해제되지 않고 계속해서 메모리에 남아있는 현상을 말합니다. 대부분은 가비지 컬렉터에 의해 해제되지만, 다음과 같은 이유로 해제가 되지 않는 경우가 있습니다.
- 잘못 사용한 전역 변수
- 해제되지 않은 타이머, 콜백
- 돔 외부에서의 참조
- 잘못 사용한 클로저
Web Vitals
이 외에도 구글은 Web Vitals이라는 필수적인 성능 지침을 정의해 두고 성능 측정의 기준으로 이용되고 있습니다. 그 기준은 LCP, FID, CLS가 있습니다.
FID (First Input Delay)
사용자의 행동에 대해 실제로 이벤트 핸들러가 반응하기까지 걸리는 시간을 의미합니다. 사용자가 이벤트를 발생시킬 때 메인 스레드에서 다른 작업이 진행 중이라면 그 이벤트를 처리할 수 있는 시점은 해당 작업이 끝난 이후가 됩니다. 이처럼 사용자의 이벤트를 받고 실제로 처리할 수 있게 될 때까지 걸리는 시간을 FID라고 합니다. 이 시간이 짧을수록 사용자는 입력에 대한 반응이 빠르게 온다고 느끼게 될 것입니다.
- Good: ~ 100ms
- Need Improvement: 100ms ~ 300ms
- Poor: 300ms ~
CLS (Cumulative Layout Shift)
시각적인 안정성을 측정하는 데 사용되는 기준입니다. 이는 시작 위치에서 레이아웃이 얼마나 변화하는지에 대해 측정합니다. 다만, 이런 레이아웃이 글 작성 후 작성 완료 버튼을 누른 이후의 화면 변화와 같이 사용자가 충분히 예측할 수 있는 것이라면 변경된 정도가 커져도 성능에 영향을 미친다고 보지 않습니다.
- Good: ~ 0.1
- Need Improvement: 0.1 ~ 0.25
- Poor: 0.25 ~
성능 측정, 어떻게 할 수 있을까?
Lighthouse
가장 대표적으로 사용하는 도구로는 크롬 개발자 도구에서 제공하는 Lighthouse가 있습니다. Lighthouse는 구글이 제시한 WebVitals를 이용하여 성능을 측정하고 결과를 제공합니다.
크롬 개발자 도구
Lighthouse와 별개로 개발자 도구의 퍼포먼스 탭과 네트워크 탭 그리고 메모리 탭을 이용하는 방법도 있습니다.
퍼포먼스 탭
퍼포먼스 탭에서는 직접 원하는 구간을 녹화함으로써 네트워크, 렌더링 그리고 메모리 전반에 관한 사항을 확인할 수 있습니다.
메모리 탭
메모리 탭을 이용하면 현재 메모리의 사용률을 확인할 수 있습니다. 스냅샷을 찍어 각 스냅샷 간의 차이를 비굑해 어느 항목에서 메모리 누수가 발생했는지 찾을 수 있습니다.
네트워크 탭
네트워크 탭을 통해서 에셋을 불러오거나 네트워크 요청이 처리되는데 얼마나 시간이 걸리는지 확인할 수 있습니다. 이때 옵션을 통해서 모바일 환경과 유사한 네트워크를 설정해 시뮬레이션도 가능합니다. 기본적으로 프리셋이 제공되고 있으며 서비스에서 목표로 하는 네트워크 환경에 대한 설정을 커스터마이징할 수 있습니다.
리액트 프로파일러
리액트로 만들어진 앱의 경우에 사용할 수 있습니다. 리액트 프로파일러를 이용해 컴포넌트별 렌더링 시간을 파악할 수 있고, 사용자의 인터렉션에 대한 변화를 추적할 수 있습니다.
모니터링 도구
개발 도중이 아니라 실시간 서비스 중에도 성능을 측정하는 방법입니다. 네트워크 로딩 속도, AJAX 요청 속도 그리고 자바스크립트 에러 등을 모니터링할 수 있습니다. 예시로는 제니퍼 프론트(Jennifer Front)와 뉴렐릭(Newrelic)이 있습니다.
성능 측정 시 고려할 것들
서비스에 맞는 성능 개선 요소에 집중하기
성능 측정을 하기에 앞서 자신의 서비스에 맞는 성능 개선 요소에 집중하는 것이 중요합니다. 성능을 측정하고 최적화하는 것이 모두 비용이기 때문에 현재 상황과 서비스의 성격에 맞게 개선하고자 하는 요소를 정하는 것이 좋습니다. 예를 들어 넷플릭스의 경우 사용자와 인터렉션이 많고 스트리밍 서비스이기 때문에 사용자 입력에 따른 반응속도와 메모리 관리가 중요할 것이고, 위키피디아의 경우에는 정보를 제공하는 것에 초점이 맞춰져 있기 때문에 처음 화면이 나타나는 속도와 검색하는데 걸리는 시간 등이 중요할 것입니다.
기본 환경에서 측정하기
만약 성능을 측정하는 환경에 확장 프로그램과 같이 성능에 영향을 미치는 요소가 있다면 측정 시 정확도에 영향을 줄 수 있습니다. 따라서 가장 기본 상태에서 측정하는 것이 정확한 측정 데이터를 얻을 수 있습니다. 크롬 개발자 도구를 이용하는 경우 시크릿 모드를 사용하는 것을 추천합니다.
타겟 사용자 환경에 맞춰 데이터 수집하기
만약 서비스의 목표 타겟 기기가 모바일 기기라면 웹 환경에서의 성능 측정은 소용이 없을 것입니다. 일반적으로 모바일은 웹에 비해 성능이 4~5배 정도 낫기 때문에 자신이 타겟으로 하는 환경에 맞춰 데이터를 수집해야 합니다.
마무리
프론트엔드, 성능 측정 왜 해야 할까?
→ 사용자 개선을 통한 이익 증대를 위함
프론트엔드에서 측정해야 하는 성능은 무엇일까?
→ 로딩 속도와 렌더링 속도 그리고 메모리 누수
성능 측정, 어떻게 할 수 있을까?
→ 크롬, 리액트 프로파일러 그리고 실시간 모니터링 도구 등을 이용
성능 측정 시 고려할 것들
→ 서비스 성격, 측정 환경 동일 그리고 서비스 타겟
참고
[10분 테코톡] 🍺 서니의 프론트엔드 성능 측정에 나오는 내용을 정리했습니다. 자세한 설명을 아래의 링크를 확인해주시면 감사하겠습니다.
https://www.youtube.com/watch?v=A6J74xLWqYg&list=WL&index=31
