커스텀 측정항목

Philip Walton

특정 웹사이트에서 보편적으로 측정할 수 있는 사용자 중심 측정항목을 사용하면 많은 이점이 있습니다. 이러한 측정항목을 사용하면 다음 작업을 할 수 있습니다.

실제 사용자가 웹을 전체적으로 어떻게 경험하는지 파악합니다.
내 사이트를 경쟁업체 사이트와 비교합니다.
맞춤 코드를 작성하지 않고도 분석 도구에서 유용하고 실행 가능한 데이터를 추적할 수 있습니다.

범용 측정항목은 좋은 기준을 제공하지만, 특정 사이트의 전체 환경을 파악하려면 이러한 측정항목보다 더 많은 측정항목을 측정해야 하는 경우가 많습니다.

맞춤 측정항목을 사용하면 다음과 같이 사이트에만 적용될 수 있는 사이트 환경의 측면을 측정할 수 있습니다.

단일 페이지 앱 (SPA)이 한 '페이지'에서 다른 페이지로 전환하는 데 걸리는 시간입니다.
로그인한 사용자를 위해 데이터베이스에서 가져온 데이터를 페이지에 표시하는 데 걸리는 시간입니다.
서버 측 렌더링 (SSR) 앱이 하이드레이트하는 데 걸리는 시간입니다.
재방문자가 로드한 리소스의 캐시 적중률입니다.
게임에서 클릭 또는 키보드 이벤트의 이벤트 지연 시간입니다.

커스텀 측정항목을 측정하는 API

이전에는 웹 개발자가 성능을 측정할 수 있는 하위 수준 API가 많지 않았으므로 사이트의 성능이 양호한지 측정하기 위해 해킹에 의존해야 했습니다.

예를 들어 requestAnimationFrame 루프를 실행하고 각 프레임 간의 델타를 계산하여 실행 시간이 긴 JavaScript 작업으로 인해 기본 스레드가 차단되는지 확인할 수 있습니다. 델타가 디스플레이의 프레임 속도보다 훨씬 긴 경우 이를 긴 작업으로 보고할 수 있습니다. 하지만 이러한 해킹은 실제로 성능에 영향을 미치므로 (예: 배터리 소모) 권장되지 않습니다.

효과적인 성능 측정의 첫 번째 규칙은 성능 측정 기법 자체가 성능 문제를 일으키지 않는지 확인하는 것입니다. 따라서 사이트에서 측정하는 모든 맞춤 측정항목에 대해 가능한 경우 다음 API 중 하나를 사용하는 것이 좋습니다.

Performance Observer API

Browser Support

Source

Performance Observer API는 이 페이지에서 설명한 다른 모든 성능 API의 데이터를 수집하고 표시하는 메커니즘입니다. 이를 이해하는 것은 양질의 데이터를 얻는 데 매우 중요합니다.

PerformanceObserver를 사용하여 성능 관련 이벤트를 수동으로 구독할 수 있습니다. 이렇게 하면 API 콜백이 유휴 기간에 실행되므로 일반적으로 페이지 성능을 방해하지 않습니다.

PerformanceObserver를 만들려면 새 성능 항목이 디스패치될 때마다 실행할 콜백을 전달하세요. 그런 다음 observe() 메서드를 사용하여 수신할 항목 유형을 관찰자에게 알려줍니다.

const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

po.observe({type: 'some-entry-type'});

다음 섹션에는 관찰에 사용할 수 있는 다양한 항목 유형이 모두 나열되어 있지만 최신 브라우저에서는 정적 PerformanceObserver.supportedEntryTypes 속성을 통해 사용할 수 있는 항목 유형을 검사할 수 있습니다.

참고: observe() 메서드에 전달된 객체는 동일한 관찰자를 사용하여 두 개 이상의 항목 유형을 관찰하기 위해 entryTypes 배열을 지정할 수도 있습니다. entryTypes를 지정하는 것은 브라우저 지원 범위가 더 넓은 이전 옵션이지만, 이제는 type를 사용하는 것이 좋습니다. type를 사용하면 추가 항목별 관찰 구성 (예: 다음에 설명하는 buffered 플래그)을 지정할 수 있기 때문입니다.

이미 발생한 항목 관찰

