브라우저 모니터링의 PageViewTiming 이벤트 는 사용 가능한 즉시 각 데이터 포인트를 별도의 이벤트로 보냅니다. 타이밍을 제한하지 않기 때문에 발동 시점에 상관없이 첫 페인트나 첫 상호작용 데이터를 받을 수 있습니다. 이 문서에서는 PageViewTiming 및 해당 속성을 사용하여 시각적 및 응답성 관점에서 사이트, 구성요소 로드 및 사용자 성능 측정항목에 대한 데이터를 쿼리하는 이유와 방법을 설명합니다.
PageViewTiming을 사용하는 이유는 무엇입니까?
응용 프로그램에서 비동기 또는 동적 페이지를 사용하는 경우 사이트 또는 구성 요소 로드에 대한 추가 세부 정보가 필요할 수 있습니다. 그러나 페이지는 다양한 방식으로 콘텐츠를 로드할 수 있으며 사용자는 해당 콘텐츠와 상호 작용하는 시기를 제어합니다. 이것이 일부 사용자 중심 성능 메트릭이 브라우저 에이전트의 표준 창 로드(페이지 로드 시간) 외부에서 발생하는 이유입니다.
예를 들어, 사용자는 참을성이 없어 콘텐츠가 웹페이지에 표시되자마자 클릭을 시작할 수 있습니다. 또는 콘텐츠가 로드된 후 오랫동안 페이지를 사용하기 위해 기다릴 수 있습니다.
PageViewTiming 이벤트는 다른 이벤트에 종속되지 않는 보다 실시간 전달 메커니즘을 제공합니다. 추가 측정항목은 시각적 및 응답성 관점에서 사용자가 사이트를 경험하는 방식을 이해하는 데 도움이 될 수 있습니다.
Google의 코어 웹 바이탈 지원
꽃병 모니터링용 에이전트 버전 1177 부터 코어 웹 바이탈을 완벽하게 지원합니다. 이 기능은 모든 유형의 에이전트(Lite, Pro 또는 Pro+SPA)에서 사용할 수 있습니다.
코어 웹 바이탈을 구성하는 지표는 시간이 지남에 따라 진화합니다 . 현재 세트는 사용자 경험의 세 가지 측면인 로딩, 상호 작용 및 시각적 안정성에 중점을 둡니다. 여기에는 다음 기준과 각각의 옛 값이 포함됩니다.
- Largest contentful paint (LCP): 로딩 성능을 측정합니다. 좋은 사용자 경험을 제공하려면 페이지가 처음 로드되기 시작할 때 LCP가 within 2.5 seconds 발생해야 합니다.
- Interaction to next paint (INP): 모든 사용자 복합체의 지연시간을 페이지로 측정합니다. 좋은 사용자 경험을 제공하려면 페이지의 INP가 less than 200 milliseconds 이어야 합니다.
- Cumulative layout shift (CLS): 시각적 안정성을 측정합니다. 좋은 사용자 경험을 제공하려면 페이지에서 CLS를 less than 0.1 으로 유지해야 합니다.
이러한 지표 각각에 대해 대부분의 사용자에게 권장되는 팝업 목표, 좋은 레버 값을 달성했는지 확인하기 위해 측정할 항목은 모바일 및 데스크톱 기기에 걸쳐 분류된 페이지 로드의 75th percentile 입니다.
자세히 알아보려면 Nerd Days에서 인지된 성능에 대해 이야기 하는 것을 시청하십시오.
자세한 시각적, 상호 작용 및 응답 메트릭
BrowserInteraction 및 PageView 이벤트는 페이지 창 로드 (또는 창 로드 및 AJAX) 타이밍을 수신하면 보고를 종료합니다. 그러나 페인트 및 상호 작용 메트릭은 언제든지 발생할 수 있습니다. PageViewTiming 는 이러한 측정항목을 다음과 같은 별도의 이벤트로 제공합니다.
- 이 타이밍의 변동성을 고려하십시오.
- 임의의 시간 초과를 설정하지 마십시오.
BrowserInteraction및PageView이벤트를 무기한 보류하지 않도록 합니다.
추가 자료 | 코멘트 |
|---|---|
|
|
|
Google의 연구에 따르면 가장 큰 요소가 렌더링된 시점을 확인하는 것이 페이지의 주요 콘텐츠가 로드되고 유용한 시점을 측정하는 더 정확한 방법입니다. 제한 사항 및 고려 사항을 포함하여 이 메트릭에 대한 자세한 내용은 w3c draft 를 참조하십시오. 또한 LCP를 사용하여 누적 레이아웃 이동 점수 속성을 보고합니다. 이 속성은 콘텐츠가 가장 많이 포함된 페인트는 Google에서 코어 웹 바이탈 로 식별한 세 가지 지표 중 하나입니다. LCP 값은 최대 2.5초는 "좋음"으로 간주되고, 2.5-4초 사이는 "개선 필요"로 간주되며, 4초를 초과하면 "나쁨"으로 간주됩니다. |
|
또한 사용자의 첫 번째 상호 작용 순간에 누적 레이아웃 이동(CLS) 점수 속성을 보고합니다. 이 속성은 다음과 같이 보고됩니다. INP는 Google에서 코어 웹 바이탈 로 식별한 세 가지 지표 중 하나입니다. INP 점수가 200ms 이하는 "좋음"으로 간주되고, 200-500ms 사이는 "개선 필요"로 간주되며, 500ms를 초과하면 "나쁨"으로 간주됩니다. |
| CLS(누적 레이아웃 변경)는 에이전트 v1177 이상 에서 사용할 수 있습니다. CLS는 사용자 환경이 예기치 않게 레이아웃이 변경되는 빈도를 정량화하는 데 도움이 되므로 시각적 안정성을 측정하는 데 중요한 사용자 중심 지표입니다. 낮은 CLS는 페이지를 즐겁게 만드는 데 도움이 됩니다. 누적 레이아웃 변경은 Google에서 코어 웹 바이탈 로 식별한 세 가지 지표 중 하나입니다. CLS 점수가 0.1 이하인 경우 "좋음"으로 간주되고, 0.1-0.25 사이는 "개선 필요"로 간주되며, 0.25 이상은 "나쁨"으로 간주됩니다. |
| 다음 페인트(INP)와의 상호작용은 에이전트 v1227 이상 에서 가능합니다. INP는 런타임 응답성과 사용자가 인지하는 성능을 측정하기 위한 새로운 지표입니다. 사용자 복합체와 페이지 반응 또는 리페인팅 사이의 가장 큰 지연 시간을 측정합니다. 이는 Web Vitals v3에 추가된 실험적이지만 중요한 것으로 식별된 지표입니다. 최대 200ms의 INP 점수는 "양호", 200-500ms는 "개선 필요", 500ms 이상은 "나쁨"으로 간주됩니다. |
|
|
| 지정된 경우 |
| 이것은 |
| 긴 작업 보고는 에이전트 v1227부터 사용할 수 있습니다. 이 이벤트는 >50ms 동안 기본 UI 스레드를 차단하는 작업을 보고하는 실험적인 PerformanceLongTaskTiming API에서 관찰한 항목당 나타냅니다. 참고: 이 이벤트는 실험적 기능으로 사용할 수 있지만 해당 데이터는 자동으로 수집되지 않습니다. 일반적으로 사용자 입력 또는 상호 작용 처리 지연을 방지하기 위해 이러한 작업을 분할하고 최적화하는 것이 좋습니다. 긴 작업은 |
| 에이전트 v1177 이상 에서 사용할 수 있는 또한 |
|
또한 |
| 에이전트 v1163 이상 에서 사용할 수 있는 또한 |
호환성 및 요구 사항
요구 사항:
- 설치 요구 사항 을 충족합니다.
- 이 이벤트를 보고하려면 브라우저 에이전트 버전 1153 이상이필요합니다.
브라우저 에이전트 릴리스 정보 를 따라 새 메트릭이 릴리스되는 시기를 알아보세요.
이러한 메트릭은 다음 브라우저 버전에서 지원됩니다. 지원되지 않는 브라우저의 경우 PageViewTiming 이벤트가 기록되지 않습니다.
메트릭 | 지원되는 브라우저 버전 |
|---|---|
|
|
|
|
|
|
|
|
|
|
| 이 이벤트는 현재 14.1(데스크톱) 또는 14.5(iOS) 미만의 Safari를 제외한 대부분의 최신 브라우저 버전에서 지원됩니다. MDN 문서를 통한 호환성 매트릭스. |
| 이 이벤트는 현재 데스크톱 및 모바일의 모든 브라우저에서 지원됩니다. MDN 문서를 통한 호환성 매트릭스. |
| 이 이벤트는 현재 데스크톱 및 모바일의 모든 브라우저에서 지원됩니다. MDN 문서를 통한 호환성 매트릭스. |
누적 레이아웃 시프트
CLS(Cumulative Layout Shift)는 웹페이지 콘텐츠의 안정성을 측정하는 지표입니다. 전체 설명은 web.dev/cls를 참조하세요.
New Relic에서 CLS를 캡처하는 방법
Layout Instability API 에 의해 보고된 페이지 레이아웃의 이동은 페이지 수명 동안 집계되고 모든 PageViewTiming 이벤트에 대한 속성으로 보고되며 해당 이벤트가 발생했을 때 CLS 값을 나타냅니다.
이 모델을 사용하여 사용자는 페이지 수명의 여러 지점에서 CLS 값을 볼 수 있습니다. 예를 들어 CLS 값은 처음 사용자가 페이지와 상호 작용하거나 페이지를 숨길 때까지입니다.
다른 CLS 소스 근사화
Lighthouse는 페이지가 로드되는 시점까지만 CLS 값을 캡처하므로 개발 또는 랩 환경에서 유용합니다. windowLoad PageViewTiming 이벤트를 보면 Lighthouse 값을 근사화할 수 있습니다.
CrUX 보고서는 페이지의 수명 동안 캡처된 값을 사용하므로 RUM 환경에서 최악의 경우 변화를 분석하는 데 유용합니다. windowUnload PageViewTiming 이벤트의 CLS 속성을 보면 CrUX 값을 근사화할 수 있습니다. 샘플 세트가 다르고 수명이 긴 웹 페이지의 값이 포함되는 방식이 다르기 때문에 이러한 값은 정확히 동일하지 않습니다. New Relic 브라우저 모니터링 에이전트는 페이지가 언로드될 때 CLS를 캡처하는 반면 CrUX는 페이지 수명 동안 메트릭을 수집하고 업데이트합니다.
CLS 집계 방식
2021년 7월부터 Google은 CLS 값이 집계되는 방식을 업데이트했습니다. 브라우저 모니터링 에이전트 버전 v12xx 는 CLS 메트릭 진화에 설명된 방법을 사용합니다.
Browser monitoring agent v12xx or higher:
레이아웃 이동 값은 창에서 캡처됩니다. 서로 1초 이내에 발생했지만 첫 번째와 마지막 이동 사이에 5초를 넘지 않는 레이아웃 전환은 동일한 창의 일부입니다. CLS 점수는 레이아웃 이동 값의 합계가 가장 높은 창의 레이아웃 이동 값 합계를 나타냅니다.
Prior to Browser agent v12xx:
CLS 점수는 페이지 수명의 해당 시점까지 발생한 모든 레이아웃 이동의 합계를 나타냅니다.
이벤트 데이터 쿼리
다음은 시작하는 데 도움이 되는 이벤트 데이터에 대한 몇 가지 샘플 쿼리입니다.