[모던 리액트 DeepDive] 12장 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표

12.2 핵심 웹 지표란?

핵심 웹 지표는 뛰어난 사용자 경험을 제공하는 데 필수적인 지표입니다.

구글에서 핵심 웹 지표로 꼽는 지표는 다음과 같습니다.

• 최대 콘텐츠풀 페인트(LCP: Largest Contentful Paint)
• 최초 입력 지연(FID: First Input Delay)
• 누적 레이아웃 이동(CLS: Culmulative Layout Shift)

핵심은 아니지만, 특정 문제를 진단하는 데 사용될 수 있다고 언급한 지표입니다.

• 최초 바이트까지의 시간(TTFB: Time To First Byte)
• 최초 콘텐츠풀 시간(FCP: First Contentful Paint)

12.3 최대 콘텐츠풀 페인트(LCP)

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

큰 이미지 또는 텍스트란?

• <img>
• <svg> 내부의 <image>
• poster 속성을 사용하는 <video>
• url()을 통해 불러온 배경 이미지가 있는 요소
• 텍스트와 같인 인라인 텍스트 요소를 포함하고 있는 블록 레벨 요소(<p>, <div> 등)

페이지 로딩에 따라 변화할 수 있는 지표입니다. 사용자의 디바이스 크기에 따라, 실제 로딩에 필요한 시간에 따라 LCP의 값이 달라질 수 있습니다.

2.5초 내로 응답이 오면 좋은 점수, 4초 이내로 오면 보통, 그 이상 걸리면 나쁨으로 판단됩니다.

개선 방안:

1. LCP 예상 영역에 이미지보다는 텍스트를 활용한다.
2. 이미지를 불러오는 효율적인 방법?

• <img>: 브라우저의 프리로드 스캐너에 의해 먼저 발견되어 빠르게 요청이 일어납니다. 프리로드 스캐너는 HTML을 파싱하는 단계를 차단하지 않고 이미지와 같이 미리 로딩하면 좋은 리소스를 먼저 찾아 로딩하는 브라우저의 기능입니다. <picture>도 마찬가지입니다.
• <svg>: 프리로드 스캐너에 의해 발견되지 않아 병렬적으로 다운로드되지 않습니다. LCP에 악영향을 끼칩니다.
• <video>의 poster: poster는 video 재생 전이나 탐색 전까지 노출되는 요소입니다. 프리로드 스캐너에 의해 발견되어 <img>와 같은 성능을 낼 수 있습니다. <video>가 LCP에 영향을 줄 것 같으면 넣어주는 것이 권장됩니다.
• background-image: url(): CSS 리소스는 항상 느립니다. DOM을 그릴 준비가 될 때까지 리소스 요청이 지연되기 때문입니다. 가능하면 LCP와 같이 중요한 리소스에는 사용하지 않는 것이 좋습니다.

3. 이외 알아두면 도움되는 사항

• 이미지 무손실 압축
• loading=lazy는 사용하지 말 것
• fadein과 같은 애니메이션: 이미지가 늦게 뜨는 애니메이션은 LCP에 영향을 준다.
• 클라이언트에서 빌드하지 말 것: 가능하면 서버에서 미리 빌드된 채로 오는 것이 좋다.
• 최대 콘텐츠풀 리소스는 직접 호스팅: Cloudinary 같은 이미지 최적화 서비스를 이용해 다른 출처에서 정제한 이미지를 가져오면 최적화에 좋은 영향을 미치지 못한다. 때문에 같은 도메인에서 직접 호스팅하는 것이 좋다. 덜 중요한 리소스만 이미지 서비스를 이용할 것.

12.4 최초 입력 지연(FID)

• 사용자가 페이지와 처음 상호 작용할 때(링크 클릭, 버튼 클릭, 사용자 지정 JS 기반 컨트롤 시)부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정

메인 스레드가 바쁘면 싱글 스레드인 JS에서는 입력이 지연될 수 있습니다.

다양한 이벤트 중 클릭, 터치, 타이핑 등 개별 입력 작업에 초점이 맞춰져 있어 스크롤이나 핀치 투 줌 등은 사용자 입력이 아닌 애니메이션으로 분류해 측정 대상에서 제외됩니다.

구글이 정의한 사용자 경험 4가지를 RAIL이라 부릅니다. 이는 다음과 같습니다.

• Response: 입력에 대한 반응 속도를 50ms 미만으로 처리할 것
• Animation: 각 프레임을 10ms 이하로 생성할 것
• Idle: 유휴 시간을 극대화해 페이지가 50ms 이내에 사용자 입력에 응답하도록 할 것
• Load: 5초 이내에 콘텐츠를 전달하고 인터랙션을 준비할 것