기본적으로 PerformanceObserver 객체는 항목이 발생할 때만 관찰할 수 있습니다. 성능 분석 코드가 우선순위가 높은 리소스를 차단하지 않도록 지연 로드하려는 경우 문제가 발생할 수 있습니다.

이전 항목을 가져오려면 (발생 후) observe()를 호출할 때 buffered 플래그를 true로 설정합니다. 브라우저는 PerformanceObserver 콜백이 처음 호출될 때 성능 항목 버퍼의 이전 항목을 해당 유형의 최대 버퍼 크기까지 포함합니다.

po.observe({
  type: 'some-entry-type',
  buffered: true,
});

피해야 할 기존 성능 API

Performance Observer API 이전에는 개발자가 performance 객체에 정의된 다음 세 가지 메서드를 사용하여 성능 항목에 액세스할 수 있었습니다.

이러한 API는 계속 지원되지만 새 항목이 방출되는 시점을 수신할 수 없으므로 사용하지 않는 것이 좋습니다. 또한 많은 새로운 API (예: largest-contentful-paint)가 performance 객체를 통해 노출되지 않고 PerformanceObserver를 통해서만 노출됩니다.

Internet Explorer와의 호환성이 특별히 필요한 경우가 아니라면 코드에서 이러한 메서드를 사용하지 않고 앞으로 PerformanceObserver를 사용하는 것이 좋습니다.

User Timing API

Browser Support

Source

User Timing API는 시간 기반 측정항목을 위한 범용 측정 API입니다. 이를 통해 임의로 특정 시점을 표시한 다음 나중에 이러한 표시 사이의 기간을 측정할 수 있습니다.

// Record the time immediately before running a task.
performance.mark('myTask:start');
await doMyTask();

// Record the time immediately after running a task.
performance.mark('myTask:end');

// Measure the delta between the start and end of the task
performance.measure('myTask', 'myTask:start', 'myTask:end');

Date.now() 또는 performance.now()와 같은 API를 사용해도 비슷한 기능을 사용할 수 있지만 User Timing API를 사용하면 성능 도구와 잘 통합된다는 이점이 있습니다. 예를 들어 Chrome DevTools는 성능 패널에서 사용자 타이밍 측정을 시각화하며, 많은 분석 제공업체도 사용자가 수행한 측정을 자동으로 추적하고 기간 데이터를 분석 백엔드로 전송합니다.

사용자 타이밍 측정을 보고하려면 PerformanceObserver를 사용하고 measure 유형의 항목을 관찰하도록 등록하면 됩니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `measure` entries to be dispatched.
po.observe({type: 'measure', buffered: true});

Long Tasks API

Browser Support

Source

Long Tasks API는 브라우저의 기본 스레드가 프레임 속도나 입력 지연 시간에 영향을 미칠 정도로 오랫동안 차단된 시점을 파악하는 데 유용합니다. API는 50밀리초 이상 실행되는 작업을 보고합니다.

비용이 많이 드는 코드를 실행하거나 대규모 스크립트를 로드하고 실행해야 할 때마다 해당 코드가 기본 스레드를 차단하는지 추적하는 것이 유용합니다. 실제로 많은 상위 수준 측정항목은 긴 작업 API 자체를 기반으로 빌드됩니다 (예: 상호작용 시간 (TTI) 및 총 차단 시간 (TBT)).

긴 작업이 발생하는 시점을 확인하려면 PerformanceObserver를 사용하여 longtask 유형의 항목을 관찰하도록 등록하면 됩니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `longtask` entries to be dispatched.
po.observe({type: 'longtask', buffered: true});

Long Animation Frames API

Browser Support

Source

Long Animation Frames API는 50밀리초가 넘는 긴 작업이 아닌 긴 프레임을 살펴보는 Long Tasks API의 새로운 반복입니다. 이를 통해 더 나은 기여 분석과 잠재적으로 문제가 될 수 있는 지연의 더 넓은 범위를 비롯한 Long Tasks API의 단점이 해결됩니다.

긴 프레임이 발생하는 시점을 확인하려면 PerformanceObserver를 사용하고 long-animation-frame 유형의 항목을 관찰하도록 등록하면 됩니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `long-animation-frame` entries to be dispatched.
po.observe({type: 'long-animation-frame', buffered: true});

