코어웹바이털이란 무엇인가

이 글은 구글 검색 엔진 최적화를 위한 시리즈 글로 코어웹바이털(Core Web Vitals)에 대한 내용입니다

코어웹바이털(Core Web Vitals)은 웹사이트의 실제 사용자의 로딩 속도를 빠르게 해 우수한 사용자 경험을 제공하기 위해 필수적인 메트릭스로, 비슷한 콘텐츠가 있을 경우 코어바이털이 좋은 페이지가 검색에 좀 더 노출됩니다

다만, 코어웹바이털은 구글의 수백가지 랭킹 요소 중에 하나라는 것입니다. 검색 랭킹 중 가장 중요한 것은 탁월한 콘텐츠라고 봐야 할 것입니다

코어웹바이털(Core Web Vitals)의 3가지 구성요소는 ▲ 페이지의 가장 큰 콘텐츠가 표시되는 로딩 성능 측정 시간(LCP) ▲사용자가 페이지와 처음 상호작용(링크 클릭, 버튼 탭 등)한 후부터 브라우저가 이를 응답해 시행하는데까지 걸리는 시간(FID) ▲ 페이지가 로딩되는 중 레이아웃이 이동하는 시각적 안정성의 정도(CLS)입니다

아래부터는 약간의 수학적 지식과 개발 지식이 있어야 이해할 수 있습니다. 저같은 수포자는 이해에 어려움이 있으나 나중을 위해 메모합니다

▲ 임계값과 75번째 백분위수 – 각 Core Web Vitals 메트릭에는 성능을 “양호(good)”, “개선 필요(needs improvement)” 또는 “나쁨(poor)”으로 분류하는 관련 임계값이 있습니다. – 추가적으로 페이지 또는 사이트의 전반적인 성능을 분류하기 위해 해당 페이지 또는 사이트에 대한 모든 페이지 조회수의 75번째 백분위수 값을 사용합니다. 즉, 사이트에 대한 페이지 조회수의 75% 이상이 “양호” 임계값을 충족하는 경우 해당 사이트는 해당 메트릭에 대해 “양호”한 성능을 보이는 것으로 간주됩니다. 반대로 페이지 보기의 25% 이상이 “나쁨” 임계값을 충족하면 해당 사이트의 성능은 “나쁜” 것으로 간주됩니다. 예를 들어 2초의 75번째 백분위수 LCP는 “양호”로 분류되고 5초의 75번째 백분위수 LCP는 “나쁨”으로 분류됩니다. ※ 임계값(threshold value) : 임계값은 어떤 통계가 상위인지, 하위인지, 또는 일반적인 범위인지를 정의하는 값을 의미함 ※ 백분위수(Percentile. 百分位數)는 크기가 있는 값들로 이뤄진 자료를 순서대로 나열했을 때 백분율로 나타낸 특정 위치의 값을 이르는 용어

구글 스피드 인사이트에서 웹사이트 속도와 코어웹바이털을 측정할 수 있습니다

※100 밀리초는 0.1초. 1 밀리초는 1천분의 1초

LCP : Largest contentful paint(최대 콘테츠 표시)

LCP는 페이지의 가장 큰 콘텐츠가 표시되는 로딩 성능 측정 시간으로 사용자가 감지하는 로딩 속도를 측정할 수 있는 중요한 사용자 중심 메트릭입니다

우수한 사용자 경험을 제공하려면 사이트의 최대 콘텐츠풀 페인트가 2.5초 이하여야 합니다. 대부분의 사용자에 대해 이 목표를 달성할 수 있도록 하려면 모바일 및 데스크톱 기기 전반에 분할된 페이지 로드의 75번째 백분위수를 측정하는 것이 바람직한 임계값입니다.

LCP가 빠르면 사용자가 해당 페이지를 사용할 수 있다고 인지하는데 도움이 됩니다

로드 또는 DOMContentLoaded와 같은 오래된 매트릭은 사용자가 화면에서 보는 것과 반드시 일치하지 않아 적절하지 않습니다

FCP(First Contentful Paint)와 같은 새로운 사용자 중심 성능 메트릭은 로딩 경험의 시작 부분만을 포착하는데 이는 사용자와 큰 관련이 있지 않습니다

현재 Largest Contentful Paint API에 지정된 대로, 최대 콘텐츠풀 페인트에 대해 고려되는 요소 유형은 다음과 같습니다.

• <img> 요소
• <svg> 요소 내부의 <image>
• <video> 요소(포스터 이미지 사용)
• url() 함수를 통해 로드된 배경 이미지가 있는 요소(CSS 그라데이션과는 대조적임)
• 텍스트 노드 또는 기타 인라인 수준 텍스트 하위 요소를 포함하는 블록 수준 요소

LCP는 아래와 같이 필드데이터를 현장에서 측정하거나 실험실에서 측정 가능합니다

현장 도구 #

• Chrome User Experience Report
• PageSpeed Insights
• Search Console(Core Web Vitals Report)
• web-vitals JavaScript 라이브러리

실험실 도구 #

• Chrome DevTools
• Lighthouse
• WebPageTest

LCP는 4가지 요인(느린 서버 응답 시간, JavaScript 및 CSS 렌더링 차단, 리소스 로드 시간, 클라이언트 측 렌더링)에 의해 영향을 받으며 LCP 최적화를 통해 개선 가능합니다

• PRPL 패턴으로 즉각적 로딩 적용
• 중요 렌더링 경로 최적화
• CSS 최적화
• 이미지 최적화
• 웹 글꼴 최적화
• JavaScript 최적화(클라이언트 렌더링 사이트용)

