12. 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표

12.1 웹사이트와 성능

12.2 핵심 웹 지표란?

CWV(Core Web Vital) 로 불리며 구글에서 만든 지표이다
LCP(Largest Contentful Pain) : 가장 큰 용량의 컨텐츠가 그려지는 시간
FID(Frist Inpur Delay) : 최초 입력 지연
CLS(Cumulative Layout Shift) : 누적 레이아웃 이동
TTFB(Time To Fisrt Byte)
FCP(Fisrt Contentful Paint) : 최초 콘텐츠풀 시간

12.3 LCP

12.3.1 LCP 의 정의

페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에 가장 큰 이미지 및 텍스트를 렌더링 하는데 걸리는 시간

12.3.2 의미

기존에는 웹페이지 로딩 완료 시점을 DOMContentLoaded 로 판단을 했지만, 해당 이벤트는 HTML 파싱이 마무리된 시점에 호출이 되며 CSS, 이미지, 하위 프레임 로딩은 기다리지 않기 때문에 문제가 있었다
따라서 사용자에게 화면을 전달하는 속도를 객관적으로 판단하기 위한 지표로 만들어 진것이 LCP 이다

12.3.3 LCP(최대 컨텐츠풀 페인트)

LCP 는 뷰포트를 기준으로 하므로 디바이스, 그리고 화면 형태에 따라 다르게 측정 된다

12.3.4 기준 점수

2.5 초 미만 : GOOD
2.5 ~ 4.0 : 개선 필요
4.0 초 초과 : POOR

12.3.5 개선 방안

텍스트는 언제나 옳다

이미지 보다는 텍스트가 빠를 수 밖에 없다

이미지는 어떻게 불러올 것인가?

<img>, <video> 는 프리로드 스캐너에 의해 빠르게 요청되므로 빠른 지표를 가진다
<svg>, background-image 는 CSS 로딩 + HTML 파싱 이후에 그려지므로 대부분 나쁜 지표를 가진다

그 밖에 조심해야 할 사항

이미지는 무손실 압축이 좋다
lading=lazy 는 로딩을 나중에 하므로 대부분 LCP 에 영향을 미치는 큰 데이터에 사용할 경우 안좋은 영향을 미친다
fadein 애니메이션이 걸리면 당연히 LCP 에 합산 되므로 안좋은 영향을 미친다
최대한 서버에서 빌드해서 보내줄 것, useEffect 등이 쓰이면 결국 리액트 파싱이 끝난 후에 작업이 진행 되므로 지표에 악영향
LCP 에 영향을 미치는 컨텐츠는 직접 호스팅

12.4 FID(최초 입력 지연)

12.4.1 정의

화면이 아무리 빨리 로딩이 되어도 상호 작용이 불가능하면 사용성이 안좋으므로, 웹사이트의 반응성 지표인 FID 도 중요하다

12.4.2 의미

사용자 경험에 영향을 미치는 RAIL
Responese : 사용자 입력에 대한 반응 속도, 50ms 미만으로 처리 필요 (FID 요소)
Animation : 애니메이션 프레임이 10ms 이하일 것
Idle : 사용자 요청에 50ms 이내에 응답 필요
Load : 5초 이내에 컨텐츠 전달 및 인터랙션 준비

12.4.3 예제

12.4.4 기준 점수

100ms 미만 : GOOD
100 ~ 300ms : 개선 필요
300ms 초과 : POOR

12.4.5 개선 방안

실행에 오래 걸리는 긴 작업을 분리

메인 스레드에서 처리에 올래 걸리는 작업이 있으면 경고가 뜬다
크롬 성능 탭에서 제한을 걸어서 성능이 부족한 기기에서의 상황을 테스트 할 수 있다
긴 작업은 여러 개로 분리하기

자바스크립트 코드 최소화

크롬 개발자 도구의 커버리지를 선택하고 기록을 눌러서 페이지를 작동 시키면 해당 페이지에서 사용하지 않는 JS 를 볼 수 있다
다만, 특정 이벤트에만 사용되는 코드일 가능성이 있으므로 무조건 삭제는 위험
폴리필 등은 환경에 따라 삭제하는 방법으로 성능을 향상 가능

타사 자바스크립트 코드 실행의 지연

Google Analytics 나 Firebase 같은 통계 집계를 위한 코드로 성능 저하가 생길 수 있다
해당 코드는 중요 자원이 아니므로 defer 나 async 로 불러오는 것이 좋다

12.5 CLS(누적 레이아웃 이동)