FID는 R에 해당하는 응답에 초점을 맞추고 있습니다.

FID 측정은 사용자가 직접 클릭하거나 E2E 도구를 사용해야 합니다. FID는 최초 이벤트 발생으로부터 이벤트 핸들러가 실행되는 순간까지의 기간만 측정합니다.

100ms 이내 응답은 좋은 점수, 300ms 이내는 보통, 그 이후는 나쁨으로 판단됩니다.

개선 방안

1. 실행에 오래 걸리는 작업을 분리: 꼭 웹페이지에서 해야 하는 작업이 아니면 서버로 옮기거나 긴 작업을 여러 개로 분리하는 방법을 고민해볼 수 있습니다.
2. 자바스크립트 코드 최소화: 개발자 도구 Three dots의 커버리지(범위) 탭에서 사용되지 않은 코드의 비율을 알 수 있습니다. 또, 폴리필 코드의 크기는 제법 크기 때문에 꼭 필요하지 않으면 제거하는 것이 좋습니다.
3. 타사 자바스크립트 코드 실행의 지연

타사 스크립트의 실행이 오래 걸린다면 script 태그의 defer나 async 속성을 사용하는 것을 고려해볼 수 있습니다. defer와 async 모두 스크립트를 다른 리소스와 병렬로 다운로드하지만, async는 페이지가 완전히 로딩되지 않아도(DOM이 준비되지 않아도) 스크립트가 다운로드되는 즉시 실행됩니다.

만약 광고 같은 뷰포트에 위치에 따라 불러와야 하는 컴포넌트의 경우 IntersectionObserver를 이용해 뷰포트에 들어오는 시점에 불러오는 것이 좋습니다.

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

• 페이지의 생명주기 동안 발생하는 모든 예기치 않은 이동에 대한 지표를 계산

점수를 계산할 때 포함되는 내용은 다음과 같습니다.

• 영향비율: 레이아웃 이동이 발생한 요소의 전체 높이와 뷰포트 높이의 비율을 의미한다. 예를 들어, 레이아웃 이동이 발생한 요소의 높이가 100이고, 예기치 않은 레이아웃 이동으로 인해 10만큼 내려갔다고 가정해 보자. 이 경우 뷰포트의 높이가 100이라고 가정한다면 레이아웃 이동으로 인해 총 10+10만큼 뷰포트에 영향을 미쳤으므로 이 경우 영향비율은 0.2점이 된다 ((10+10)/100=0.2).
• 거리비율: 레이아웃 이동이 발생한 요소가 뷰포트 대비 얼마나 이동했는지를 의미한다. 예를 들어, 예기치 않은 레이아웃 이동으로 인해 10만큼 내려갔고, 전체 뷰포트가 100이라면 0.1점이 된다 (10/100).

두 가지 점수를 곱해서 최종 점수를 계산하게 됩니다.

0.1 이하인 경우 좋음, 0.25 이하인 경우 보통이며, 그 외에는 나쁨으로 판단됩니다.

개선 방안

1. 삽입이 예상되는 요소를 위한 추가 공간 확보: useEffect 대신 useLayoutEffect 사용, 스켈레톤 UI 활용, 서버 사이드 렌더링으로 해결할 수 있습니다.
2. 폰트 로딩 최적화: <link>의 rel=preload를 사용해서 폰트를 빠르게 로딩하거나, font-family: optional(auto, block, swap, fallback, optional)을 활용해 기본 폰트를 로딩하는 방법도 있습니다. 두 방법을 적절히 활용합니다.
3. 적절한 이미지 크기 설정: width와 height를 지정하는 것이 가장 좋습니다. width: 100%; height: auto;와 함께 너비와 높이를 원하는 비율로 지정하면 브라우저가 aspect-ratio 속성을 통해 비율을 자동으로 맞춰주기도 합니다. 뷰포트 너비에 따라 다른 이미지를 제공하고자 할 때 srcset 속성을 사용하는 것도 좋은 방법이 될 수 있습니다.

<img srcset="image-1000.jpg 1000w, image-2000.jpg 2000w" alt="이미지" />

그 외의 성능 확인에 중요한 지표들

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

600ms 걸릴 경우 개선이 필요한 것으로 간주됩니다.

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

페이지 로드 시작 후 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정합니다.

1.8초 이내는 좋음, 3.0초 이내는 보통, 그 이후는 개선이 필요한 것으로 판단됩니다.

• TTFB 개선
• 렌더링 블로킹 리소스 최소화
• 최초 화면에 대한 최적화
• 리다이렉트 최소화
• DOM 크기 최소화