FID(First Input Delay: 최초 입력 지연)

FID는 사용자가 페이지와 처음 상호작용(링크 클릭, 버튼 탭 등)한 후부터 브라우저가 이를 시행하는데까지 걸리는 시간(FID)으로 최초 입력 지연 값이 0.1초(100 밀리초) 이하여야 합니다

대부분의 사용자에 대해 이 목표를 달성할 수 있도록 하려면 모바일 및 데스크톱 기기 전반에 분할된 페이지 로드의 75번째 백분위수를 측정하는 것이 바람직한 임계값이라고 합니다

페이지에서 일부 콘텐츠를 렌더링했지만 아직 안정적으로 상호 작용할 수 없는 상태이므로 일반적으로 긴 최초 입력 지연은 First Contentful Paint(최초 콘텐츠풀 페인트, FCP)와 Time to Interactive(상호 작용까지의 시간, TTI) 사이에 발생합니다.

FID를 개선하는 방법은 FID 최적화를 참고하시면 됩니다

• 타사 코드의 영향 줄이기
• JavaScript 실행 시간 단축
• 메인 스레드 작업 최소화
• 요청 수를 낮게 유지하고 전송 크기를 작게 유지

CLS : Cumulative Layout Shift(누적 레이아웃 이동)

CLS는 사용자가 예상치 못한 레이아웃 이동을 경험하는 빈도를 수량화하기 때문에 시각적 안정성을 측정할 때 중요한 사용자 중심 매트릭입니다

CLS가 낮으면 우수한 사용자 경험을 보장하는데 도움이 됩니다

우수한 사용자 경험을 제공하려면 사이트의 CLS 점수가 0.1 이하여야 합니다. 대부분의 사용자에 대해 이 목표를 달성할 수 있도록 하려면 모바일 및 데스크톱 기기 전반에 분할된 페이지 로드의 75번째 백분위수를 측정하는 것이 바람직한 임계값입니다.

페이지 콘텐츠의 예기치 않은 이동은 일반적으로 리소스가 비동기식으로 로드되거나 DOM 요소가 기존 콘텐츠 위의 페이지에 동적으로 추가되기 때문에 발생합니다.

원인은 알 수 없는 크기의 이미지나 동영상, 대체 크기보다 크거나 작게 렌더링되는 글꼴, 동적으로 크기가 조정되는 타사 광고 또는 위젯일 수 있습니다.

아래는 페이지 로딩 중 레이아웃이 이동해 사용자가 원치않는 버튼을 누르게 되는 CLS 문제점을 예시한 영상입니다

아래 영상은 구글 클립인데 임베딩이 안돼 제 유튜브에 삽입해 임베딩했습니다

CLS는 일반적으로 리소스가 비동기식으로 로드되거나 DOM 요소가 기존 콘텐츠 위의 페이지에 동적으로 추가되기 때문에 발생한다고 합니다

CLS를 개선하는 방법은 아래와 같습니다

• 이미지 및 비디오 요소에 항상 크기 속성을 포함하거나 CSS 가로 세로 비율 상자와 같은 방식으로 필요한 공간을 미리 확보하세요. 이러한 접근 방식을 사용하면 이미지가 로드되는 동안 브라우저가 문서에 올바른 양의 공간을 할당할 수 있습니다. unsized-media 기능 정책을 사용하여 기능 정책을 지원하는 브라우저에서 이 동작을 강제할 수도 있습니다.
• 사용자 상호 작용에 대한 응답을 제외하고는 기존 콘텐츠 위에 콘텐츠를 삽입하지 마세요. 이렇게 하면 레이아웃 이동이 발생하기 때문입니다.
• 레이아웃 변경을 트리거하는 속성의 애니메이션보다 전환 애니메이션을 사용하세요. 상태에서 상태로 컨텍스트와 연속성을 제공하는 방식으로 애니메이션 전환을 수행하는 것이 좋습니다.

CLS를 개선하는 방법에 대한 자세한 내용은 CLS 최적화 및 레이아웃 이동 디버그를 참조해주세요

코어웹바이털 측정 도구

코어웹바이털의 필드 측정 도구는 아래의 3가지가 있습니다

구글 페이지 스피드 인사이트 : 지난 28일 동안 집계된 페이지 수준 및 원본 수준 성능에 대해 보고하며 성능 개선 방법을 제안

구글 서치콘솔 웹바이털 보고서 : 지난 28일 동안 집계된 웹사이트의 실제 사용 데이터(필드 데이터)에 따른 페이지 성능을 보여주며 가장 믿을만 합니다

크롬 사용자 경험 리포트(Chrome UX) : 다양한 보고를 볼 수 있지만 개발 지식을 필요로 함. 선택한 출처에 대한 CrUX 데이터를 표시하는 사전 구축된 대시보드. Data Studio를 기반으로 구축되며 설정 프로세스는 약 1분 정도 소요. 구글 페이지 스피드 인사이트 및 서치콘솔과 비교했을 때 CrUX 대시보드 보고는 더 많은 차원을 포함. 예를 들면 데이터를 장치 및 연결 유형별로 분류 가능

코어웹바이털을 측정하기 위한 실험실 도구는 아래와 같습니다

LCP	FID	CLS
Chrome DevTools	✔	✘ (대신 TBT 사용)	✔
Lighthouse	✔	✘ (대신 TBT 사용)	✔

(끝)