개발자 의견 필요 - Frame Timing API

폴 루이스

지난 몇 년 동안 브라우저는 렌더링 성능 면에서, 특히 모바일에서 상당한 진전을 이루었습니다. 이전에는 원격으로 복잡한 모든 프레임의 프레임 속도를 매끄럽게 해결할 수 없었지만, 오늘날에는 적어도 주의를 기울이면 달성할 수 있습니다.

그러나 대부분의 사람들은 자신의 기기에서 합리적으로 테스트할 수 있는 것과 사용자가 경험하는 것 사이에 차이가 있습니다. 60fps가 매끄럽게 작동하지 않으면 경험이 손상되고 결국 다른 곳으로 가게 되어 곤란을 겪게 됩니다. 또한 W3C에서는 사용자에게 표시되는 내용을 확인할 수 있는 새로운 API인 Frame Timing API에 관해 논의하고 있습니다.

Jake Archibald와 저는 최근에 API에 대한 개요를 동영상으로 녹화했습니다. 글보다는 영상으로 정보를 얻고 싶다면 다음 동영상을 한번 살펴보세요.

Frame Timing API 사용

Frame Timing API를 이용해 할 수 있는 일은 의심할 여지 없이 많으며, 결정적으로 자신과 프로젝트에 중요한 것이 무엇인지 측정할 수 있게 됩니다. 다음과 같은 몇 가지 아이디어가 있습니다.

  • JavaScript 및 CSS 애니메이션의 FPS 추적
  • 페이지의 매끄러운 정도를 추적하면 스크롤 (또는 보유하고 있는 멋진 무한 스크롤 목록)이 표시될 수 있습니다.
  • 기기의 현재 부하에 따라 쇼비즈 효과를 자동으로 축소합니다.
  • 런타임 성능 측정항목에 대한 회귀 테스트

엘리베이터 피치

현재 사양에 표시된 API는 다음과 같습니다. 이 API를 사용하여 JavaScript, 스타일, 레이아웃이 실행되는 렌더기 스레드 타이밍에 대한 데이터를 가져올 수 있습니다. (렌더러 스레드를 기본 스레드라고 부르는 것을 들어보셨을 것입니다. 이 스레드는 다른 이름으로 동일합니다.)

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

반환되는 각 렌더기 스레드 레코드는 대략적으로 다음과 같습니다.

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

각 레코드는 기본적으로 고유한 프레임 번호, 프레임이 시작된 시간을 나타내는 고해상도 타임스탬프, 사용된 CPU 시간을 나타내는 또 다른 값을 포함하는 객체입니다. 이러한 배열로 각 startTime 값을 살펴보고 기본 스레드가 60fps로 시작하는지 확인할 수 있습니다. 기본적으로 '각 프레임의 startTime가 약 16ms 청크로 올라가나요?'

그 밖에도 cpuTime도 얻을 수 있으므로 16ms 경계 내에 있는 것이 편안한지 아니면 유선에 진입했는지 알 수 있습니다. cpuTime가 16ms 경계 근처에 있으면 가비지 컬렉션 시작과 같은 작업을 위한 공간이 많지 않으며 CPU 사용량이 높으면 배터리 소모도 높아집니다.

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

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

또한 각각은 소스 프레임 번호를 가지며, 이 번호를 사용하여 기본 스레드의 이벤트에 다시 연결할 수 있습니다.

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

합성이 브라우저에서 자주 작동하는 방식 때문에 렌더기 스레드 레코드마다 이러한 레코드가 여러 개 있을 수 있으므로 sourceFrameNumber를 사용하여 이를 다시 연결할 수 있습니다. 이러한 기록에 CPU 시간이 있어야 하는지 여부에 관한 토론도 있으므로 GitHub 문제에 대해 적극적으로 의견을 표명할 수 있습니다.

추가 정보

이 API는 아직 출시되지 않았지만 곧 출시될 예정입니다. 그동안 다음 도움말을 읽고 참고하실 수 있습니다.