이 페이지는 Cloud Translation API를 통해 번역되었습니다.

현장에서 웹 바이탈을 측정하기 위한 권장사항

현재 분석 도구로 웹 바이탈을 측정하는 방법

Philip Walton

페이지의 실제 실적을 측정하고 보고하는 기능은 시간 경과에 따른 실적을 진단하고 개선하는 데 매우 중요합니다. 현장 데이터가 없으면 사이트에 적용한 변경사항이 실제로 원하는 결과를 얻고 있는지 확실히 알 수 없습니다.

많은 인기 실제 사용자 모니터링(RUM) 분석 제공업체는 이미 도구에서 기타 여러 웹 바이탈과 함께 Core Web Vitals 측정항목을 지원하고 있습니다. 현재 이러한 RUM 분석 도구 중 하나를 사용하고 있다면 사이트의 페이지가 권장되는 Core Web Vitals 기준을 얼마나 잘 충족하는지 평가하고 향후 회귀를 방지할 수 있습니다.

Core Web Vitals 측정항목을 지원하는 분석 도구를 사용하는 것이 좋지만 현재 사용 중인 분석 도구에서 이를 지원하지 않는 경우에는 전환하지 않아도 됩니다. 거의 모든 분석 도구에서 커스텀 측정항목 또는 이벤트를 정의하고 측정할 수 있습니다. 즉, 현재 분석 제공업체를 통해 Core Web Vitals 측정항목을 측정하고 기존 분석 보고서 및 대시보드에 추가할 수 있습니다.

이 가이드에서는 서드 파티 또는 사내 분석 도구로 Core Web Vitals 측정항목(또는 맞춤 측정항목)을 측정하기 위한 권장사항을 설명합니다. Core Web Vitals 지원을 서비스에 추가하려는 분석 공급업체를 위한 가이드 역할도 합니다.

맞춤 측정항목 또는 이벤트 사용

위에서 언급했듯이 대부분의 분석 도구를 사용하면 맞춤 데이터를 측정할 수 있습니다. 애널리틱스 도구에서 이를 지원하는 경우 이 메커니즘을 사용하여 각 Core Web Vitals 측정항목을 측정할 수 있습니다.

애널리틱스 도구에서 맞춤 측정항목 또는 이벤트를 측정하는 방법은 일반적으로 다음과 같은 3단계로 진행됩니다.

필요한 경우 도구의 관리자에서 맞춤 측정항목을 정의하거나 등록합니다. (참고: 일부 분석 제공업체에서는 사전에 맞춤 측정항목을 정의해야 할 필요가 없습니다.)
프런트엔드 JavaScript 코드에서 측정항목의 값을 계산합니다.
측정항목 값을 애널리틱스 백엔드로 전송합니다. 이름 또는 ID가 1단계에서 정의된 것과 일치하는지 확인합니다. 필요한 경우 다시

1단계와 3단계의 경우 애널리틱스 도구의 문서를 참고하세요. 2단계에서는 web-vitals 자바스크립트 라이브러리를 사용하여 각 Core Web Vitals 측정항목의 값을 계산할 수 있습니다.

다음 코드 샘플은 코드에서 이러한 측정항목을 쉽게 추적하고 분석 서비스로 전송하는 방법을 보여줍니다.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

평균 피하기

평균을 계산하여 성능 측정항목의 값 범위를 합산하고 싶은 유혹이 들 수 있습니다. 평균은 많은 양의 데이터를 깔끔하게 요약한 것이기 때문에 언뜻 보기에는 편리해 보일 수 있지만 페이지 성능을 해석하기 위해 평균값을 사용해서는 안 됩니다.

평균은 단일 사용자의 세션을 나타내지 않으므로 문제가 있습니다. 각 분포 범위에 있는 이상점이 오해의 소지가 있는 방식으로 평균을 왜곡할 수 있습니다.

예를 들어 소수의 사용자가 최대 값 범위에 근접한 매우 느린 네트워크나 기기를 사용할 수 있지만 문제가 있음을 시사하는 방식으로 평균에 영향을 미칠 만큼 충분한 사용자 세션은 고려하지 않을 수 있습니다.

가능하면 평균 대신 백분위수를 사용하세요. 특정 실적 측정항목의 분포에서 퍼센티일은 웹사이트의 모든 사용자 환경을 더 잘 설명합니다. 이를 통해 실제 환경의 하위 집합에 집중할 수 있으므로 단일 값보다 더 많은 유용한 정보를 얻을 수 있습니다.

배포를 보고할 수 있는지 확인

