현재 사용 중인 분석 도구로 웹 바이탈을 측정하는 방법
캠페인의 실제 실적을 측정하고 보고할 수 있다면 페이지는 실적을 진단하고 시간이 지남에 따라 개선하는 데 매우 중요합니다. 제외 필드 데이터, 사이트가 변경되고 있는지 확실히 알 수는 없습니다. 실제로 원하는 결과를 달성하고 있는지 확인하세요.
여러 인기 실제 사용자 모니터링 (RUM) 분석 제공업체 이미 Google Workspace에서 Core Web Vitals 측정항목을 (많은 다른 Web Vitals 포함) 만약 현재 이러한 RUM 분석 도구 중 하나를 사용하고 있다면 사이트의 페이지가 권장 Core Web Vitals를 얼마나 잘 충족하는지 평가합니다. 성능 저하를 방지하며 있습니다.
Core Web Vitals를 지원하는 분석 도구를 사용하는 것이 좋지만 현재 사용 중인 분석 도구에서 지원하지 않는 경우에는 반드시 전환할 필요는 없습니다 거의 모든 분석 도구는 맞춤 측정항목 또는 이벤트입니다. 현재 분석 제공업체를 통해 Core Web Vitals를 측정할 가능성이 큽니다 기존 애널리틱스 보고서 및 대시보드에 추가할 수 있습니다.
이 가이드에서는 서드 파티 또는 사내 분석 도구로 Core Web Vitals 측정항목 (또는 모든 맞춤 측정항목)을 측정하기 위한 권장사항을 설명합니다. Core Web Vitals 지원을 서비스에 추가하려는 분석 공급업체를 위한 가이드 역할도 합니다.
맞춤 측정항목 또는 이벤트 사용
위에서 언급했듯이 대부분의 분석 도구에서는 맞춤 데이터를 측정할 수 있습니다. 만약 지원하는 경우 각 코어 웹 및 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 애널리틱스를 사용하는 이 기법의 한 예입니다. 이 보고서는 오픈소스입니다. 개발자가 이 섹션에서 설명하는 기술의 예로 이를 참고할 수 있습니다. 섹션으로 이동합니다.
적시에 데이터 전송
일부 실적 측정항목은 페이지 로드가 완료되면 계산될 수 있습니다. 반면에 다른 URL (예: CLS)은 페이지의 전체 수명을 고려하며 종료: 페이지 로드 취소를 시작함
하지만 beforeunload 및 unload가 모두 작동하므로 문제가 될 수 있습니다.
이벤트가 안정적이지 않고 (특히 모바일에서) 사용되는 방식이
권장
(페이지가 뒤로-앞으로
캐시).
페이지의 전체 수명을 추적하는 측정항목의 경우
측정항목의 현재 값은 visibilitychange 이벤트 중의 값이며
페이지의 공개 상태가 hidden로 변경됩니다. 페이지가
공개 상태 상태가 hidden로 변경됩니다. 의 스크립트가
해당 페이지가 다시 실행될 수 있습니다. 이는 특히 모바일 운영 환경에서
페이지 콜백 없이 브라우저 앱 자체를 닫을 수 있는 시스템
있습니다.
모바일 운영체제는 일반적으로 visibilitychange
이벤트가 발생할 때 발생합니다.
또한 탭을 닫거나visibilitychange
생성할 수 있습니다. 이렇게 하면 visibilitychange 이벤트가
unload 또는 beforeunload 이벤트
기간별 실적 모니터링
추적 및 보고가 모두 가능하도록 애널리틱스 구현을 업데이트한 후 Core Web Vitals 측정항목을 사용했다면 다음 단계는 사이트의 변경사항을 성능에 미치는 영향을 최소화합니다
변경사항 버전 관리하기
변경사항 추적에 대한 단순하고 궁극적으로는 신뢰할 수 없는 접근 방식으로 이후 모든 측정항목이 배포 날짜는 새 사이트 및 배포 날짜가 이전 사이트에 해당합니다. 하지만 어떤 요인이든 (HTTP, 서비스 워커 또는 CDN 계층에서의 캐싱 포함)로 인해 도움이 될 수 있습니다
훨씬 더 나은 접근 방식은 배포된 각 변경사항에 대해 고유한 버전을 만드는 것입니다. 분석 도구에서 버전을 추적합니다. 대부분의 분석 도구는 버전을 설정하는 것입니다. 그렇지 않은 경우 맞춤 측정기준을 만들고 해당 측정기준을 배포된 버전에 추가합니다
실험하기
여러 버전을 추적하여 버전 관리를 한 단계 더 발전시킬 수 있습니다. 동시에 사용할 수 있습니다.
애널리틱스 도구에서 실험 그룹을 정의할 수 있는 경우 해당 기능을 사용합니다. 또는 맞춤 측정기준을 사용하여 각 측정항목 값을 보장할 수 있습니다. 보고서에서 특정 실험 그룹과 연결할 수 있습니다.
애널리틱스에서 실험을 진행하면 이제 '실험 변경사항'을 적용하고 실적을 실적 변동 추이를 확인할 수 있습니다 kubectl 명령어를 변경사항이 실제로 실적 개선에 도움이 된다는 확신을 주면 모든 사용자에게 적용됩니다
측정이 성능에 영향을 미치지 않는지 확인하기
실제 사용자에 대한 실적을 측정할 때는 실적 측정 코드가 확인할 수 있습니다. 만약 그렇다면 이러한 결론과 신뢰할 수 없을 것입니다. 분석 코드 자체의 존재가 가장 큰 규모인지 부정적인 영향을 미칩니다
시스템에 RUM 분석 코드를 배포할 때는 항상 다음 원칙을 따르세요. 프로덕션 사이트:
분석 연기
애널리틱스 코드는 항상 비동기식 비차단 방식으로 로드해야 합니다. 일반적으로 마지막에 로드되어야 합니다. 애널리틱스 코드를 LCP에 부정적인 영향을 줄 수 있습니다.
Core Web Vitals 측정항목을 측정하는 데 사용되는 모든 API는 구체적으로
(
buffered 플래그)을 지원하지 않으므로
스크립트를 조기에 로드하려고 서두르지 않아도 됩니다.
나중에 계산할 수 없는 측정항목을 측정하는 경우
페이지 로드 타임라인에 따라 일찍 실행해야 하는 코드만 인라인해야 합니다.
문서의 <head>에 삽입해야 합니다 (따라서 렌더링 차단이 아님
요청)하고 나머지는 지연시킵니다. 모든 광고 소재를
조기에 분석할 수 있게 되었습니다.
긴 작업 만들지 않기
애널리틱스 코드는 사용자 입력에 대한 응답으로 실행되는 경우가 많지만, 애널리틱스 코드가 많은 DOM 측정을 수행하거나 프로세서 집약적인 다른 API를 사용하는 경우 분석 코드 자체로 인해 입력 응답성이 저하될 수 있습니다. 또한 애널리틱스 코드가 포함된 자바스크립트 파일이 커서 해당 파일을 실행하는 경우 기본 스레드를 차단하여 페이지의 다음 페인트에 대한 상호작용 (INP)에 부정적인 영향을 미칠 수 있습니다.
비차단 API 사용
다음과 같은 API는
sendBeacon()
및
requestIdleCallback()
필요하지 않은 작업을 쉽게 실행할 수 있도록
차단할 수 있습니다.
이러한 API는 RUM 분석 라이브러리에서 사용하기에 좋은 도구입니다.
일반적으로 모든 분석 비콘은 sendBeacon() API를 사용하여 전송해야 합니다.
(가능한 경우) 모든 수동 분석 측정 코드는
유휴 기간으로
설정할 수 있습니다
필요한 것보다 더 많이 추적하지 않음
브라우저가 많은 성능 데이터를 노출하지만, 단지 데이터가 반드시 녹화를 해야 한다는 의미는 아닙니다. 분석 서버
Resource Timing API와 같은 리소스를 예로 들 수 있습니다. 는 페이지에 로드된 모든 단일 리소스에 대해 상세한 타이밍 데이터를 제공합니다. 그러나 이러한 모든 데이터가 비즈니스 예측에 반드시 또는 리소스 로드 성능 개선
간단히 말해 데이터가 존재하기 때문에 단순히 데이터를 추적하는 데 그치지 말고, 데이터가 사용될 수 있도록 그것을 추적하는 리소스를 소비하기 전에.