프론트엔드 성능 측정

참고자료 : 테코톡 프론트엔드 성능 측정

프론트엔드에서 성능이란?

웹 화면을 구현하고 서버로부터 데이터를 받아오는 과정에서 리소스들을 사용자들에게 빠르게 보여줄 수 있는 것

성능 == 속도

그렇다면 프론트엔드에서 성능은 왜 중요할까?

성능이 중요한 이유

웹 성능 측정의 기준은?

동일한 사이트더라도 사용자의 환경은 모두 다를 수 있음

따라서 속도는 상대적인 개념임

사용자 정의 지표

처음 그려지는 화면이 어떤 화면인지, 어떤게 사용자에게 의미있는 화면인지, 상호작용하는 시점은 언제인지와 같은 고민을 통해 보다 다양한 사용자 환경에서 성능을 측정한다.

따라서 사용자 정의 지표가 제공하는 특징들을 이해한 다음 사용자 경험에 중요한 부분들을 설정하는 것이 중요

성능 측정 지표

Core Web Vitals : 구글에서 만든 신뢰성 있는 지표

LCP

• 로딩 성능을 측정
  페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 측정
• 측정 요소
  1. img 요소
  2. svg 요소 내부의 image
  3. video 요소
  4. url() 함수를 통해 로드된 배경 이미지가 있는 요소
  5. 텍스트 노드 또는 기타 인라인 수준 텍스트 하위 요소를 포함하는 블록 수준 요소
  

  

우수한 사용자 경험을 제공하기 위해서는 페이지가 처음으로 로딩된 후 2.5초 이내에 LCP가 발생해야 함

FID(First Input Delay)

• 사용자의 상호 작용을 측정
• 사용자가 페이지와 처음 상호 작용할 때부터 해댱 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정
  

  

우수한 사용자 경험을 제공하려면 페이지의 FID가 100ms 이하여야 함

예를들어 사용자가 처음 입력을 입력했을 때 브라우저가 응답을 하는 시간이 100ms 이하여야 함

INP(Interaction to Next Paint)

• 2024년 3월에 FID와 대체 예정인 지표
• FID는 첫 번째 상호작용만을 측정하지만 INP는 모든 페이지 상호작용을 고려함
  

  

  
  모든 메뉴의 상호작용이 200ms 이하여야 함

CLS(Cumulative Layout Shift)

• 시각적 안정성을 측정
• 리소스가 비동기식으로 로드되거나 DOM 요소가 기존 콘텐츠 위의 페이지에 동적으로 추가되기 때문에 발생
• 우수한 사용자 경험을 제공하려면 페이지에서 0.1이하의 CLS를 유지해야 함

CLS가 안좋은 예시

56개의 아이템을 장바구니로 이동중이라고 가정하자
이때 로딩중에는 뒤로 가기를 눌러도 버튼이 동작하지 않는다.

프론트엔드 성능 측정 방법

프론트엔드 성능 측정 방법에는 크게 실험실 도구와 필드 도구를 사용하는 방법이 있다.

실험실 도구

• 일관되고 통제된 환경에서 페이지 로드를 시뮬레이션하는 도구
• Chrome DevTools
• Light house

Light house

• 웹 페이지 품질을 검사하기 위한 오픈 소스 도구
• DevTools의 Light house 패널에서 사용
• 실험실 환경에서 성능 및 접근성 등의 사용자 경험 품질을 측정
• 사이트 성능에 영향을 주는 항목과 각 항목별로 설명과 함께 개선 방안 제공
  

페이지와 사용자의 상호작용을 확인할 수 없는 실험실 도구이므로 FID 대신 확인할 수 있는 지표인 TBT를 제공

TBT(총 차단 시간)는 메인 스레드가 입력 응답을 막을 만큼 오래 차단되었을 때 시간을 측정

Performance Insights

• 웹 사이트 성능을 측정할 수 있는 DevTools 패널
• 기존의 Performance 패널의 불편한 점을 개선하기 위해 등장한 실험 단계의 기능

더 간소화된 UI, 사용 사례에 따른 분석 지원, 브라우저 작동 방식에 대한 전문 지식이 없어도 사용할 수 있도록 지원

녹화를 시작하고 페이지와 상호작용하면 리소스를 가져오는 시간 등의 각 지표들에 대해 상세히 확인할 수 있다.

또한 Layout Shift가 일어났다면 어느 부분인지 프레인 단위로 확인할 수 있다.