Element Timing API

Browser Support

Source

콘텐츠가 포함된 최대 페인트 (LCP) 측정항목은 가장 큰 이미지 또는 텍스트 블록이 화면에 표시된 시점을 파악하는 데 유용하지만, 경우에 따라 다른 요소의 렌더링 시간을 측정해야 할 수도 있습니다.

이러한 경우 Element Timing API를 사용하세요. LCP API는 실제로 요소 타이밍 API를 기반으로 빌드되며 가장 큰 콘텐츠 요소의 자동 보고를 추가하지만, elementtiming 속성을 명시적으로 추가하고 element 항목 유형을 관찰하도록 PerformanceObserver를 등록하여 다른 요소에 대해서도 보고할 수 있습니다.

<img elementtiming="hero-image" />
<p elementtiming="important-paragraph">This is text I care about.</p>
<!-- ... -->

<script>
  const po = new PerformanceObserver((entryList) => {
    for (const entry of entryList.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  // Start listening for `element` entries to be dispatched.
  po.observe({type: 'element', buffered: true});
</script>

도움말: 최대 콘텐츠 렌더링 시간에 고려되는 요소 유형은 Element Timing API를 사용하여 관찰할 수 있는 요소 유형과 동일합니다. 이러한 유형이 아닌 요소에 elementtiming 속성을 추가하면 속성이 무시됩니다.

Event Timing API

Browser Support

Source

다음 페인트까지의 상호작용 (INP) 측정항목은 페이지 수명 동안 모든 클릭, 탭, 키보드 상호작용을 관찰하여 전반적인 페이지 반응성을 평가합니다. 페이지의 INP는 사용자가 상호작용을 시작한 시점부터 브라우저가 사용자의 입력에 따른 시각적 결과를 보여주는 다음 프레임을 페인트하는 시점까지 완료하는 데 가장 오래 걸린 상호작용인 경우가 많습니다.

INP 측정항목은 Event Timing API를 통해 가능합니다. 이 API는 이벤트 수명 주기 중에 발생하는 여러 타임스탬프를 노출합니다.

startTime: 브라우저가 이벤트를 수신한 시간입니다.
processingStart: 브라우저가 이벤트의 이벤트 핸들러 처리를 시작할 수 있는 시간입니다.
processingEnd: 브라우저가 이 이벤트의 이벤트 핸들러에서 시작된 모든 동기 코드의 실행을 완료한 시간입니다.
duration: 브라우저가 이벤트를 수신한 시점부터 이벤트 핸들러에서 시작된 모든 동기 코드를 실행한 후 다음 프레임을 페인트할 수 있을 때까지의 시간입니다 (보안상의 이유로 8밀리초로 반올림됨).

다음 예에서는 이러한 값을 사용하여 맞춤 측정항목을 만드는 방법을 보여줍니다.

const po = new PerformanceObserver((entryList) => {
  // Get the last interaction observed:
  const entries = Array.from(entryList.getEntries()).forEach((entry) => {
    // Get various bits of interaction data:
    const inputDelay = entry.processingStart - entry.startTime;
    const processingTime = entry.processingEnd - entry.processingStart;
    const presentationDelay = entry.startTime + entry.duration - entry.processingEnd;
    const duration = entry.duration;
    const eventType = entry.name;
    const target = entry.target || "(not set)"

    console.log("----- INTERACTION -----");
    console.log(`Input delay (ms): ${inputDelay}`);
    console.log(`Event handler processing time (ms): ${processingTime}`);
    console.log(`Presentation delay (ms): ${presentationDelay}`);
    console.log(`Total event duration (ms): ${duration}`);
    console.log(`Event type: ${eventType}`);
    console.log(target);
  });
});

// A durationThreshold of 16ms is necessary to include more
// interactions, since the default is 104ms. The minimum
// durationThreshold is 16ms.
po.observe({type: 'event', buffered: true, durationThreshold: 16});

Resource Timing API

Browser Support

Source

Resource Timing API를 사용하면 개발자가 특정 페이지의 리소스가 로드된 방식에 대한 자세한 정보를 확인할 수 있습니다. API 이름과 달리 제공되는 정보는 타이밍 데이터에만 국한되지 않습니다 (이러한 데이터가 많이 있음). 액세스할 수 있는 기타 데이터는 다음과 같습니다.

initiatorType: 리소스를 가져온 방법(예: <script> 또는 <link> 태그에서 가져옴, fetch() 호출에서 가져옴)
nextHopProtocol: 리소스를 가져오는 데 사용된 프로토콜(예: h2 또는 quic)
encodedBodySize/decodedBodySize: 인코딩된 형식 또는 디코딩된 형식의 리소스 크기 (각각)
transferSize: 네트워크를 통해 실제로 전송된 리소스의 크기입니다. 캐시에서 리소스가 제공되는 경우 이 값은 encodedBodySize보다 훨씬 작을 수 있으며, 캐시 재검증이 필요하지 않은 경우 0일 수 있습니다.

리소스 타이밍 항목의 transferSize 속성을 사용하여 캐시 적중률 측정항목 또는 총 캐시된 리소스 크기 측정항목을 측정할 수 있습니다. 이는 리소스 캐싱 전략이 재방문자의 실적에 미치는 영향을 파악하는 데 유용합니다.

다음 예시에서는 페이지에서 요청한 모든 리소스를 로깅하고 각 리소스가 캐시에서 제공되었는지 여부를 나타냅니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log(entry.name, entry.transferSize === 0);
  }
});

