성능 최적화 목표 설정하기
성능 최적화를 하려면 시간에 따라 사용자가 어떻게 느끼는 지 알아야 한다. Google에서 제안하는 RAIL과 Web Vitals은 시간에 따라 사용자가 어떻게 느끼는 지 알려준다. 이 두 가지 모델을 통해서 성능 최적화 목표를 설정할 수 있다.
Response는 사용자 인터렉션에 관한 내용이며, HTTP Response가 아니다.
RAIL은 웹 앱의 주요 작업인 Response, Animation, Idle, Load의 약자다. 사용자의 경험을 주요 작업으로 나누고 각각의 성능 목표를 정의하는 데 도움이 된다.
100ms 이내에 반응해야 한다. 사용자 입력이 시작하고 상호작용이 즉각적인 것처럼 느끼도록 하려면 100ms 이내에 반응해야 한다.
각 프레임을 10ms 이하로 생성해야 한다. 왜냐하면, 프레임의 최대 시간은 16ms이지만 브라우저는 렌더링하는 데 약 6ms가 필요하므로 처리시간은 10ms가 된다.
유휴 시간에 데이터 로드, 사용자 입력 응답이 발생하는 데, 유휴 시간을 가지지 않으면 이것들을 방해할 수 있다.
첫 번째 Load는 5000ms 이내에 돼야 하고, 후속 로드는 2000ms 이내하는 것이 좋다. 모바일 사용자 장치와 느린 네트워크를 고려해서 5000ms 이내에 로드하는 게 좋다.
좀 더 자세한 내용을 알고 싶다면 RAIL 정리를 참고한다.
Web Vitals은 좋은 UX를 제공하기 위해 Google에서 제안하는 성능 품질 지침이다. Google에서 제공한 도구와 측정 항목은 숙련도에 따라서 UX 품질을 파악하기 힘들다는 사실을 발견했다. 그래서 Web Vitals은 환경을 단순화해서 품질 개선에 도움이 되는 것에 초점을 맞췄다.
로딩 시간, 상호작용 시간, 시각적 변화량 항목에 대한 좋음/나쁨을 판단할 수 있는 숫자 범위를 가이드한다. 성능 측정 항목 중 주요 지표는 Core Web Vitals로 구분한다.
- 브라우저가 페이지 콘텐츠의 첫 번째 바이트를 수신하는 데 걸리는 시간을 의미한다.
- 600ms 이상 걸리면 나쁨을 의미한다.
- 페이지 로드가 시작된 후 페이지 콘텐츠의 일부가 화면에 렌더링 될 때까지의 시간을 측정한다.
- 콘텐츠는 텍스트, 이미지(배경 이미지 포함), svg 요소 또는 흰색이 아닌 canvas 요소를 의미한다.
- 페이지가 처음 로드를 시작한 시점을 기준으로 뷰포트 내에 표시되는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 측정한다.
- img, image내의 svg, video, url() 배경, 텍스트를 고려한다.
- 이미지는 보이는 크기와 고유 크기 중 더 작은 크기를 고려한다.
- 텍스트 요소의 경우 해당 텍스트 노드의 크기만 고려된다.
- FCP와 TTI 사이의 총 시간을 측정한다.
- 메인 스레드는 50ms 이상 실행되는 작업인 Long Task가 있을 때 차단 된 것으로 간주한다.
- FCP와 TTI 사이에 발생하는 각 Long Task의 차단 시간의 합계가 TBT다.
- 예를 들어 Long Task 250ms, 90ms가 있다면 각각 50ms를 제외한 240ms가 TBT다.
- 페이지가 로드 되기 시작한 시점부터 기본 하위 리소스가 로드 된 시점까지의 시간을 측정하며 사용자 입력이 가능한 시점을 측정한다.
- FCP가 시작되고, 5초 동안 메인 스레드를 차단하지 않는 시기를 찾는다. 그 시기에서 과거로 검색하며 Long Task의 종료 시점을 찾는 다. 그 시점이 TTI 완료 시점이다.
- 사용자가 페이지에 처음 인터렉션 한 시간부터 이벤트 핸들러 처리를 시작할 수 있는 시간까지의 시간을 측정한다.
- 페이지에서 발생하는 모든 예기치 않는 레이아웃 이동에 대한 모든 개별 레이아웃 이동 점수의 합계를 측정한다.
-
CLS = 이동 거리 비율 x 이동한 영역 비율(뷰포트가 100%다)
성능 측정 항목 중 주요 지표인 LCP, FID, CLS를 의미한다.
- 좋음: 2500ms 미만
- 나쁨: 4000ms 초과
- 좋음: 100ms 미만
- 나쁨: 300ms 초과
- 좋음: 0.1 미만
- 나쁨: 0.25 초과