개요

RUM 보기 이벤트는 모든 페이지 보기에 대한 광범위한 성능 메트릭을 수집합니다. 애플리케이션의 페이지 조회수를 모니터링하고 대시보드와 RUM Explorer에서 성능 메트릭을 탐색하세요.

다음에서 보기에 대한 성능 메트릭에 액세스할 수 있습니다:

• 애플리케이션 성능에 대한 높은 수준의 보기를 제공하는 기본 제공 RUM 대시보드를 사용할 수 있습니다. 예를 들어, RUM에서 수집한 기본 속성을 필터링하여 성능 개요 대시보드에서 사용자 하위 집합에 영향을 미치는 문제를 표시할 수 있습니다. 이 대시보드를 복제하여 필요에 맞게 사용자 지정하고 대시보드의 쿼리에서 RUM 성능 메트릭을 사용할 수도 있습니다.
• 성능 워터폴은 특정 페이지 보기의 성능 문제를 해결할 수 있는 RUM 탐색기의 모든 RUM 보기 이벤트에 액세스할 수 있습니다. 웹사이트 자산 및 리소스, 긴 작업, 프론트엔드 오류가 최종 사용자의 페이지 수준 성능에 미치는 영향을 표시합니다.

이벤트 타이밍 및 코어 웹 바이탈

Google의 Core Web Vitals은 사이트의 사용자 경험을 모니터링하기 위해 고안된 세 가지 메트릭 세트입니다. 이러한 메트릭은 로드 성능, 상호 작용 및 시각적 안정성을 파악하는 데 중점을 둡니다. 각 메트릭에는 우수한 사용자 경험으로 해석되는 값의 범위에 대한 지침이 함께 제공됩니다. Datadog은 이러한 메트릭의 75번째 백분위수를 모니터링할 것을 권장합니다.

• 백그라운드에서 열린 페이지(예: 새 탭 또는 초점이 없는 창)에서는 Next Paint 및 Largest Contentful Paint에 대한 상호 작용이 수집되지 않습니다.
• 실제 사용자의 페이지 보기에서 수집된 메트릭은 Synthetic 브라우저 테스트와 같이 고정되고 통제된 환경에서 로드된 페이지에 대해 계산된 메트릭과 다를 수 있습니다. Synthetic 모니터링은 실제 메트릭이아닌 실험실 메트릭으로 Largest Contentful Paint 및 Cumulative Layout Shift를 표시합니다.

Core Web Vitals 대상 요소

근본 문제를 알아내고 성능을 향상하려면 먼저 Core Web Vitals 메트릭 수치를 높인 요소가 무엇인지 알아내야 합니다. RUM에서는 각 Core Web Vital 인스턴스와 연관된 요소를 보고합니다.

• Largest Contentful Paint의 경우, RUM에서 최대 컨텐츠풀 페인트에 해당하는 요소의 CSS 선택기를 보고합니다.
• Next Paint와 상호작용의 경우, RUM에서 다음 페인트와 상호작용 시간이 가장 많이 걸린 요소의 CSS 선택기를 보고합니다.
• First Input Delay의 경우, Rum에서 사용자가 첫 번째로 상호작용한 요소의 CSS 선택기를 보고합니다.
• Cumulative Layout Shift의 경우, RUM에서 가장 많이 움직여 CLS에 영향을 준 요소의 CSS 선택기를 보고합니다.

모든 성능 메트릭

단일 페이지 애플리케이션(SPA) 모니터링

단일 페이지 애플리케이션(SPA)의 경우, RUM Browser SDK는 loading_type 속성을 사용하여 initial_load 와 route_change 탐색을 구분합니다. 웹 페이지의 상호 작용이 페이지를 완전히 새로 고치지 않고 다른 URL로 연결되는 경우, RUM SDK는 loading_type:route_change를 사용하여 새 보기 이벤트를 시작합니다. RUM은 히스토리 API를 사용하여 URL 변경 사항을 추적합니다.

