구글에서 만든 지표로 핵심 웹 지표(Core Web Vital)가 있습니다. 이것은 웹사이트에서 뛰어난 사용자 경험을 제공하는 데 필수적인 지표를 일컫는 용어입니다. 구글에서 핵심 웹 지표로 꼽는 지표는 다음과 같습니다.
- 최대 콘텐츠풀 페인트(LCP: Largest Contentful Paint)
- 최초 입력 지연(FID: First Input Delay)
- 누적 레이아웃 이동(CLS: Cumulative Layout Shift)
그리고 다음 두 지표는 핵심까지는 아니지만, 특정 문제를 진단하는 데 사용될 수 있습니다.
- 최초 바이트까지의 시간(TTTB: Time To First Byte)
- 최초 콘텐츠풀 시간(FCP: First Contentful Paint)
최대 콘텐츠풀 페인트(Largest Contentful Paint, LCP)
페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에서 가장 큰 이미지 또는 텍스트를 렌더링 하는 데 걸리는 시간입니다. 뷰포트는 사용자에게 현재 노출되는 화면을 의미하고, 위에서 의미하는 '큰 이미지와 텍스트'는 다음과 같이 정의되어 있습니다.
- <img>
- <svg> 내부의 <image>
- poster 속성을 사용하는 <video>
- url()을 통해 불러온 배경 이미지가 있는 요소
- 텍스트와 같이 인라인 텍스트 요소를 포함하고 있는 블록 레벨 요소
- 이 블록 레벨 요소에는 <p>, <div> 등이 포함
기준 점수
최대 콘텐츠풀 페인트에서 좋은 점수란 해당 지표가 2.5초 내로 응답이 오는 것입니다. 4초 이내로 응답이 온다면 보통, 그 이상이 걸리면 나쁨으로 판단됩니다.
개선 방안
- 텍스트는 언제나 옳습니다.
- LCP에서 좋은 점수를 얻는 가장 확실한 방법은 뷰포트 최대 영역, 즉 LCP 예상 영역에서 이미지가 아닌 문자열을 넣는 것입니다. 아무래도 이미지보다 텍스트 노출이 훨씬 더 빠르기 때문입니다.
- 이미지는 어떻게 불러올 것인가요?
- <img>: 이미지는 브라우저의 프리로드 스캐너에 의해서 먼저 발견되어 빠르게 요청이 일어납니다. 프리로드 스캐너란 HTML을 파싱 하는 단계를 차단하지 않고 이미지와 같이 빠르게 미리 로딩하면 좋은 리소스를 먼저 찾아 로딩하는 브라우저의 기능입니다. 따라서 <img>로 LCP 요소를 불러오기에는 적절하다고 할 수 있습니다. 이는 <picture>도 마찬가지입니다.
- background-image: url(): background-image를 비롯해서 CSS에 있는 리소스는 항상 느립니다. 그러므로 가능하다면 background-image는 LCP와 같이 중요한 리소스에는 사용하지 않는 것이 좋습니다.
- loading=lazy 주의: loading=lazy는 리소스를 중요하지 않음으로 표시하고 필요할 때만 로드하는 전략으로 <img>, <iframe> 등에 적용할 수 있지만 문제는 최대 콘텐츠풀 콘텐츠의 이미지는 중요하지 않은 리소스로 분류해서는 안된다는 것입니다. 이는 그저 로딩 속도만 늦출 뿐 지표 점수에는 도움이 되지 않습니다. 상대적으로 중요하지 않은 이미지에서는 사용해도 좋지만 LCP의 이미지에는 사용하지 않는 것이 좋습니다.
최초 입력 지연(First Input Delay, FID)
사용자가 얼마나 빠르게 웹페이지와의 상호작용에 대한 응답을 받을 수 있는지 측정하는 지표입니다. 모든 입력에 대해 측정하는 것이 아니며, 최초의 입력 하나에 대해서만 그 응답 지연이 얼마나 걸리는지 판단합니다.
웹사이트 내부의 이벤트가 반응이 늦어지는 이유는 무엇일까요?
바로 브라우저의 메인 스레드가 바쁘기 때문입니다. 무언가 대규모 렌더링이 일어나고 있거나, 대규모 자바스크립트 파일을 분석하고 실행하는 등 다른 작업을 처리하는 데 리소스를 할애하고 있기 때문입니다. 이렇게 메인 스레드가 바쁜 경우, 자바스크립트 실행 환경은 '싱글 스레드'이기 때문에 자바스크립트가 이벤트 리스너와 같은 다른 작업을 실행할 수 없어 지연이 발생합니다.
기준 점수
FID의 좋은 점수를 얻기 위해서는 100ms 이내로 응답이 와야 하며, 300ms 이내인 경우 보통, 그 이후의 경우에는 나쁨으로 처리됩니다.
개선 방안
- 자바스크립트 코드 최소화
- 실행에 오래 걸리는 긴 작업을 분리
- 꼭 웹페이지에서 해야 하는 작업인지 확인
- 긴 작업을 여러 개로 분리
누적 레이아웃 이동(Cumulative Layout Shift, CLS)
페이지의 생명주기 동안 발생하는 모든 예기치 않은 이동에 대한 지표를 계산하는 것입니다. 클라이언트에서 미리 노출이 예상되는 부분을 HTML로 자리 잡아 두는 것이 CLS 지표에 큰 도움이 됩니다.
기준 점수
CLS의 경우 0.1 이하인 경우 좋음, 0.25 이하인 경우 보통이며 그 외에는 개선이 필요한 나쁜 점수로 보고됩니다.
개선 방안
- 삽입이 예상되는 요소를 위한 추가적인 공간 확보
- 폰트 로딩 최적화
- FOUT 해결: HTML 문서에서 지정한 폰트가 보이지 않고 대체 기본 폰트로 보이고 있다가 뒤늦게 폰트가 적용되는 현상
- FOIT 해결: HTML 문서에서 지정한 폰트가 보이지 않고, 기본 폰트도 없어서 텍스트가 없는 채로 있다가 뒤늦게 폰트가 로딩되면서 페이지에 렌더링되는 현상
- <link>의 preload 사용: preload로 지정된 요소는 웹페이지의 생명주기에서 초기에 불러와야 하는 중요한 리소스로 간주되므로 브라우저는 리소스를 더 빠르게 사용할 수 있도록 준비해 줍니다.
- 적절한 이미지 크기 설정
- width, height 지정
최초 콘텐츠풀 페인트(First Contentful Paint, FCP)
페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링 될 때까지의 시간을 측정
즉, 웹사이트에 접속한 순간부터 페이지에 텍스트, 이미지 등이 뜨기 시작한 시점까지의 시간을 의미합니다.
기준 점수
일반적으로 FCP는 1.8초 이내에 이뤄진다면 좋음, 3.0초 이내는 보통, 그 이후는 개선이 필요한 것으로 보고됩니다.
개선 방안
- TTFB 개선
- 렌더링을 가로막는 리소스 최소화
- 페이지 리다이렉트 최소화
- DOM 크기 최소화
최초 바이트까지의 시간(Timte To First Byte, TTFB)
브라우저가 웹 페이지의 첫 번째 바이트를 수신하는 데 걸리는 시간을 의미
즉, 페이지를 요청했을 때 최초의 응답이 오는 바이트까지가 얼마나 걸리는지를 측정하는 지표입니다.
개선 방안
- 웹페이지의 주된 방문객의 국적을 파악해 최대한 해당 국적과 가깝게 서버를 위치시키는 것이 좋습니다. 응답해야 할 서버가 사용자가 가까울수록 응답 속도가 빨라지기 때문입니다.
- ex) aws의 ap-northeast-2(서울)
- 서버 사이드 렌더링을 수행하고 있다면
- 로직을 최적화해 페이지를 최대한 빨리 준비시켜야 합니다.
- 페이지를 만드는 데 필요한 작업을 최소화하고, 페이지를 그리는 데 중요한 내용만 서버 사이드 렌더링에서 준비하는 등의 최적화가 필요합니다.
References
https://web.dev/articles/lcp?hl=ko
React Deep Dive
'1. 웹개발 > 1_1_5 React JS' 카테고리의 다른 글
[React] 컴포넌트 합성이란? (0) | 2024.07.06 |
---|---|
[React] Flux 패턴과 Elm 아키텍처 (0) | 2024.05.18 |
[React] forwardRef와 useImperativeHandle 훅이란? (0) | 2024.05.01 |
[React] 커스텀훅 vs 고차 컴포넌트 (0) | 2024.04.27 |
[React] useLayoutEffet와 useEffect (0) | 2024.04.20 |