각 Core Web Vitals 측정항목의 값을 계산하고 맞춤 측정항목 또는 이벤트를 사용하여 애널리틱스 서비스로 전송한 후에는 수집된 값을 표시하는 보고서 또는 대시보드를 빌드해야 합니다.

권장 Core Web Vitals 기준을 충족하려면 각 측정항목의 값을 75번째 백분위수로 표시하는 보고서가 필요합니다.

분석 도구에서 분위수 보고를 기본 제공하지 않는 경우에도 모든 측정항목 값을 오름차순으로 정렬하여 나열하는 보고서를 생성하여 이 데이터를 수동으로 가져올 수 있습니다. 이 보고서가 생성되면 보고서의 정렬된 모든 값 목록에서 75% 지점의 결과가 해당 측정항목의 75번째 백분위수가 됩니다. 이는 데이터를 세분화하는 방식(기기 유형, 연결 유형, 국가 등)과 관계없이 동일하게 적용됩니다.

분석 도구에서 기본적으로 측정항목 수준의 보고 세부사항을 제공하지 않는 경우 분석 도구에서 맞춤 측정기준을 지원하는 경우 동일한 결과를 얻을 수 있습니다. 추적하는 측정항목 인스턴스마다 고유한 맞춤 측정기준 값을 설정하면 보고서 구성에 맞춤 측정기준을 포함한 경우 개별 측정항목 인스턴스별로 분류된 보고서를 생성할 수 있습니다. 각 인스턴스에는 고유한 측정기준 값이 있으므로 그룹화되지 않습니다.

웹 바이탈 보고서는 Google 애널리틱스를 사용하는 이 기법의 한 예입니다. 보고서의 코드는 오픈소스이므로 개발자는 이 섹션에 설명된 기법의 예로 참조할 수 있습니다.

웹 Vitals 보고서 스크린샷

적시에 데이터 전송

일부 성능 측정항목은 페이지 로드가 완료된 후에 계산할 수 있지만, CLS와 같은 다른 측정항목은 페이지의 전체 수명을 고려하며 페이지의 언로드가 시작된 후에만 최종적으로 결정됩니다.

그러나 beforeunload 및 unload 이벤트는 둘 다 신뢰할 수 없고 (특히 모바일에서) 이 이벤트 사용은 권장되지 않습니다(페이지가 뒤로-앞으로 캐시를 사용할 수 없도록 할 수 있으므로) 권장되지 않습니다.

페이지의 전체 수명을 추적하는 측정항목의 경우 페이지의 표시 상태가 hidden로 변경될 때마다 visibilitychange 이벤트 중에 측정항목의 현재 값을 전송하는 것이 가장 좋습니다. 페이지의 가시성 상태가 hidden로 변경되면 해당 페이지의 스크립트를 다시 실행할 수 있다는 보장이 없기 때문입니다. 이는 특히 페이지 콜백이 실행되지 않고 브라우저 앱 자체가 닫힐 수 있는 휴대기기 운영체제에서 그렇습니다.

모바일 운영체제는 일반적으로 탭을 전환하거나 앱을 전환하거나 브라우저 앱 자체를 닫을 때 visibilitychange 이벤트를 실행합니다. 또한 탭을 닫거나 새 페이지로 이동할 때 visibilitychange 이벤트가 실행됩니다. 따라서 visibilitychange 이벤트는 unload 또는 beforeunload 이벤트보다 훨씬 안정적입니다.

일부 브라우저 버그로 인해 visibilitychange 이벤트가 실행되지 않는 경우가 있습니다. 자체 분석 라이브러리를 빌드하는 경우 이러한 버그를 인지하는 것이 중요합니다. web-vitals JavaScript 라이브러리가 이러한 모든 버그를 처리합니다.

기간별 실적 모니터링

Core Web Vitals 측정항목을 추적하고 보고하도록 분석 구현을 업데이트했다면 다음 단계는 사이트 변경사항이 시간 경과에 따라 성능에 미치는 영향을 추적하는 것입니다.

변경사항 버전 지정

변경사항을 추적하는 순진하고 궁극적으로는 신뢰할 수 없는 접근 방식은 변경사항을 프로덕션에 배포한 다음 배포 날짜 이후에 수신된 모든 측정항목이 새 사이트에 해당하고 배포 날짜 이전에 수신된 모든 측정항목이 이전 사이트에 해당한다고 가정하는 것입니다. 그러나 HTTP, 서비스 워커 또는 CDN 레이어의 캐싱을 비롯한 여러 요인으로 인해 이 기능이 작동하지 않을 수 있습니다.

