디버그 정보로 성능 데이터의 기여도를 분석하는 방법 알아보기 분석을 통해 실제 사용자의 문제를 파악하고 해결할 수 있도록
Google에서는 성능을 측정하고 디버그할 수 있는 두 가지 카테고리의 도구를 제공합니다.
- 실험실 도구: Lighthouse와 같은 도구로 페이지를 로드할 수 있는 도구입니다. 시뮬레이션 환경을 통해 시뮬레이션된 환경 (예: 네트워크 및 저사양 휴대기기).
- 필드 도구: Chrome 사용자 환경 등의 도구 보고서 (CrUX)는 Chrome에서 수집한 실제 사용자 데이터를 기반으로 합니다. (참고: PageSpeeds 와 같은 도구에서 보고한 필드 데이터 검색 통계 및 검색 콘솔의 출처는 다음과 같습니다. CrUX 데이터).
현장 도구는 더 정확한 데이터를 제공하지만, 실제로 무엇을 나타내는지 나타내는 사용자의 실제 경험입니다. 실험실 도구가 문제를 파악하고 해결하는 데 있습니다
CrUX 데이터는 페이지의 실제 성능을 더 잘 대표하지만 CrUX 점수가 개선 방법을 알아내는 데 확인할 수 있습니다
반면 Lighthouse는 문제를 식별하고 구체적으로 개선 방법에 대한 제안을 볼 수 있습니다. 하지만 Lighthouse는 페이지 로드 시 발견된 성능 문제를 확인할 수 있습니다 문제를 감지하지 않습니다. 스크롤 또는 클릭과 같은 사용자 상호작용의 결과로만 나타나는 버튼을 클릭합니다.
이에 따라 다음과 같은 중요한 질문이 떠오릅니다. 이 애플리케이션의 디버그 정보를 Core Web Vitals 또는 기타 현장 실제 사용자의 성능 측정항목
이 게시물에서는 추가 정보를 수집하는 데 사용할 수 있는 API에 대해 자세히 설명합니다. 현재 Core Web Vitals 측정항목의 디버깅 정보와 기존 애널리틱스 도구에서 이 데이터를 캡처하는 방법에 대한 아이디어를 얻을 수 있습니다.
기여 분석 및 디버깅을 위한 API
레이아웃 변경 횟수(CLS)
모든 Core Web Vitals 측정항목 중에서 CLS가 현장에서 디버그 정보를 수집하는 것이 가장 중요합니다. CLS 측정 사용자가 광고와 상호작용하는 방식이 스크롤 거리, 클릭 내용 등 페이지의 종류에 따라 어떤 요소가 변경되고 있는지에 영향을 미칩니다.
PageSpeed Insights의 다음 보고서를 살펴보세요.
<ph type="x-smartling-placeholder">
실험실 (Lighthouse)의 CLS와 이전의 CLS에 대해 보고된 값 비교 필드 (CrUX 데이터)가 상당히 다릅니다. 페이지에 광고를 게재할 수 있는 Lighthouse에서 테스트할 때 사용되지 않습니다.
그러나 사용자 상호 작용이 필드 데이터에 영향을 미친다는 것을 이해하더라도, 여전히 0.28점을 얻으려면 페이지에서 어떤 요소가 바뀌는지 알아야 함 75번째 백분위수에서 발생합니다 LayoutShiftAttribution 인터페이스를 통해 가능합니다.
레이아웃 변경 기여 분석 받기
LayoutShiftAttribution
인터페이스가 레이아웃 불안정성 layout-shift 항목마다 노출됨
API가 내보냅니다.
두 인터페이스에 관한 자세한 설명은 디버그 레이아웃 교대 근무 목적 우선 알아두어야 할 점은 개발자는 페이지에서 발생하는 모든 레이아웃 변경과 확인할 수 있습니다
다음은 각 레이아웃 변경과 요소를 기록하는 코드의 예입니다. 확인할 수 있습니다
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
24시간 또는 3년 이내에 데이터를 측정하고 분석 도구로 보내는 것은 실용적이지 않을 것입니다 발생하는 모든 단일 레이아웃 변경 모든 교대 근무를 모니터링하여 최악의 변동을 추적하고 이에 대한 정보만 보고합니다.
목표는 사이트에서 발생하는 모든 레이아웃 변경을 식별하고 수정하는 모든 사용자에게 목표는 가장 많은 수의 문제에 영향을 미치는 변화를 식별하는 것입니다. 75번째 백분위수에서 페이지의 CLS에 가장 많이 기여합니다.
또한 인코더-디코더가 입력될 때마다 가장 큰 소스 요소를 CLS 값을 계정에 전송할 준비가 되었을 때만 확인할 수 있습니다.
다음 코드는 참여한 layout-shift개 항목의 목록을 가져옵니다.
CLS로 변환하고 가장 큰 이동 값에서 가장 큰 소스 요소를 반환합니다.
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
가장 큰 이동에 기여한 가장 큰 요소를 식별한 후에는 분석 도구에 보고할 수 있습니다
특정 페이지의 CLS에 가장 많이 기여하는 요소는 모든 사용자에 대해 이러한 요소를 집계하면 가장 많은 사용자에게 영향을 미치는 변화하는 요소의 목록을 생성할 수 있습니다.
사용자 환경 변화의 근본 원인을 파악하고 해결한 후 분석 코드가 작은 변동을 '최악'으로 보고하기 시작합니다. 늘어난다는 점입니다 결국 보고된 모든 교대 근무 수는 페이지의 '양호' 상태 임곗값 0.1입니다.
가장 큰 변화와 함께 캡처하는 데 유용할 수 있는 기타 메타데이터 소스 요소는 다음과 같습니다.
- 변화가 가장 큰 시기
- 가장 큰 변화 시점의 URL 경로 (동적으로 URL 업데이트).
최대 콘텐츠 렌더링 시간(LCP)
현장에서 LCP를 디버그하려면 필요한 기본 정보는 어떤 특정 요소가 해당 특정 항목에 대해 가장 큰 요소 (LCP 후보 요소)였습니다. 페이지 로드 시간을 단축할 수 있습니다.
LCP는 IP 주소가 더 많지만 후보 요소가 사용자별로 다르며, 이는 정확히 동일한 경우에도 있습니다.
여러 이유로 이 문제가 발생할 수 있습니다.
- 사용자 기기의 화면 해상도가 다르기 때문에 페이지 레이아웃에 따라 다양한 요소가 표시 영역 안에 표시됩니다.
- 사용자는 맨 위로 스크롤된 페이지를 로드하지 않는 경우도 있습니다. 종종 링크가 프래그먼트 식별자 또는 심지어 텍스트 조각을 사용하므로 페이지가 로드되고 페이지의 모든 스크롤 위치에서 표시되도록 할 수 있습니다.
- 콘텐츠가 현재 사용자에게 맞춤설정될 수 있으므로 LCP 후보 요소는 사용자마다 크게 다를 수 있습니다.
즉, 어떤 요소나 요소 집합에 대해 가정할 수 없다는 의미입니다. 가 특정 페이지에 대한 가장 일반적인 LCP 후보 요소가 됩니다. 다음과 같이 해야 합니다. 실제 사용자 행동을 기준으로 측정할 수 있습니다.
LCP 후보 요소 식별
JavaScript에서 LCP 후보 요소를 결정하려면 최대 Contentful Paint API를 사용하면 LCP 시간 값을 결정하는 데 사용하는 것과 동일한 API입니다.
largest-contentful-paint 항목을 관찰할 때
마지막 항목의 element 속성을 확인하여 현재 LCP 후보 요소를 업데이트합니다.
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
LCP 후보 요소를 파악하면 이를 분석 도구로 보낼 수 있음 측정항목 값과 함께 표시됩니다. 이렇게 하면 CLS와 마찬가지로 어떤 유형의 요소를 먼저 최적화하는 것이 가장 중요합니다.
LCP 후보 요소 외에도 LCP 하위 파트 시간: 을 통해 사이트와 관련성이 높은 특정 최적화 단계를 파악할 수 있습니다.
다음 페인트에 대한 상호작용 (INP)
INP 필드에서 캡처해야 할 가장 중요한 정보는 다음과 같습니다.
- 상호작용한 요소
- 상호작용 유형인 이유
- 상호작용이 일어난 시점
느린 상호작용의 주요 원인은 차단된 기본 스레드입니다. 이는 기본 스레드가 JavaScript가 로드되는 동안 일반적입니다. 가장 느린 상호작용이 있는지 파악 문제를 해결하기 위해 무엇을 해야 하는지 결정하는 데 도움이 됨 있습니다.
INP 측정항목은 이벤트 리스너를 실행하는 데 걸리는 시간을 포함하여 모든 이벤트 리스너 후 다음 프레임을 그리는 데 걸리는 시간 확인할 수 있습니다 즉, INP의 경우 어떤 타깃팅이 필요한지를 알면 느린 상호작용을 유발하는 경향이 있으며 있습니다.
다음 코드는 INP 항목의 대상 요소와 시간을 기록합니다.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
이 코드는 어떤 event 항목이 INP인지 확인하는 방법은 보여주지 않습니다.
더 복잡하기 때문입니다. 하지만 다음 섹션에서는
이 정보를 얻는 방법은
web-vitals JavaScript 라이브러리를 설치합니다.
web-vitals JavaScript 라이브러리 사용
이전 섹션에서는 몇 가지 일반적인 제안사항과 캡처 가능한 코드 예시를 제공합니다. 분석 도구로 보내는 데이터에 포함할 디버그 정보
버전 3부터 web-vitals가 JavaScript 라이브러리에는 속성이 포함되어 있습니다. 빌드 이러한 모든 정보 및 몇 가지 추가적인 신호도 사용할 수 있습니다.
다음 코드 예에서는 추가 이벤트 매개변수 (또는 맞춤 설정) 측정기준)의 값이라고 합니다. 성능의 근본 원인을 파악하는 데 유용한 디버그 문자열 있습니다
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
이 코드는 Google 애널리틱스에만 해당되지만 일반적인 아이디어는 다른 분석 도구에도 액세스할 수 있습니다
이 코드는 단일 디버그 신호에 대해 보고하는 방법도 보여주지만 캠페인별로 여러 다양한 신호를 수집하고 측정항목입니다.
예를 들어, INP를 디버그하려면 시간, loadState, 상호작용을 의미하는 등 (예: 긴 애니메이션 프레임 데이터)에 포함할 수 있습니다.
web-vitals 저작자 표시 빌드는 추가 기여 분석 정보를 노출합니다.
INP의 경우 다음 예에 나와 있습니다.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
자세한 내용은 web-vitals 기여 분석 자세한 내용은 문서를 참고하세요. 노출된 디버그 신호의 전체 목록입니다.
데이터 보고 및 시각화
측정항목 값과 함께 디버그 정보를 수집하기 시작했다면 다음 단계는 모든 사용자의 데이터를 집계하여 파악할 수 있습니다.
앞서 언급했듯이 모든 문제를 해결할 필요는 없습니다. 해결하려고 할 때는 특히 처음부터 문제를 해결해야 합니다. 가장 많은 사용자에게 영향을 미치는 문제들입니다. 확인할 수 있습니다
GA4의 경우 다음을 사용하여 데이터를 쿼리하고 시각화하는 방법에 대한 도움말을 참고하세요. BigQuery를 선택합니다.
요약
이 글이
디버그 정보를 가져오는 기존 성능 API 및 web-vitals 라이브러리
업계의 실제 사용자 방문을 기반으로 실적을 진단하는 데 도움을 줍니다. 이
Core Web Vitals에 중점을 두지만 개념은
디버깅에도 적용됩니다
모든 실적 측정항목을 측정할 수 있습니다.
실적 측정을 이제 막 시작했으며 이미 마케팅 경험이 있는 경우 Google 애널리틱스 사용자인 경우 Web Vitals 보고서 도구가 도움이 될 수 있습니다. 이미 Core Web의 디버그 정보 보고를 지원하고 있기 때문입니다. vitals 측정항목
제품 및 서비스를 개선하고자 하는 분석 공급업체는 사용자에게 더 많은 디버깅 정보를 제공하고 싶다면 여기에 설명된 기술뿐만 아니라 제시된 아이디어에만 국한되지는 마세요. 여기에서 확인하세요. 이 게시물은 일반적으로 모든 분석 도구에 적용할 수 있습니다. 하지만 개별 분석 도구가 더 많은 디버그 정보를 볼 수 있습니다.
마지막으로, 이러한 측정항목을 디버그하는 능력에 격차가 있다고 생각되면 API 자체에서 누락된 기능이나 정보가 web-vitals-feedback@googlegroups.com으로 이메일을 보내주세요.