Datadog에서는 페이지 로딩에 필요한 시간을 계산하는 고유한 성능 메트릭인 loading_time을 제공합니다. 이 메트릭은 initial_load 및 route_change 탐색 모두에서 작동합니다.

로딩 시간 계산 방법

최신 웹 애플리케이션을 고려하기 위해 로딩 시간은 네트워크 요청과 DOM 변형을 감시합니다.

• Initial Load: 로딩 시간은 _더 긴 값_을 표시합니다.

  • navigationStart와 loadEventEnd의 차이, 또는
  • navigationStart와 첫 페이지 활동 시점의 시간 차. 자세한 내용은 페이지 활동 계산 방법을 참고하세요.

• SPA Route Change: 로딩 시간은 URL 변경 시간과 페이지에 활동이 없는 첫 시간의 차와 같습니다. 자세한 내용은 페이지 활동 계산 방법을 참고하세요.

페이지 활동 계산 방법

RUM Browser SDK는 페이지 활동을 추적하여 인터페이스가 다시 안정될 때까지의 시간을 추정합니다. 다음과 같은 경우 페이지에 활동이 있는 것으로 간주합니다.

• xhr 또는 fetch 요청이 진행 중입니다.
• 브라우저는 성능 리소스 타이밍 항목(JS, CSS 등의 로딩 종료)을 방출합니다.
• 브라우저는 DOM 변형을 방출합니다.

페이지 활동은 100초 동안 활동이 없으면 종료된 것으로 간주됩니다.

참고: SDK 초기화 이후에 발생한 활동만 고려됩니다.

주의 사항:

다음 시나리오에서는 마지막 요청이나 DOM 변경 후 100ms인 기준으로도 활동을 정확하게 판단하지 못할 수 있습니다.

• 애플리케이션은 주기적으로 또는 클릭할 때마다 API에 요청을 전송하여 분석을 수집합니다.
• 이 애플리케이션은 ‘come’ 기술(즉, 스트리밍 또는 긴 폴링)을 사용하며 요청은 무기한 보류 상태로 유지됩니다.

이러한 경우 활동 결정의 정확성을 높이려면 페이지 활동을 계산할 때 제외할 RUM Browser SDK의 리소스 목록인 excludedActivityUrls를 지정합니다.

window.DD_RUM.init({
    ...
    excludedActivityUrls: [
        // 정확한 URL 제외
        'https://third-party-analytics-provider.com/endpoint',

        // /comet으로 끝나는 모든 URL 제외
        /\/comet$/,

        // 함수가 true를 반환하는 모든 URL 제외
        (url) => url === 'https://third-party-analytics-provider.com/endpoint',
    ]
})

Hash SPA 내비게이션