12.5.1 정의

무언가를 클릭하려고 했을 때, 다른 요소가 로딩 중이어서 클릭 하려는 순간에 화면이 밀려 원하던 클릭 못하는 경험
로딩으로 인해 레이아웃이 늦게 떠서, 다른 걸 클릭 하는 것

12.5.2 의미

영향분율 : (이동된 레이아웃의 높이 + 이동된 높이) / 전체 뷰포트 높이
거리분율 : 레이아웃이 이동한 높이 / 전체 뷰포트 높이
최종 점수 : 영향분율 x 거리분율
레이아웃 이동이 발생한 레이아웃의 높이 10, 레이아웃이 이동한 높이 10, 뷰포트의 높이 100 이면
- 영향분율 : (10 + 10) / 100 = 0.2
- 거리분율 : 10 / 100 = 0.1
- 최종 점수 : 0.2 * 0.1 = 0.02

12.5.3 예제

유튜브와 같이 미리 영상이 나올 곳의 레이아웃을 띄워놓고 추후에 데이터를 로딩하면 화면 밀림이 발생하지 않아 CLS 관련 지표를 좋게 만들 수 있다

12.5.4 기준 점수

0.1 미만 : GOOD
0.1 ~ 0.25 : 개선 필요
0.25 초과 : POOR

12.5.5 개선 방안

삽입이 예상되는 요소를 위한 추가적인 공간 확보

useLayoutEffect 를 사용하여 미리 공간을 확보하기. 단, 페인팅 성능에 영향을 주므로 신중하게 선택 필요
스켈레톤 UI 적용. 단, 해당 영역이 뜨지 않는다면 문제 발생
SSR 적용. 단, 상황에 따라 적용이 어려운 케이스 존재

폰트 로딩 최적화

FOUT(Flash Of Unstyled Text) : 기본 폰트로 보이다가 뒤 늦게 폰트가 적용되는 현상
FOIT(Flash Of Invisible Text) : 기본 폰트 조차 없어서 안보이다가, 뒤늦게 폰트가 로딩 되면서 텍스트가 보이는 현상
위의 문제 해결을 위해서 적용해 볼 점
- <link> 의 preloading 사용 : 폰트에 프리로딩을 적용하여 빠르게 불러와서 사용하도록 설정
- font-family 의 옵션 사용
  - auto : 브라우저가 결정
  - block : 폰트가 로딩 되기 전까지 렌더링 중단, 최대 3초
  - swap : 일단 기본 폰트로 렌더링 후, 폰트 로딩이 완료 되면 적용 (FOUT 방식)
  - fallback : 100ms 간 텍스트를 보여주지 않고, 이후 fallback 폰트로 렌더링. 폰트 로딩이 완료 되면 적용
  - optional : fallback 과 동일하게 작동하나 네트워크 상황에 따라 브라우저가 폰트 다운로드를 직접 취소

적절한 이미지 크기 설정

aspect-ratio 속성을 사용하기 위해 이미지의 기본 비율을 미리 적어두어서 문제를 해결, 이렇게 할경우 100% - auto 등으로 인해 발생하는 문제에서 자유로울 수 있다
<img src="./image.jpg" alt="이미지" width="4" height="3"> 처럼 비율로 작성해도 되지만 오래된 브라우저나 CSS 로딩 실패 등의 상황을 고려하여 원하는 이미지의 크기게 맞는 비율을 적어두는 편이 좋다

<img src="./image.jpg" alt="이미지" width="1600" height="900">

뷰포트에 맞게 다른 반응형 이미지를 사용하고 싶다면 srcset 속성을 사용하는 것이 좋다

<img
  width="1000"
  height="1000"
  src="./image-1000.jpg"
  srcset="image-1000.jpg 1000w, image-2000 2000w, image-3000.jpg 3000w"
/>

12.5.6 핵심 지표는 아니지만 성능 확인에 중요한 지표들

최초 바이트까지의 시간 (Time to First Byte, TTFB)

웹 페이지가 첫 번째 바이트를 수신하는데 걸리는 시간. 즉, 최초 응답이 오는 시간이 얼마나 걸리는지 측정
600ms 이상이면 개선이 필요
SSR 과 같이 서버에서 스트리밍 형식으로 제공되는 페이지의 경우 해당 지표가 매우 중요

최초 컨텐츠풀 페인트(First Contentful Paint, FCP)