// Start listening for `resource` entries to be dispatched.
po.observe({type: 'resource', buffered: true});

Browser Support

Source

Navigation Timing API는 Resource Timing API와 유사하지만 탐색 요청만 보고합니다. navigation 항목 유형은 resource 항목 유형과도 유사하지만 탐색 요청에만 해당하는 추가 정보 (예: DOMContentLoaded 및 load 이벤트가 발생한 경우)가 포함되어 있습니다.

많은 개발자가 서버 응답 시간 (첫 바이트 소요 시간 (TTFB))을 파악하기 위해 추적하는 측정항목은 Navigation Timing API를 사용하여 확인할 수 있습니다. 구체적으로는 항목의 responseStart 타임스탬프입니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log('Time to first byte', entry.responseStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

서비스 워커를 사용하는 개발자가 관심을 가질 수 있는 또 다른 측정항목은 탐색 요청의 서비스 워커 시작 시간입니다. 브라우저가 가져오기 이벤트를 가로채기 시작하기 전에 서비스 워커 스레드를 시작하는 데 걸리는 시간입니다.

특정 탐색 요청의 서비스 워커 시작 시간은 entry.responseStart와 entry.workerStart의 델타에서 확인할 수 있습니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Service Worker startup time:',
        entry.responseStart - entry.workerStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

Server Timing API

Browser Support

Source

Server Timing API를 사용하면 응답 헤더를 통해 서버에서 브라우저로 요청별 타이밍 데이터를 전달할 수 있습니다. 예를 들어 특정 요청에 대해 데이터베이스에서 데이터를 조회하는 데 걸린 시간을 나타낼 수 있습니다. 이는 서버의 속도 저하로 인한 성능 문제를 디버깅하는 데 유용합니다.

서드 파티 분석 제공업체를 사용하는 개발자에게는 서버 타이밍 API가 이러한 분석 도구에서 측정할 수 있는 다른 비즈니스 측정항목과 서버 성능 데이터를 연관시키는 유일한 방법입니다.

응답에서 서버 타이밍 데이터를 지정하려면 Server-Timing 응답 헤더를 사용하면 됩니다. 예를 들면 다음과 같습니다

HTTP/1.1 200 OK

Server-Timing: miss, db;dur=53, app;dur=47.2

그런 다음 페이지에서 Resource Timing API와 Navigation Timing API의 resource 또는 navigation 항목에 있는 이 데이터를 읽을 수 있습니다.

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Logs all server timing data for this response
    console.log('Server Timing', entry.serverTiming);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

커스텀 측정항목 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

커스텀 측정항목을 측정하는 API

Performance Observer API

이미 발생한 항목 관찰

피해야 할 기존 성능 API

User Timing API

Long Tasks API

Long Animation Frames API

Element Timing API

Event Timing API

Resource Timing API

Navigation Timing API

Server Timing API

커스텀 측정항목