개발자 의견 필요 - Frame Timing API

지난 몇 년간 브라우저는 특히 모바일에서 렌더링 성능 측면에서 큰 발전을 이루었습니다. 이전에는 원격으로 복잡한 작업을 할 때 원활한 프레임 속도를 달성할 수 없었지만, 이제는 주의해서 작업하면 달성할 수 있습니다.

하지만 대부분의 경우 개발자가 자체 기기에서 합리적으로 테스트할 수 있는 사항과 사용자가 경험하는 사항 사이에는 불일치가 있습니다. 부드럽게 재생되는 60fps를 제공하지 못하면 사용자 경험이 저하되고 결국 사용자는 다른 플랫폼으로 이동하여 YouTube가 피해를 입게 됩니다. W3C에서는 사용자에게 표시되는 내용을 확인하는 데 도움이 되는 새로운 API인 Frame Timing API에 관해 논의하고 있습니다.

제이크 아치볼드와 저는 최근 API에 관한 개요 동영상을 녹화했습니다. 읽기보다는 시청하는 것을 선호하는 경우 다음 동영상을 참고하세요.

Frame Timing API 사용

Frame Timing API로 할 수 있는 일은 많습니다. 무엇보다도 개발자와 프로젝트에 중요한 사항을 측정할 수 있습니다. 다음은 몇 가지 아이디어입니다.

  • JavaScript 및 CSS 애니메이션의 fps 추적
  • 페이지 스크롤의 부드러움 (또는 멋진 무한 스크롤 목록)을 추적합니다.
  • 기기의 현재 부하에 따라 스펙터클 효과를 자동으로 축소합니다.
  • 런타임 성능 측정항목의 회귀 테스트

엘리베이터 피치

다음은 현재 사양에서 API가 표시되는 방식입니다. 이를 통해 JavaScript, 스타일, 레이아웃이 실행되는 렌더러 스레드 타이밍에 관한 데이터를 가져올 수 있습니다. 렌더러 스레드를 기본 스레드라고 하기도 합니다. 다른 이름으로 불리는 동일한 스레드입니다.

var rendererEvents = window.performance.getEntriesByType("renderer");

반환되는 각 렌더러 스레드 레코드는 대략 다음과 같이 표시됩니다.

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

각 레코드는 본질적으로 고유한 프레임 번호, 프레임이 시작된 시점의 고해상도 타임스탬프, 사용된 CPU 시간의 타임스탬프를 포함하는 객체입니다. 이러한 배열을 사용하면 각 startTime 값을 확인하고 기본 스레드가 60fps로 실행 중인지 확인할 수 있습니다. 즉, '각 프레임의 startTime가 대략 16ms 단위로 증가하나요?'

또한 cpuTime도 제공되므로 16ms 경계 내에 여유 있게 있는지 또는 16ms 경계까지 갔는지 알 수 있습니다. cpuTime가 16ms 경계 근처에 있으면 가비지 컬렉션이 시작될 여지가 거의 없으며 CPU 사용량이 많으면 배터리 소모도 더 커집니다.

렌더러 스레드 외에도 페인팅 및 합성이 발생하는 컴포저 스레드 타이밍에 관한 데이터도 가져올 수 있습니다.

var compositeThreadEvents = window.performance.getEntriesByType("composite");

각 이벤트는 소스 프레임 번호와 함께 반환되며, 이 번호를 사용하여 메인 스레드의 이벤트에 다시 연결할 수 있습니다.

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

브라우저에서 컴포지션이 작동하는 방식으로 인해 렌더러 스레드 레코드당 이러한 레코드가 여러 개 있을 수 있으므로 sourceFrameNumber를 사용하여 다시 연결할 수 있습니다. 이러한 레코드에 CPU 시간도 포함되어야 하는지에 관한 논의도 있습니다. 강한 의견이 있으면 GitHub 문제에 의견을 보내주세요.

추가 정보

이 API는 아직 제공되지 않지만 곧 제공될 예정입니다. 그동안 다음과 같은 작업을 할 수 있습니다.