최초 화면에 뭐라도 뜨기 시작한 시간
- 1.8 초 미만 : GOOD
- 1.8 ~ 3.0 초 : 개선 필요
- 3.0 초 초과 : POOR
개선 방안
- TTFB 최적화
- 리소스(CSS, JS) 최적화
- Above The Fold 최적화 : 최초 화면에 보이지 않느 부분은 늦게 렌더링
- 페이지 리다이렉트 최소화 : 다른 페이지로 이동을 하려면 필히 렌더링이 발생하므로 최소한으로 유지
- DOM 크기 최소화 : DOM 이 크면 렌더링에 많은 시간이 들게 되므로 최적화 필요

12.6 정리

성능은 사용성에 큰 영향을 미치므로 버그 만큼이나 충분히 고려해야 한다

13. 웹페이지 성능을 측정하는 다양한 방법

13.1 어플리케이션에서 확인하기

13.1.1 create-react-app

web-vitals 라이브러리 & PerformanceObserver 라는 API 를 사용하여 측정 가능
console.log 를 넣어 브라우저에서 확인하거나 서버로 보내기, 파일로 기록 등등 다양하게 활용이 가능하다

reportWebVitals(console.log);

13.1.2 create-next-app

NextWebVitalsMetric 을 통해 측정 가능
Next 에 특화된 지표도 제공
- Next.js-hydration : SSR 되어 하이드레이션 하는데 걸린 시간
- Next.js-route-change-to-render : 경로 변경 후 렌더링을 시작하는데 걸린 시간
- Next.js-render : 경로 변경 후 완료된 페이지를 렌더링하는데 걸린 시간

13.2 구글 라이트하우스

구글에서 제공하는 웹페이지 성능 측정 도구

13.2.1 구글 라이트 하우스 - 탐색 모드

접속 후 페이지 로딩이 완료될 때까지의 성능을 측정하는 모드

성능

FCP, LCP, CLS 이외에도 3가지 추가적 지표 제공
Time to Interactive : 페이지에서 사용자가 완전히 상호작용 할 수 있을 때까지 걸리는 시간
- 0 ~ GOOD ~ 3.8 ~ 개선 필요 ~ 7.3 ~ POOR
Speed Index : 페이지가 로드되는 동안 컨텐츠가 얼마나 빨리 시각적으로 표시되는지 수치
- 0 ~ GOOD ~ 3.4 ~ 개선 필요 ~ 5.8 ~ POOR
Total Blocking Time : 메인 스레드에서 특정 시간 이상 실행되는 작업의 총 합
- 특정 작업이 50ms 이상 실행되면 긴 작업으로 간주한다

접근성

사용자 및 신체적으로 불편한 사람들이 일반적인 사용자와 동등하게 웹페이지를 이용 가능하도록 보장하는 것

권장사항

CSP(Content Security Policy, 컨텐츠 제한 정책) 을 통한 XXS(Cross Site Scriptinh) 방어
HTTPS 사용 여부
사용자 위치 정보 권한 체크
알림 권한 체크
보안 취약점이 있는 JS 라이브러리 사용 체크
비밀번호 붙여넣기 여부
이미지 비율 표시
이미지 해상도 체크
HTML Doctype 여부
문자 집합(utf-8 같은) 체크
지원 중단 API 사용 여부
콜솔 로그에 뜨는 에러 여부
크롬 개발자 도우 Issue 탭의 문제점 여부
소스 맵(압축 된 코드를 원본 코드로 변환할 수 있는 파일, 주로 디버깅 시 사용) 여부
font-display 여부(옵셔널 폰트가 미리 로드 되었는지 여부)

검색 엔진 최적화(SEO)

robots.txt, <meta>, <title> 등의 정보 확인

13.2.2 구글 라이트 하우스 - 기간 모드

실제 웹페이지를 탐색하는 동안 측정하는 모드, 시작을 누루고 작업 수행 후 종료를 눌러 확인

흔적(View Trace)

시간에 흐름에 따른 웹페이지 로딩 여부 확인 가능, 13.4.1 에서 다룬다

트리 맵

페이지 로딩 시 불러온 리소스를 전부 확인 가능
실제로 로딩은 했지만 사용하지 않은 바이트도 확인 가능

13.2.3 구글 라이트 하우스 - 스냅샷

지금 사용자가 사용하다가 멈춘 현재 페이지 상태를 기준으로 분석하는 모드
기간 분석이 아니므로 분석의 내용은 제한적

13.3 WebPageTest