또한 Coverage 패널에서는 현재 페이지에서 사용하는, 사용하지 않는 js의 비율을 보여줌

Network 패널에서는 리소스 요청 개수와 응답 시간, 용량 등을 확인할 수 있음

필드 도구

• 실제 사용자가 실제로 페이지를 로드하고 페이지와 상호 작용
• Chrome UX Report
• web-vitals Library
• Chrome Web Vital Extension

Chrome UX Report(CrUX)

• 인기 사이트의 실제 사용자 경험 데이터를 제공하는 공개 데이터 세트
• 모든 사용자 중심의 Core Web Vitals 메트린이 데이터 세트에 표시
• 유의미한 데이터를 제공 받기 위해 공개적으로 검색 가능하고, 충분한 사용자가 있어야 함
  

성능을 최적화 할 수 있는 방법

위의 방법들 중 상대적으로 적은 노력으로 크게 개선할 수 있는 방법에 대해 알아보자

서버 응답 시간 개선

• 가까운 CDN으로 라우팅
• CDN 서버(Content Delivery Network)를 기존 워싱턴에서 서울로 변경
• 응답 시간을 3.56초에서 0.5초로 속도 7배 향상
  CDN
  • 인터넷 사용자가 웹사이트를 더 빠르고 효율적으로 이용할 수 있도록 도와주는 분산 서버 시스템
    

    

이미지 최적화

• 이미지 사이즈 조정, 압축
• 반응형 이미지
• 이미지 지연 로딩
  

  

  
  같은 사이즈의 이미지를 랜더링하는데 랜더링 시간에 차이가 있다.
  그 이유는??

위의 이미지(랜더링이 느린 이미지)는 원본 이미지로 약 4.3MB이고 아래의 이미지는 사이즈 조정 및 압측을 통해 30.6KB이다.

파일 크기를 99% 축소하였고 이미지 로드 시간을 108ms에서 10ms로 속도를 약 10배 상승했다.

이미지 사이즈 조정, 압축 방법

• 이미지 사이즈 - Imagemagick
  이미지를 새로 만들거나 고칠 수 있는 도구, CLI로 간단하게 이미지 사이즈 조정 가능
• 다양한 이미지 형식을 지원하는 이미지 압축 도구
  CLI, NPM 패키지, Webpack 플러그인에서 사용 가능

반응형 이미지

• 환경에 맞게 적절한 사이즈의 이미지를 제공하는 방법
  

  

  
  srcset : 브라우저에 제시할 이미지 목록과 크기 정의
  sizes : 화면 크기 조건 정의

브라우저 동작

• 기기 너비 확인
• sizes 목록에서 조건 확인
• 해당 조건에서 이미지 크기 확인
• 크기에 근접한 srcset의 이미지 요청
  
  반응형 이미지 적용 예시
  

  

  
  각 화면 크기에 맞는 이미지 파일을 요청
  모바일 환경에서 더 작은 이미지를 요청하므로 더 빠르게 랜더링할 수 있음

사용하지 않는 자바스크립트 분할(FBI 개선)

위의 코드는 home페이지와 about 페이지가 있는 예제 코드이다.

이 코드를 webpack으로 빌드하면 bundle 크기는 2.9MB이고 응답으로 오는 bundle의 크기는 877KB이다.

home 페이지에 들어왔는데 about페이지에 필요한 모듈과 라이브러리가 포함된 bundle 파일이 오고있다.

JS 코드를 분할하는 방법

• React.lazy를 사용해 처음 랜더링될 때까지 컴포넌트 코드의 로딩을 지연(dynamic imports)
• lazy를 사용해 번들을 분할
  사용자가 필요한 자바스크립트만을 제공
  

  

분할 결과

이제 초기 진입시 더 빠르게 브라우저를 랜더링할 수 있음

이미지 크기 설정(CLS 개선)

 

위의 코드처럼 이미지 요소를 작성하면 텍스트가 먼저 위치해있다가 이미지를 가져오면서 텍스트가 밀림

따라서 이미지 요소에 width, height 속성을 추가하여 이미지 가져오기 전 공간 확보하여 텍스트가 밀리는 현상을 방지할 수 있다.

Light house를 통해 확인해보면 CLS 지표가 개선되었다.
또한 앞서 설명한 이미지 압축을 통해 Layout Shift 뿐만아니라 다른 부분까지 개선한다.