RUM SDK는 해시(#) 탐색에 의존하는 프레임워크를 자동으로 모니터링합니다. SDK는 HashChangeEvent를 감시하고 새 보기를 발행합니다. 현재 보기 컨텍스트에 영향을 주지 않는 HTML 앵커 태그에서 오는 이벤트는 무시됩니다.

커스텀 성능 메트릭 생성

커스텀 바이탈을 통해 구성 요소 수준 성능 측정

customVital API를 사용하여 구성 요소 수준에서 애플리케이션의 성능을 측정하세요. 예를 들어 페이지의 일부가 렌더링되는 데 걸리는 시간이나 구성 요소가 사용자 상호 작용에 응답하는 데 걸리는 시간을 측정할 수 있습니다. 참고: 커스텀 필수 이름에는 공백이나 특수 문자를 포함할 수 없습니다.

지속 시간 측정 시작 및 중지

startDurationVital을 호출하여 지속 시간 측정을 시작하고 stopDurationVital로 측정을 중지합니다:

window.DD_RUM.startDurationVital("dropdownRendering")
window.DD_RUM.stopDurationVital("dropdownRendering")

stopDurationVital 메서드를 호출하면 커스텀 바이탈 기간이 Datadog로 전송되며 @vital.name:dropdownRendering을 사용하여 조회할 수 있습니다. 예를 들어 @vital.duration:>10을 사용하여 기간별로 필터링할 수도 있습니다.

참조 및 설명 사용

startDurationVital에서 반환된 참조를 사용하고 description 문자열을 지정하여 여러 페이지에서 동일한 커스텀 바이탈의 인스턴스를 구분합니다. 예를 들어 login 페이지에서 dropdownRendering의 지속 시간을 추적하는 경우입니다.

const reference = window.DD_RUM.startDurationVital("dropdownRendering", { description: "login" })
window.DD_RUM.stopDurationVital(reference)

이 코드는 @vital.description으로 그룹화하여 여러 페이지에서 동일한 구성 요소의 렌더링 동작을 추적할 수 있습니다.

context 속성을 사용하여 커스텀 바이탈에 컨텍스트를 추가할 수도 있습니다.

window.DD_RUM.startDurationVital("dropdownRendering", {context: { clientId: "xxx" }})
window.DD_RUM.stopDurationVital("dropdownRendering")

addDurationVital로 커스텀 바이탈 보고

커스텀 바이탈 변수를 개별적으로 설정하는 대신 addDurationVital을 사용하여 한 번의 작업으로 커스텀 바이탈을 보고할 수 있습니다.

window.DD_RUM.addDurationVital("dropdownRendering", {startTime: 1707755888000, duration: 10000})

추가 성능 타이밍 추적

RUM의 기본 성능 타이밍 외에도 애플리케이션이 시간을 소비하는 위치를 보다 유연하게 측정할 수 있습니다. addTiming API는 성능 타이밍을 추가할 수 있는 간단한 방법입니다.

예를 들어 히어로 이미지가 표시되는 타이밍을 추가할 수 있습니다:

<html>
  <body>
    <img onload="window.DD_RUM.addTiming('hero_image')" src="/path/to/img.png" />
  </body>
</html>

또는 사용자가 처음 스크롤할 때 타이밍을 추가할 수 있습니다.

document.addEventListener("scroll", function handler() {
    // 이벤트 리스너를 제거하여 한 번만 트리거되도록 합니다.
    document.removeEventListener("scroll", handler);
    window.DD_RUM.addTiming('first_scroll');
});

타이밍이 전송되면 타이밍은 @view.custom_timings.<timing_name>과 같이 나노초 단위로 액세스할 수 있습니다 (예: @view.custom_timings.first_scroll). RUM Explorer 또는 대시보드에서 시각화를 만들기 전에 측정값을 생성해야 합니다.

단일 페이지 애플리케이션의 경우 addTiming API는 현재 RUM 보기의 시작을 기준으로 타이밍을 발행합니다. 예를 들어 사용자가 애플리케이션을 시작(초기 로드)하고 5초 후에 다른 페이지로 이동(경로 변경)하고 8초 후에 최종적으로 addTiming을 트리거하는 경우, 타이밍은 8-5 = 3초입니다.

비동기 설정을 사용하는 경우, 나의 고유한 타이밍(UNIX 에포크 타임스탬프)을 두 번째 파라미터로 제공할 수 있습니다.

예시:

document.addEventListener("scroll", function handler() {
    // 이벤트 리스너를 제거하여 한 번만 트리거되도록 합니다.
    document.removeEventListener("scroll", handler);

    const timing = Date.now()
    window.DD_RUM.onReady(function() {
      window.DD_RUM.addTiming('first_scroll', timing);
    });
});

참고 자료

추가 유용한 문서, 링크 및 기사:

인터랙티브 랩: 코어 웹 바이탈학습 센터 실제 사용자 모니터링(RUM)블로그 Datadog RUM 및 Synthetic 모니터링으로 코어 웹 바이탈 모니터링블로그 Datadog에서 보기 탐색설명서 이벤트에 시각화 적용설명서 RUM 대시보드에 대해 알아보기설명서