가장 널리 알려진 성능 분석 도구
거리가 먼 지역 서버를 기준으로 테스트하기 때문에 LH 보다 성능이 떨어지는 가능성이 높다
www.webpagtest.org (opens in a new tab) 에 접속하여 url 을 입력하면 분석이 가능
제공하는 5가지 도구
- Site Performance : 성능 분석 도구
- Core Web Vitals : 핵심 지표 확인 도구
- Lighthout : 구글 라이트 하우스
- Visual Comparison : 2개 이상의 사이트를 동시 실행하여 로딩 과정 비교 도구
- Traceroute : 네트워크 경로를 확인하는 도구

13.3.1 Performance Summary

Opportunities & Experiments
- Is It Quick : 웹사이트가 빠른지 평가. TTFB 가 짧은지, LCP 가 합리적인지 등을 판단
- IS It Usable : 웹사이트의 사용성과 시각적인 요소 확인. CLS 를 최소화하는지, 상호작용이 빠른지, 접근성 이슈가 있는지 등을 확인
- Is It Resilient : 보안 취약성 점검. 렌더링을 막는 요소가 있는지, 실질적 위험 요소가 있는지 평가
Observed Metrics : TTFB, FCP, 렌더링 시작에 소요되는 시간 등 다양한 지표에 대한 결과
Individual Runs : 기본적으로 3번의 테스트를 하고 평균값을 보여주는데, 각각 실행에 따른 결과 확인 가능

13.3.2 Opportunities & Experiments

13.3.1 에서 이야기한 테스트를 수행

13.3.3 Filmstrip

시간의 흐름에 따라 페이지가 어떤 식으로 그려졌는지 영화 필름을 보는 것 처럼 확인할 수 있는 메뉴
각각의 상황을 클릭하여 해당 상황에 따른 세부 지표를 통해 사이트의 개선이 가능하다

** [p. 843] 짬바가 필요한 영역으로 보인다

13.3.4 Details

13.3.5 Web Vitals

LCP, CLS, TBT(총 블로킹 시간)에 대한 자세한 내용 확인 가능

13.3.6 Optimizations

최적화와 관련된 정보를 보여준다

13.3.7 Content

컨텐츠를 종류별로 묶어서 통계를 보여주는 페이지

13.3.8 Domains

컨텐츠가 어떤 도메인에서 왔는지 묶어서 통계를 보여주는 페이지

13.3.9 Console Log

페이지 접속 시 뜨는 console.log 를 확인 가능한 페이지

13.3.10 Detected Technologies

웹사이트를 개발하는데 사용 된 기술을 확인할 수 있는 메뉴

** [p. 850] wappalyzer 대용으로 좋을 듯!

13.3.11 Main-thread Processing

메인쓰레드가 어떤 작업을 했는지 비율을 보여주는 메뉴

13.3.12 Lighthouse Report

LH 리포트 확인 가능

13.3.13 기타

외부에서 제공하는 서비스로 클릭 시 해당 서비스를 제공하는 외부 페이지로 이동

13.4 크롬 개발자 도구

개발 된지 오래된 사이트 or 개발자와 운영자가 다른 경우 자세하기 들여다 보기 좋은 도구

13.4.1 성능 통계

LH 와 비슷하게 Page Load 를 통해 로딩 시작 ~ 끝 까지 확인이 가능, 또는 Start Recoding 을 통해 원하는 부분 성능 측정 가능
Throttling 을 지원하여 열악한 환경에서 테스트도 가능

** [p. 853] 윈도우 컴에서 확인 ㄱㄱ

insight

주목할 만한 이벤트를 모아서 보여주는 기능
FCP, LCP, Dom Content Loaded 같은 이벤트가 언제 발생했는지 확인 가능
Performance Measure : Timing API 로 측정한 지표 확인 가능
Long Task : 가장 주목할 만한 지표, 메인 쓰레드에서 가장 오래 실행한 작업을 표기
- 해당 Task 를 확인해서 소스 코드를 확인하여 수정이 가능
Render Blocking CSS : 어떤 리소스가 렌더링을 막는지 확인 가능
Forced Style Recalculation : 스타일이 다시 계산되는 작업이 어디서 일어나는지 확인 가능

메인 메뉴

시간 상황에 따른 상태를 면밀히 측정 가능

13.4.2 성능

Performance Insights 탭이 등장하기 전에 있던 탭으로, 더 복잡하고 어렵지만 자세한 정보를 볼 수 있다

메뉴

위에서 언급한 성능 관련 내용 확인 가능

13.5 정리

About About