프론트엔드 성능 측정 왜 해야할까?
페이지에 들어갔을 때 빈 화면이 나오고 5초 뒤에 화면이 하나씩 렌더링되고 10초에 보인다면 아무도 쓰지 않습니다. 아래 자료는 이커머스 업계 성능 현황 보고서 2017년 봄 아카마이(Akamai)에서 조사한 자료입니다. 지연 속도가 늘어날 수록 이탈률이 급격하게 증가하고, 구매 전환률 역시 감소합니다.


성능은 서비스를 이용률 및 기업의 이익에 영향을 미칩니다. 즉 프론트엔드 사용성 개선을 통한 이익성 증대에 있습니다.
프론트엔드에서 측정해야 하는 성능을 무엇일까?
측정할 수 있는 성능으로는 크게 로딩시간 렌더 시간, 메모리 누수 확인이 있습니다.
- 로딩 속도
- FCP(First Contentful Paint): 첫 요소가 로드 될 때까지 걸리는 시간
- FMP(First Meaningful Paint): 사용자에게 첫 요소가 로드 될 때까지 걸리는 시간
- FMP의 경우 약 20%의 항목에서 정확하지 않다고 하여, 현재는 LCP를 기준으로 로딩 속도 측정
- LCP(Largest Contentful Paint): 주요 컨텐츠가 로드 될 때까지 걸리는 시간



화면에서 가장 큰 요소가 계속 변경, 아래는 가장 큰 화면이 렌더 후 다른 요소가 렌더되고 있지만 다른 요소는 렌더되고 있지 않음 ⇒ LCP를 이용해 로딩속도 확인
- 렌더링 성능
- 60은 사람이 자연스럽다고 느끼는 초당 화면 수
- 한 화면이 그려지는 시간이 1s/60 = 약 16ms 여야지 우리눈에 자연스럽게 보임.
- 브라우저 렌더링 과정


- 메모리 누수
- 할당된 자원이 제때 해제되지 않고, 계속해서 메모리에 남아있는 현상
- 대부분은 가비지 콜렉터에 의해 해제가 되지만, 다음과 같은 이유로 인해 해제가 되지 않는 경우가 있습니다.
- 위 그래프와 다르게 아래 그래프는 힙과 노드가 증가만 할 뿐 감소하지 않는 것을 확인할 수 있다.


- Web Vitals
- LCP 위에서 했음
- FID(First Input Delay): 사용자의 행동에 대해 이벤트 핸들러가 작동할 때 까지의 시간
- 사용자의 이벤트를 받고, 실제로 처리할 수 있게 될 때까지 걸리는 시간을 FID라고 한다.(입력에 대한 반응)
- CLS(Cumulative Layout Shift): 시각적인 안정성 측정 시 사용
- 이런 변경도 계산
- 성능 측정 체크리스트




성능 측정, 어떻게 할 수 있을까?
⇒ 크롬(lighthouse), 리액트 프로파일러, 실시간 모니터링 도구 이용
- Lighthouse
- 구글이 제시한 Web Vitals를 이요하여 성능을 측정하고 결과를 제공
- 어느 부분에서 성능적인 문제가 있는지 보여줌 ⇒ 결국 이 부분을 향상 시킨다는 것을 목표로 하면 될 듯, 각 페이지 별로 스크린샷, 다른 환경에서 어떤 결과가 나오는지 찍어두고 리팩토링을 한 뒤 어떻게 개선 되었는지 비교 분석하는 방향으로
- 개발자 도구, 퍼포먼스, 네트워크 탭
- 퍼포먼스: 직접 원하는 구간을 녹화함으로써 네트워크 렌더링, 메모리 전반에 대한 사항 확인
- 메모리: 스냅샷 간의 차이를 비교해서 어느 항목에서 누수가 발생하는지 확인 가능
- 네트워크: 네트워크 탭을 통해 에셋, 네트워크 요청이 얼마나 걸리는지 확인 가능
- 리액트 프로파일러
- 컴포넌트 별 렌더링 시간 파악 가능
- 인터랙션 변화 추적
- 모니터링 도구
- 제니퍼 프론트
- 뉴렐릭
성능 측정 시 고려할 것들
서비스 성격, 측정 환경 통일, 서비스 타겟
넷플릭스: 키 입력에 반응 속도, 메모리, 사용자 입력 안정화 대기 시간
위키피디아: 정보가 화면에 로드되는 속도, CPU 소요시간