배포된 각 변경사항에 고유한 버전을 만든 다음 애널리틱스 도구에서 해당 버전을 추적하는 것이 훨씬 좋습니다. 대부분의 분석 도구는 버전 설정을 지원합니다. 그렇지 않은 경우 커스텀 측정기준을 만들고 해당 측정기준을 배포된 버전으로 설정할 수 있습니다.

실험하기

여러 버전(또는 실험)을 동시에 추적하여 버전 관리를 한 단계 업그레이드할 수 있습니다.

애널리틱스 도구에서 실험 그룹을 정의할 수 있는 경우 해당 기능을 사용합니다. 또는 맞춤 측정기준을 사용하여 각 측정항목 값을 보고서의 특정 실험 그룹과 연결할 수 있습니다.

애널리틱스에 실험을 설정하면 일부 사용자를 대상으로 실험 변경사항을 출시하고 해당 변경사항의 실적을 대조군 사용자의 실적과 비교할 수 있습니다. 변경사항이 실제로 성능을 개선한다는 확신이 들면 모든 사용자에게 적용할 수 있습니다.

측정이 실적에 영향을 미치지 않도록 합니다.

실제 사용자의 성능을 측정할 때는 실행 중인 성능 측정 코드가 페이지의 성능에 부정적인 영향을 미치지 않도록 하는 것이 매우 중요합니다. 이 경우 분석 코드 자체가 가장 큰 부정적인 영향을 미치는지 알 수 없으므로 실적이 비즈니스에 미치는 영향에 관한 결론을 도출하려고 해도 신뢰할 수 없습니다.

프로덕션 사이트에 RUM 분석 코드를 배포할 때는 항상 다음 원칙을 따르세요.

분석 연기

애널리틱스 코드는 항상 비차단 방식으로 비동기식으로 로드되어야 하며, 일반적으로 가장 마지막에 로드되어야 합니다. 분석 코드를 차단 방식으로 로드하면 LCP에 부정적인 영향을 미칠 수 있습니다.

Core Web Vitals 측정항목을 측정하는 데 사용되는 모든 API는 buffered 플래그를 통해 비동기 및 지연된 스크립트 로드를 지원하도록 특별히 설계되었으므로 스크립트를 일찍 로드하기 위해 서두를 필요가 없습니다.

나중에 페이지 로드 타임라인에서 계산할 수 없는 측정항목을 측정하는 경우 문서의 <head>에서 초기에 실행해야 하는 코드만 인라인으로 삽입하고 (렌더링 차단 요청이 아님) 나머지는 연기해야 합니다. 단일 측정항목에 필요한 이유만으로 모든 분석을 일찍 로드하지 마세요.

긴 작업 만들지 않기

애널리틱스 코드는 사용자 입력에 대한 응답으로 실행되는 경우가 많지만 애널리틱스 코드가 많은 수의 DOM 측정을 실행하거나 프로세서 집약적인 다른 API를 사용하는 경우 애널리틱스 코드 자체로 인해 입력 응답이 느려질 수 있습니다. 또한 애널리틱스 코드가 포함된 JavaScript 파일이 큰 경우 이 파일을 실행하면 기본 스레드가 차단되고 페이지의 다음 페인트까지의 상호작용(INP)에 부정적인 영향을 미칠 수 있습니다.

비차단 API 사용

sendBeacon() 및 requestIdleCallback()와 같은 API는 사용자에게 중요한 작업을 차단하지 않는 방식으로 중요하지 않은 작업을 실행하도록 특별히 설계되었습니다.

이러한 API는 RUM 분석 라이브러리에서 사용할 수 있는 유용한 도구입니다.

일반적으로 모든 분석 비콘은 sendBeacon() API(사용 가능한 경우)를 사용하여 전송해야 하며 모든 수동 분석 측정 코드는 유휴 기간에 실행해야 합니다.

필요 이상으로 추적하지 않음

브라우저는 많은 성능 데이터를 노출하지만 데이터를 사용할 수 있다고 해서 반드시 기록하여 분석 서버로 전송해야 하는 것은 아닙니다.

예를 들어 Resource Timing API는 페이지에 로드된 모든 리소스에 대한 세부적인 타이밍 데이터를 제공합니다. 그러나 이러한 모든 데이터가 리소스 로드 성능을 개선하는 데 반드시 필요하거나 유용하지는 않습니다.

즉, 데이터가 존재하기 때문에 단순히 데이터를 추적하는 것이 아니라 데이터를 추적하는 리소스를 사용하기 전에 데이터가 사용되도록 해야 합니다.