현재 분석 도구로 웹 바이탈을 측정하는 방법
페이지의 실제 성능을 측정하고 보고할 수 있는 기능은 시간 경과에 따른 성능을 진단하고 개선하는 데 중요합니다. 필드 데이터가 없으면 사이트를 변경한 후 원하는 결과를 실제로 달성하는지 알 수 없습니다.
다수의 인기 실제 사용자 모니터링(RUM) 분석 제공업체는 이미 자체 도구에서 코어 웹 바이탈 측정항목 및 다른 여러 웹 바이탈을 지원하고 있습니다. 현재 이러한 RUM 분석 도구 중 하나를 사용하고 있다면 사이트의 페이지가 권장 코어 웹 바이탈 기준점을 얼마나 잘 충족하는지 평가하고 향후 회귀를 방지할 수 있습니다.
코어 웹 바이탈 측정항목을 지원하는 분석 도구를 사용하는 것이 좋지만 현재 사용 중인 분석 도구에서 지원하지 않는 경우 전환할 필요가 없습니다. 거의 모든 분석 도구에서 맞춤 측정항목 또는 이벤트를 정의하고 측정하는 방법을 제공합니다. 즉, 현재 분석 제공업체를 통해 코어 웹 바이탈 측정항목을 측정하고 이를 기존 분석 보고서와 대시보드에 추가할 수 있습니다.
이 가이드에서는 서드 파티 또는 사내 분석 도구로 코어 웹 바이탈 측정항목 (또는 맞춤 측정항목)을 측정하기 위한 권장사항을 설명합니다. 또한 서비스에 코어 웹 바이탈 지원을 추가하려는 분석 공급업체를 위한 가이드로 사용할 수도 있습니다.
맞춤 측정항목 또는 이벤트 사용
위에서 언급했듯이 대부분의 분석 도구를 사용하면 커스텀 데이터를 측정할 수 있습니다. 분석 도구에서 이를 지원하는 경우 이 메커니즘을 사용하여 각 Core Web Vitals 측정항목을 측정할 수 있습니다.
애널리틱스 도구에서 커스텀 측정항목 또는 이벤트를 측정하는 과정은 일반적으로 3단계로 이루어집니다.
- 도구의 관리자에서 커스텀 측정항목을 정의 또는 등록합니다 (필요한 경우). (참고: 일부 애널리틱스 제공업체에서는 커스텀 측정항목을 미리 정의할 필요가 없습니다.)
- 프런트엔드 자바스크립트 코드의 측정항목 값을 계산합니다.
- 이름 또는 ID가 1단계에서 정의한 것과 일치하는지 확인하여 측정항목 값을 분석 백엔드로 전송합니다(필요한 경우 다시 시도).
1단계와 3단계의 안내는 애널리틱스 도구의 문서를 참고하세요. 2단계에서는 web-vitals JavaScript 라이브러리를 사용하여 각 코어 웹 바이탈 측정항목의 값을 계산할 수 있습니다.
다음 코드 샘플은 코드에서 이러한 측정항목을 추적하고 분석 서비스로 전송하는 것이 얼마나 쉬운지 보여줍니다.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
평균 피하기
평균을 계산하여 성능 측정항목의 값 범위를 합산하고 싶을 수 있습니다. 평균은 대량의 데이터를 깔끔하게 요약한 것이므로 언뜻 보기에 편리해 보이지만 페이지 성능을 해석하기 위해 데이터에 의존하고 싶은 충동은 자제해야 합니다.
평균은 단일 사용자의 세션을 나타내지 않으므로 문제가 있습니다. 분포의 각 범위에 있는 이상치는 잘못된 방식으로 평균을 왜곡할 수 있습니다.
예를 들어 소수의 사용자가 최대 값 범위에 해당하는 매우 느린 네트워크나 기기를 사용할 수 있지만 문제가 있음을 암시하는 방식으로 평균에 영향을 미칠 만큼 충분한 사용자 세션을 고려하지 않을 수 있습니다.
가능하면 평균이 아닌 백분위수를 사용하세요. 특정 성능 측정항목의 분포에 대한 백분위수는 웹사이트의 전체 사용자 환경을 더 잘 설명합니다. 이를 통해 실제 경험의 하위 집합에 초점을 맞출 수 있으므로 그 어느 때보다 더 많은 유용한 정보를 얻을 수 있습니다.
분포를 보고할 수 있는지 확인
각 코어 웹 바이탈 측정항목의 값을 계산하고 맞춤 측정항목 또는 이벤트를 사용하여 분석 서비스로 전송했다면 다음 단계는 수집된 값을 표시하는 보고서 또는 대시보드를 빌드하는 것입니다.
권장 코어 웹 바이탈 기준을 충족하려면 75번째 백분위수에서 각 측정항목의 값을 표시하는 보고서가 필요합니다.
분석 도구가 분위수 보고를 기본 제공 기능으로 제공하지 않는 경우에도 모든 측정항목 값이 오름차순으로 나열된 보고서를 생성하여 이 데이터를 수동으로 가져올 수 있습니다. 이 보고서가 생성되면 이 보고서에 있는 모든 값의 정렬된 전체 목록의 75% 에 해당하는 결과가 해당 측정항목의 75번째 백분위수가 됩니다. 이는 데이터를 분류 (기기 유형, 연결 유형, 국가 등)하는 방법과 관계없이 적용됩니다.
분석 도구가 기본적으로 측정항목 수준 보고 세부사항을 제공하지 않는 경우 애널리틱스 도구에서 맞춤 측정기준을 지원하면 동일한 결과를 얻을 수 있습니다. 추적하는 개별 측정항목 인스턴스마다 고유한 맞춤 측정기준 값을 설정하면 보고서 구성에 맞춤 측정기준을 포함하면 개별 측정항목 인스턴스별로 분류된 보고서를 생성할 수 있습니다. 각 인스턴스는 고유한 측정기준 값을 가지므로 그룹화는 발생하지 않습니다.
Google 애널리틱스를 사용하는 기법의 예로 웹 바이탈 보고서가 있습니다. 보고서 코드는 오픈소스이므로 개발자는 이 섹션에서 설명하는 기술의 예로 이를 참조할 수 있습니다.
적시에 데이터 전송
일부 성능 측정항목은 페이지 로드가 완료된 후에 계산될 수 있으며, 다른 일부 성능 측정항목 (예: CLS)은 페이지의 전체 수명을 고려하며 페이지 로드 취소가 시작된 후에만 계산할 수 있습니다.
하지만 beforeunload 및 unload 이벤트는 모두 신뢰할 수 없고(특히 모바일에서) 페이지에 백앞으로 캐시가 사용되지 않도록 할 수 있으므로 사용하지 않는 것이 좋습니다.
페이지의 전체 수명을 추적하는 측정항목의 경우 페이지의 공개 상태 상태가 hidden로 변경될 때마다 visibilitychange 이벤트 중에 측정항목의 현재 값을 전송하는 것이 가장 좋습니다. 페이지의 공개 상태 상태가 hidden로 변경되면 해당 페이지의 스크립트가 다시 실행될 수 있다는 보장이 없기 때문입니다. 페이지 콜백이 실행되지 않고 브라우저 앱 자체를 닫을 수 있는 모바일 운영체제에서는 특히 더 그렇습니다.
모바일 운영체제에서는 일반적으로 탭을 전환하거나 앱을 전환하거나 브라우저 앱 자체를 닫을 때 visibilitychange 이벤트를 실행합니다.
또한 탭을 닫거나 새 페이지로 이동할 때 visibilitychange 이벤트를 실행합니다. 따라서 visibilitychange 이벤트가 unload 또는 beforeunload 이벤트보다 훨씬 더 안정적입니다.
기간별 실적 모니터링
코어 웹 바이탈 측정항목을 추적하고 보고하도록 분석 구현을 업데이트했다면 다음 단계는 사이트 변경사항이 시간 경과에 따라 실적에 미치는 영향을 추적하는 것입니다.
변경사항 버전 지정
변경사항 추적의 단순하지만 궁극적으로 신뢰할 수 없는 접근 방식은 프로덕션에 변경사항을 배포한 다음 배포 날짜 이후에 수신된 모든 측정항목이 새 사이트와 일치하고 배포 날짜 전에 수신된 모든 측정항목이 이전 사이트와 일치한다고 가정하는 것입니다. 하지만 여러 가지 요인(HTTP, 서비스 워커 또는 CDN 레이어에서의 캐싱 포함)으로 인해 이 기능이 작동하지 않을 수 있습니다.
훨씬 더 나은 접근 방식은 배포된 각 변경사항에 대해 고유한 버전을 만든 다음 애널리틱스 도구에서 해당 버전을 추적하는 것입니다. 대부분의 분석 도구는 버전 설정을 지원합니다. 그렇지 않은 경우 맞춤 측정기준을 만들고 이 측정기준을 배포된 버전으로 설정할 수 있습니다.
실험하기
여러 버전 (또는 실험)을 동시에 추적하여 버전 관리를 한 단계 더 높일 수 있습니다.
분석 도구에서 실험 그룹을 정의할 수 있는 경우 해당 기능을 사용하세요. 또는 맞춤 측정기준을 사용하여 각 측정항목 값을 보고서의 특정 실험 그룹과 연결할 수 있습니다.
애널리틱스에 실험을 적용하면 일부 사용자에게 실험 변경사항을 적용하고 해당 변경사항의 실적을 통제그룹의 사용자 실적과 비교할 수 있습니다. 변경사항이 실제로 성능을 개선한다는 확신이 들면 모든 사용자에게 적용할 수 있습니다.
측정이 실적에 영향을 미치지 않도록 하기
실제 사용자의 성능을 측정할 때는 실행 중인 성능 측정 코드가 페이지 성능에 부정적인 영향을 미치지 않는 것이 매우 중요합니다. 만약 그렇다면 애널리틱스 코드 자체의 존재가 가장 큰 부정적인 영향을 미치는지 알 수 없기 때문에 성과가 비즈니스에 미치는 영향을 파악하는 모든 결론은 신뢰할 수 없을 것입니다.
프로덕션 사이트에 RUM 분석 코드를 배포할 때는 항상 다음 원칙을 따르세요.
분석 연기
애널리틱스 코드는 항상 비동기적이고 차단되지 않는 방식으로 로드되어야 하며 일반적으로는 마지막에 로드되어야 합니다. 차단 방식으로 분석 코드를 로드하면 LCP에 부정적인 영향을 미칠 수 있습니다.
코어 웹 바이탈 측정항목을 측정하는 데 사용되는 모든 API는 buffered 플래그를 통해 비동기 및 지연된 스크립트 로드를 지원하도록 특별히 설계되었으므로 스크립트를 조기에 로드하기 위해 서두를 필요가 없습니다.
페이지 로드 타임라인의 후반에 계산할 수 없는 측정항목을 측정하는 경우 문서의 <head>에서 초기에 실행해야 하는 코드만 인라인으로 삽입하고 (렌더링 차단 요청이 아님) 나머지는 연기해야 합니다. 하나의 측정항목에 꼭 필요하다고 해서 모든 분석을 조기에 로드하지는 마세요.
긴 작업 만들지 않기
애널리틱스 코드는 사용자 입력에 대한 응답으로 실행되는 경우가 많지만 애널리틱스 코드에서 많은 DOM 측정을 수행하거나 프로세서를 많이 사용하는 다른 API를 사용하는 경우 분석 코드 자체로 인해 입력 반응성이 저하될 수 있습니다. 또한 분석 코드가 포함된 자바스크립트 파일이 큰 경우 이 파일을 실행하면 기본 스레드가 차단되고 첫 입력 지연 (FID) 또는 다음 페인트에 대한 상호작용 (INP)에 부정적인 영향을 미칠 수 있습니다.
비차단 API 사용
sendBeacon() 및 requestIdleCallback()와 같은 API는 사용자에게 중요한 작업을 차단하지 않는 방식으로 중요하지 않은 작업을 실행하도록 특별히 설계되었습니다.
이러한 API는 RUM 분석 라이브러리에서 사용하기에 좋은 도구입니다.
일반적으로 모든 분석 비콘은 sendBeacon() API(사용 가능한 경우)를 사용하여 전송해야 하며 모든 수동적 분석 측정 코드는 유휴 기간 중에 실행되어야 합니다.
필요한 만큼만 추적하지 않음
브라우저는 많은 성능 데이터를 노출하지만 데이터를 사용할 수 있다고 해서 반드시 데이터를 기록하여 애널리틱스 서버로 전송해야 하는 것은 아닙니다.
예를 들어 Resource Timing API는 페이지에 로드된 모든 단일 리소스에 대한 자세한 타이밍 데이터를 제공합니다. 하지만 이러한 모든 데이터가 리소스 로드 성능을 개선하는 데 반드시 필요하거나 유용할 가능성은 낮습니다.
간단히 말하면, 데이터가 존재한다는 이유만으로 데이터를 추적하는 것이 아니라, 추적하는 리소스를 소비하기 전에 데이터를 사용할 수 있는지 확인해야 합니다.