프론트엔드 성능 측정 왜 해야하나?
유저 이탈방지가 목적. 좋은 유저경험. 등등~ 당연한 이유!
프론트엔드에서 측정해야 하는 성능은 무엇일까?
- 로딩시간
- 렌더 시간
- 메모리 누수 확인
로딩 속도
로딩 속도를 측정하는 기준은 크게 세가지가 있다.
- 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 frame 이를 계산해보면 한 화면이 그려지는 시간이 약 16ms 미만이어야 자연스럽게 보임.
브라우저에서 렌더링은 아래와 같은 순서로 진행된다.
- Javascript: 페이지에 DOM 요소 추가 등 시각적 변화를 일으키는 작업 처리
- Style: CSS를 어떤 DOM 요소에 적용해야 할 지 계산
- Layout: 각 요소의 너비나 위치를 계산해 화면상에 배치
- Paint: 각 요소에 배경색, 글자, 색, 그림자 등과 같이 픽셀 채우기
- Composite: 이전 과정에서 생성된 레이어 병합
메모리 누수
메모리 누수는 할당된 자원이 제때 해제되지 않고 계속해서 메모리에 남아있는 현상. 대부분은 가비지 컬렉터에 의해 해제되지만, 다음과 같은 이유로 해제가 되지 않는 경우가 있다.
- 잘못 사용한 전역 변수
- 해제되지 않은 타이머, 콜백
- 돔 외부에서의 참조
- 잘못 사용한 클로저
일반적으로 자바스크립트 엔진의 경우, 실행컨텍스트가 생성된 이후 평가와 실행과정을 거친다. 참조할 수 없는 객체의 경우(참조카운트0), 가비지로 분류되고 메모리에서 제거된다. (가비지 컬렉션 기능). 객체는 대부분 일회성이 되며, 메모리에 오랫동안 남아있는 경우는 드물다.
이에대해 정리한 나의 블로그가 있다. 근데 아직 정리를 안해서… 추후에 업데이트 되면 링크를 걸겠다.
Web Vitals
이 외에도 구글에서 필수적인 성능 지침을 정의해 두고 성능 측정의 기준으로 이용되고 있다. 기준에는 LCP, FID, CLS 가 있다.
FID (First Input Delay)
사용자의 행동에 대해 실제로 이벤트 핸들러가 반응하기까지 걸리는 시간. 사용자가 이벤트를 발생시킬 때 메인 스레드에서 다른 작업이 진행 중이라면 그 이벤트를 처리할 수 있는 시점은 해당 작업이 끝난 이후가 된다.
- 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. 구글에서 제시한 WebVitals를 이용해서 성능을 측정하고 결과를 제공한다.
나도 이 도구를 써본적이 있다. 점수별로 표현하며, 100점만점으로 평가한다. 그런데 컴퓨터마다 다른 점수를 하는 것 보니 당연하게도 실험하는 컴퓨터의 성능을 기반으로 점수를 측정하는 것 같다. 모든 환경에서? 검사하려면 어떻게 해야할까~ 라는 고민이 생겼으나 나중에 더 공부해 봐야겠다.
크롬 개발자 도구
개발자 도구의 퍼포먼스 탭과 네트워크 탭, 메모리 탭을 이용하는 방법도 있다.
퍼포먼스 탭
직접 원하는 구간을 녹화함으로써 네트워크 , 렌더링 , 메모리 전반에 관한 사항을 확인할 수 있다.
메모리 탭
현재 메모리의 사용률을 확인할 수 있다. 스냅샷을 찍어 각 스냅샷 간의 차이를 비교해 어느항목에서 메모리 누수가 발생했는지 찾을 수 있다.
네트워크 탭
에셋을 불러오거나 네트워크 요청이 처리되는데 얼마나 시간이 걸리는지 확인할 수 있다. 옵션을 통해서 모바일 환경과 유사한 네트워크를 설정해 시뮬레이션도 가능하다. 프리셋 제공되고, 환경을 커스터 마이징 할 수 있다.
네트워크 탭은 나도 이용한 적이 있다. 실제로 콜스택에서 어떤 요청을 비동기 처리중인지 알수도 있고, 어떤 요청이 오래걸리는지 알 수 있어서 좋았다. 3G 환경처럼 느린 네트워크 환경에서 브라우저가 어떻게 화면에 그려지는지도 확인이 가능해서 신기했다.
리액트 프로파일러
리액트로 만들어진 앱의 경우 사용할 수 있다. 컴포넌트별 렌더링 시간을 파악할 수 있고, 사용자의 인터렉션에 대한 변화를 추적할 수 있다.
내 익스텐션에도 설치되어있다. 해당기능은 v16.5 이상의 리액트 버전으로 빌드된 사이트거나, 개발모드여야 한다.
성능 측정 시 고려할 것들
서비스에 맞는 성능 개선 요소에 집중하기.
측정 , 최적화는 모두 값이 비싼 비용이다. 서비스의 성격에 맞게 최적화를 할 요소를 잘 선택해야 한다는 뜻이다.
예) 넷플릭스 : 사용자와 인터랙션이 많고 스트리밍 서비스이기 때문에 사용자 입력에 따른 반응속도와 메모리관리가 중요.
예2) 위키피디아: 정보를 제공하는데 초점. 처음 화면이 나타나는 속도, 검색하는데 걸리는 시간이 중요
기본 환경에서 측정하기
가장 기본상태에서 측정하는 것이 정확한 측정 데이터를 얻을 수 있다. 크롬 개발자 도구를 이용하는 경우 시크릿 모드를 사용하는 것을 추천.
타겟 사용자 환경에 맞춰 데이터 수집
당연한 얘기지만, 서비스 목표 타겟 기기가 모바일이라면, 웹환경은 성능측정이 소용없다 일반적으로 웹에 비해 성능이 4~5배정도 낮기 때문에 타겟에 맞춰 데이터를 수집해야 한다.