애니메이션 부드러움 측정항목에 대응

애니메이션 측정, 애니메이션 프레임에 대한 생각, 전반적인 페이지 부드러움에 대해 알아봅니다.

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

스크롤 또는 애니메이션 중에 페이지가 '버벅거리거나' '정지'되는 문제를 겪으셨을 것입니다. 이러한 환경은 원활하지 않습니다. 이러한 유형의 문제를 해결하기 위해 Chrome팀은 애니메이션 감지를 위한 실험실 도구에 더 많은 지원을 추가하고 Chromium 내의 렌더링 파이프라인 진단을 꾸준히 개선하기 위해 노력해 왔습니다.

최근 진행 상황을 공유하고 구체적인 도구 가이드를 제공하며 향후 애니메이션 부드러움 측정항목에 관한 아이디어를 논의하고자 합니다. 언제나 그렇듯이 여러분의 의견을 기다립니다.

이 게시물에서는 다음 세 가지 주요 주제를 다룹니다.

• 애니메이션 및 애니메이션 프레임을 간단히 살펴봅니다.
• 전반적인 애니메이션의 매끄러움 측정에 관한 Google의 현재 의견입니다.
• 오늘 실험실 도구에서 활용할 수 있는 몇 가지 실용적인 제안사항입니다.

애니메이션이란 무엇인가요?

애니메이션으로 콘텐츠에 생기를 불어넣으세요. 애니메이션은 특히 사용자 상호작용에 대한 응답으로 콘텐츠를 움직이게 함으로써 환경을 더 자연스럽고 이해하기 쉽고 재미있게 만들 수 있습니다.

하지만 애니메이션을 제대로 구현하지 못하거나 애니메이션을 너무 많이 추가하면 경험이 저하되고 전혀 재미가 없게 될 수 있습니다. '유용한' 전환 효과를 너무 많이 추가하여 실적이 저조할 때 사용자 환경에 해가 되는 인터페이스를 사용해 본 적이 있을 것입니다. 따라서 일부 사용자는 개발자가 준수해야 하는 사용자 환경설정인 모션 감소를 선호할 수 있습니다.

참고: 성능이 우수한 애니메이션을 만드는 방법 및 개발자 도구를 사용하여 애니메이션을 검사하는 방법을 비롯하여 애니메이션에 대해 자세히 알아보세요.

애니메이션은 어떻게 작동하나요?

다시 한번 요약하면 렌더링 파이프라인은 다음과 같은 몇 가지 순차적 단계로 구성됩니다.

1. 스타일: 요소에 적용되는 스타일을 계산합니다.
2. 레이아웃: 각 요소의 도형과 위치를 생성합니다.
3. 페인트: 각 요소의 픽셀을 레이어로 채웁니다.
4. 합성: 레이어를 화면에 그립니다.

애니메이션을 정의하는 방법은 여러 가지가 있지만 기본적으로 다음 중 하나를 통해 작동합니다.

• 레이아웃 속성을 조정합니다.
• 페인트 속성을 조정합니다.
• 복합 속성 조정

이러한 단계는 순차적이므로 파이프라인 아래에 있는 속성의 관점에서 애니메이션을 정의하는 것이 중요합니다. 프로세스에서 업데이트가 일찍 수행될수록 비용이 많이 들고 매끄러울 가능성이 낮습니다. 자세한 내용은 렌더링 성능을 참고하세요.

레이아웃 속성을 애니메이션 처리하는 것이 편리할 수 있지만, 비용이 발생하며 비용이 즉시 명확하게 표시되지는 않습니다. 애니메이션은 가능하면 복합 속성 변경을 기준으로 정의되어야 합니다.

선언적 CSS 애니메이션을 정의하거나 웹 애니메이션을 사용하고 합성 속성에 애니메이션을 적용하는 것은 원활하고 효율적인 애니메이션을 보장하기 위한 첫 번째 단계입니다. 하지만 효율적인 웹 애니메이션에도 성능 제한이 있으므로 이 자체만으로는 부드러운 애니메이션을 보장할 수 없습니다. 그렇기 때문에 실적을 측정하는 것이 항상 중요합니다.

애니메이션 프레임이란 무엇인가요?

페이지의 시각적 표현이 업데이트되려면 시간이 걸립니다. 시각적 변경을 통해 새 애니메이션 프레임이 생성되며 이 프레임은 최종적으로 사용자의 디스플레이에 렌더링됩니다.

일정 간격으로 업데이트를 표시하므로 시각적 업데이트가 일괄 처리됩니다. 많은 디스플레이는 초당 60회(즉, 60Hz)와 같이 고정된 시간 간격으로 업데이트됩니다. 일부 최신 디스플레이는 더 높은 화면 재생 빈도를 제공할 수 있습니다(90~120Hz가 일반적임). 이러한 디스플레이는 필요에 따라 새로고침 빈도를 적극적으로 조정하거나 완전히 가변적인 프레임 속도를 제공할 수도 있습니다.

게임이나 브라우저와 같은 모든 애플리케이션의 목표는 이러한 일괄 시각적 업데이트를 모두 처리하고 기한 내에 매번 시각적으로 완전한 애니메이션 프레임을 생성하는 것입니다. 이 목표는 네트워크에서 콘텐츠를 빠르게 로드하거나 JavaScript 작업을 효율적으로 실행하는 등 다른 중요한 브라우저 작업과는 완전히 다릅니다.

어느 시점에서는 디스플레이에서 할당된 기한 내에 모든 시각적 업데이트를 완료하기가 너무 어려워질 수 있습니다. 이 경우 브라우저가 프레임을 삭제합니다. 화면이 검게 변하지 않고 반복해서 켜졌다 꺼졌다를 반복합니다. 이전 프레임 기회에 표시된 것과 동일한 애니메이션 프레임이 조금 더 오래 표시됩니다.

실제로 자주 발생하는 문제입니다. 특히 웹 플랫폼에서 흔히 볼 수 있는 정적 콘텐츠나 문서와 같은 콘텐츠의 경우 반드시 인식되지도 않습니다. 프레임 누락은 애니메이션과 같이 부드러운 모션을 표시하기 위해 애니메이션 업데이트의 꾸준한 스트림이 필요한 중요한 시각적 업데이트가 있을 때만 눈에 띕니다.

애니메이션 프레임에 영향을 미치는 요인

웹 개발자는 브라우저가 시각적 업데이트를 빠르고 효율적으로 렌더링하고 표시하는 기능에 큰 영향을 미칠 수 있습니다.

예를 들면 다음과 같습니다.

• 대상 기기에서 빠르게 디코딩할 수 없을 만큼 크기가 크거나 리소스를 많이 사용하는 콘텐츠를 사용합니다.
• 너무 많은 레이어를 사용하여 GPU 메모리가 너무 많이 필요합니다.
• 지나치게 복잡한 CSS 스타일 또는 웹 애니메이션을 정의합니다.
• 빠른 렌더링 최적화를 사용 중지하는 설계 안티패턴을 사용합니다.
• 기본 스레드에서 JS 작업이 너무 많아 시각적 업데이트를 차단하는 긴 작업이 발생합니다.

하지만 애니메이션 프레임이 기한을 놓쳐 프레임이 누락된 시점을 어떻게 알 수 있을까요?

requestAnimationFrame() 폴링을 사용하는 방법이 있지만 몇 가지 단점이 있습니다. requestAnimationFrame() 또는 'rAF'는 브라우저에 애니메이션을 실행하려고 한다고 알리고 렌더링 파이프라인의 다음 페인트 단계 전에 이를 실행할 기회를 요청합니다. 예상한 시점에 콜백 함수가 호출되지 않으면 페인트가 실행되지 않아 하나 이상의 프레임을 건너뛰었습니다. rAF가 호출되는 빈도를 폴링하고 집계하여 일종의 '초당 프레임 수'(FPS) 측정항목을 계산할 수 있습니다.

경고: 다음 코드는 안티패턴이므로 사용하지 않는 것이 좋습니다.

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

requestAnimationFrame() 폴링을 사용하는 것은 여러 가지 이유로 좋지 않습니다.

• 모든 스크립트는 자체 폴링 루프를 설정해야 합니다.
• 이로 인해 중요 경로가 차단될 수 있습니다.
• rAF 폴링이 빠르더라도 연속으로 사용하면 requestIdleCallback()가 긴 유휴 블록(단일 프레임을 초과하는 블록)을 예약하지 못하게 할 수 있습니다.
• 마찬가지로 긴 유휴 블록이 없으면 브라우저가 다른 장기 실행 작업 (예: 더 긴 가비지 컬렉션, 기타 백그라운드 또는 예측 작업)을 예약할 수 없습니다.
• 폴링을 켜거나 끌 경우 프레임 예산이 초과된 케이스가 누락됩니다.
• 브라우저가 가변 업데이트 빈도를 사용하는 경우(예: 전원 또는 표시 상태로 인해) 폴링은 거짓양성을 보고합니다.
• 가장 중요한 점은 모든 유형의 애니메이션 업데이트를 실제로 캡처하지 않는다는 것입니다.

기본 스레드에서 너무 많은 작업을 수행하면 애니메이션 프레임을 보는 기능이 영향을 받을 수 있습니다. 버벅거림 샘플을 확인하여 기본 스레드에 레이아웃과 같은 작업이 너무 많으면 RAF 기반 애니메이션으로 인해 프레임이 누락되고 RAF 콜백이 줄어들고 FPS가 낮아지는 것을 확인하세요.

기본 스레드가 느려지면 시각적 업데이트가 끊기기 시작합니다. 끊김이 심해요.

많은 측정 도구는 기본 스레드가 시의적절하게 생성되고 애니메이션 프레임이 원활하게 실행되는 기능에 중점을 두었습니다. 하지만 이게 전부가 아닙니다. 다음 예를 참고하세요.

위의 동영상은 장기 작업을 기본 스레드에 주기적으로 삽입하는 페이지를 보여줍니다. 이러한 장기 작업은 특정 유형의 시각적 업데이트를 제공하는 페이지의 기능을 완전히 악화시키며, 왼쪽 상단을 보면 requestAnimationFrame()에서 보고된 FPS가 0으로 감소하는 것을 확인할 수 있습니다.

이러한 긴 작업에도 불구하고 페이지는 계속해서 부드럽게 스크롤됩니다. 이는 최신 브라우저에서 스크롤이 종종 스레드화되어 컴포저에 의해 완전히 구동되기 때문입니다.

이 예에서는 기본 스레드에 동시에 많은 프레임이 누락되었지만 컴포저 스레드에는 여전히 스크롤 프레임이 많이 전송되었습니다. 긴 작업이 완료되면 기본 스레드 페인트 업데이트에 어차피 제공할 시각적 변경사항이 없습니다. rAF 폴링은 프레임 드롭을 0으로 제안했지만 시각적으로 사용자는 차이를 알아차리지 못합니다.

애니메이션 프레임의 경우 이야기가 그렇게 간단하지 않습니다.

참고: 긴 작업이 불량한 이유는 다양합니다. 이러한 문제는 Long Tasks API 또는 Event Timing API와 같은 전용 성능 API를 사용하여 파악됩니다. 하지만 isInputPending()와 같은 기능은 유휴 시간 동안 긴 작업이 설계상 완전히 추가될 수 있으며 이는 좋은 일입니다.

애니메이션 프레임: 중요한 업데이트

위의 예는 스토리에 requestAnimationFrame() 외에도 더 많은 것이 있음을 보여줍니다.

그렇다면 애니메이션 업데이트와 애니메이션 프레임은 언제 중요한가요? 다음은 YouTube에서 고려 중이며 의견을 받고자 하는 몇 가지 기준입니다.

• 기본 및 컴포지터 스레드 업데이트
• 누락된 페인트 업데이트
• 애니메이션 감지
• 질 vs. 양

기본 및 컴포지터 스레드 업데이트

애니메이션 프레임 업데이트는 불리언이 아닙니다. 프레임이 완전히 삭제되거나 완전히 표시될 수만 있는 것은 아닙니다. 애니메이션 프레임이 부분적으로 표시되는 데는 여러 가지 이유가 있습니다. 즉, 오래된 콘텐츠가 표시되는 동시에 새로운 시각적 업데이트가 표시될 수 있습니다.

가장 일반적인 예는 브라우저가 프레임 기한 내에 새 기본 스레드 업데이트를 생성할 수 없지만 새 컴포지터 스레드 업데이트가 있는 경우입니다 (예: 이전의 스레드 스크롤 예).

선언적 애니메이션을 사용하여 합성 속성에 애니메이션을 적용하는 것이 권장되는 한 가지 중요한 이유는 이렇게 하면 기본 스레드가 사용 중이더라도 애니메이션을 컴포저 스레드에서 완전히 구동할 수 있기 때문입니다. 이러한 유형의 애니메이션은 시각적 업데이트를 효율적으로 동시에 계속 생성할 수 있습니다.

반면에 기본 스레드 업데이트를 프레젠테이션에 사용할 수 있게 되더라도 여러 프레임 기한을 놓친 후에야 가능할 수 있습니다. 여기서 브라우저에 일부 새로운 업데이트가 있지만 최신 버전은 아닐 수 있습니다.

일반적으로 모든 새로운 시각적 업데이트 없이 새로운 시각적 업데이트가 포함된 프레임을 부분 프레임으로 간주합니다. 부분 프레임은 매우 흔합니다. 부분 업데이트에는 최소한 애니메이션과 같이 가장 중요한 시각적 업데이트가 포함되는 것이 이상적이지만 이는 애니메이션이 컴포지터 스레드에 의해 구동되는 경우에만 발생할 수 있습니다.

누락된 페인트 업데이트

또 다른 유형의 부분 업데이트는 이미지와 같은 미디어가 프레임 프레젠테이션에 맞춰 디코딩 및 래스터링을 완료하지 못한 경우입니다.

또는 페이지가 완전히 정적인 경우에도 빠른 스크롤 중에 브라우저가 시각적 업데이트 렌더링에 뒤처질 수 있습니다. 이는 GPU 메모리를 절약하기 위해 표시되는 뷰포트 밖의 콘텐츠의 픽셀 렌더링이 삭제될 수 있기 때문입니다. 픽셀을 렌더링하는 데 시간이 걸리며 손가락 플링과 같이 크게 스크롤한 후 모든 것을 렌더링하는 데 단일 프레임보다 더 오래 걸릴 수 있습니다. 이를 일반적으로 체크보드라고 합니다.

각 프레임 렌더링 기회를 통해 최신 시각적 업데이트가 실제로 화면에 얼마나 도달했는지 추적할 수 있습니다. 많은 프레임 (또는 시간)에 걸쳐 이를 수행하는 기능을 측정하는 것을 광범위하게 프레임 처리량이라고 합니다.

GPU가 매우 빠르게 멈춘 경우에는 브라우저 (또는 플랫폼)가 시각적 업데이트를 시도하는 속도를 제한하기 시작하여 유효 프레임 속도가 감소할 수 있습니다. 기술적으로는 프레임 업데이트가 중단되는 횟수를 줄일 수 있지만 시각적으로는 프레임 처리량이 낮은 것으로 보입니다.

하지만 모든 유형의 로우 프레임 처리량이 나쁜 것은 아닙니다. 페이지가 대부분 유휴 상태이고 활성 애니메이션이 없는 경우 낮은 프레임 속도도 높은 프레임 속도만큼 시각적으로 매력적이며 배터리도 절약할 수 있습니다.

프레임 처리량이 중요한 경우는 언제인가요?

애니메이션 감지

높은 프레임 처리량은 특히 중요한 애니메이션이 있는 기간에 중요합니다. 애니메이션 유형은 특정 스레드(메인, 컴포저 또는 작업자)의 시각적 업데이트에 따라 달라지므로 시각적 업데이트는 해당 스레드가 기한 내에 업데이트를 제공하는지에 따라 달라집니다. 해당 스레드 업데이트에 종속된 활성 애니메이션이 있을 때마다 지정된 스레드가 부드러움에 영향을 미칩니다.

일부 애니메이션 유형은 다른 유형보다 더 쉽게 정의하고 감지할 수 있습니다. 선언적 애니메이션 또는 사용자 입력 기반 애니메이션은 애니메이션 가능한 스타일 속성의 주기적 업데이트로 구현된 JavaScript 기반 애니메이션보다 더 명확하게 정의할 수 있습니다.

requestAnimationFrame()를 사용하더라도 모든 RAF 호출이 시각적 업데이트나 애니메이션을 반드시 생성한다고 가정할 수는 없습니다. 예를 들어 프레임 속도를 추적하기 위해만 RAF 폴링을 사용하면(위 그림 참고) 시각적 업데이트가 없으므로 자체적으로 부드러움 측정에 영향을 미치지 않습니다.

참고: 도구의 애니메이션 감지와 브라우저의 애니메이션 구현 세부정보는 지속적으로 발전하고 개선됩니다. Chrome은 최근 background-color 애니메이션을 기본 스레드에서 컴포저이터로 이동했습니다.

질 vs. 양

마지막으로 애니메이션 및 애니메이션 프레임 업데이트를 감지하는 것은 애니메이션 업데이트의 수량만 포착할 뿐 품질은 포착하지 않으므로 전체 이야기의 일부에 불과합니다.

예를 들어 동영상을 시청하는 동안 프레임 속도가 60fps로 안정적일 수 있습니다. 기술적으로는 완벽하게 원활하지만 동영상 자체의 비트 전송률이 낮거나 네트워크 버퍼링 문제가 있을 수 있습니다. 이는 애니메이션 부드러움 측정항목에 직접 반영되지는 않지만 사용자에게 불편을 줄 수 있습니다.

또는 <canvas>를 활용하는 게임 (안정적인 프레임 속도를 보장하기 위해 오프스크린 캔버스와 같은 기술을 사용할 수도 있음)는 애니메이션 프레임 측면에서 기술적으로 완벽하게 매끄러울 수 있지만, 이 과정에서 고품질 게임 애셋을 장면에 로드하지 못하거나 렌더링 아티팩트를 표시하지 못할 수도 있습니다.

물론 사이트에 정말 나쁜 애니메이션이 있을 수도 있습니다. 🙂

그 당시에는 꽤 멋졌을 것 같아요.

단일 애니메이션 프레임의 상태

프레임이 부분적으로 표시되거나 프레임이 누락되는 방식이 매끄러움에 영향을 미치지 않을 수 있으므로 각 프레임에 완성도 또는 매끄러움 점수가 있다고 생각하기 시작했습니다.

다음은 단일 애니메이션 프레임의 상태를 해석하는 방법의 스펙트럼으로, 최선의 경우부터 최악의 경우로 정렬되어 있습니다.

업데이트 불필요	유휴 시간, 이전 프레임의 반복
전체적으로 표시됨	기본 스레드 업데이트가 기한 내에 커밋되었거나 기본 스레드 업데이트가 필요하지 않았습니다.
부분적으로 제출함	컴포저만 해당. 지연된 기본 스레드 업데이트에는 시각적 변경사항이 없었습니다.
부분적으로 제출함	컴포저만 해당. 기본 스레드에 시각적 업데이트가 있었지만 이 업데이트에는 부드러움에 영향을 미치는 애니메이션이 포함되지 않았습니다.
부분적으로 제출함	컴포저만 해당. 기본 스레드에 부드러움에 영향을 미치는 시각적 업데이트가 있었지만 이전에 비활성 상태였던 프레임이 도착하여 대신 사용되었습니다.
부분적으로 제출함	컴포지터만. 원하는 기본 업데이트가 없으며 컴포지터 업데이트에 부드러움에 영향을 미치는 애니메이션이 있습니다.
부분적으로 제출함	컴포저에만 해당하지만 컴포저 업데이트에는 부드러움에 영향을 미치는 애니메이션이 없습니다.
드롭된 프레임	업데이트 없음 원하는 컴포저이터 업데이트가 없으며 기본이 지연되었습니다.
프레임 누락	컴포지터 업데이트가 필요했지만 지연되었습니다.
비활성 프레임	업데이트가 필요하고 렌더러에서 생성되었지만 vsync 기한 전에 GPU가 여전히 업데이트를 제시하지 않았습니다.

이러한 상태를 일종의 점수로 변환할 수 있습니다. 이 점수를 해석하는 한 가지 방법은 사용자가 관찰할 수 있는 확률로 간주하는 것입니다. 단일 프레임 드롭은 눈에 잘 띄지 않을 수 있지만, 연속적으로 발생하여 화면의 부드러움에 영향을 미치는 많은 프레임 드롭 시퀀스는 확실히 눈에 띕니다.

요약 정리: 프레임 누락 비율 측정항목

각 애니메이션 프레임의 상태를 자세히 살펴볼 필요가 있는 경우도 있지만 환경에 대한 빠른 '한눈에 보기' 점수를 할당하는 것도 유용합니다.

프레임이 부분적으로 표시될 수 있고 프레임 업데이트를 완전히 건너뛰더라도 실제로 부드러움에 영향을 미치지 않을 수 있으므로 프레임 수를 세는 것보다는 브라우저가 중요한 경우 시각적으로 완전한 업데이트를 제공할 수 없는 정도에 더 중점을 두어야 합니다.

멘탈 모델은 다음에서 나아가야 합니다.

1. 초당 프레임 수를
2. 누락된 중요한 애니메이션 업데이트를 감지하여
3. 특정 기간 동안 감소 비율입니다.

중요한 것은 중요한 업데이트를 기다리는 시간의 비율입니다. 이는 사용자가 실제로 웹 콘텐츠의 매끄러움을 경험하는 자연스러운 방식과 일치한다고 생각합니다. 지금까지는 다음을 초기 측정항목 집합으로 사용해 왔습니다.

• 평균 중단 비율: 전체 타임라인에서 유휴 상태가 아닌 모든 애니메이션 프레임에 대해
• 최악의 프레임 드롭 비율: 1초 슬라이딩 윈도우에 걸쳐 측정됨
• 프레임 누락 비율의 95번째 백분위수: 1초 슬라이딩 시간 구간에서 측정합니다.

현재 일부 Chrome 개발자 도구에서 이러한 점수를 확인할 수 있습니다. 이러한 측정항목은 전체 프레임 처리량에만 초점을 맞추지만 프레임 지연 시간과 같은 다른 요소도 평가하고 있습니다.

참고: 이러한 이름은 다소 오래된 이름입니다. 'Percent Dropped' 이름 지정은 더 이상 '프레임 드롭됨' 개념과 일치하지 않습니다. 이전 섹션에서 설명한 대로 각 애니메이션 프레임은 전반적인 확률로 이어지는 조건의 복잡한 배열입니다. 이러한 이름은 시간이 지남에 따라 진화할 것으로 예상됩니다.

개발자 도구에서 직접 사용해 보세요.

성능 HUD

Chromium에는 플래그(chrome://flags/#show-performance-metrics-hud) 뒤에 깔끔한 성능 HUD가 있습니다. 여기에서 코어 웹 바이탈과 같은 항목의 실시간 점수와 시간 경과에 따른 프레임 누락 비율을 기반으로 한 애니메이션 부드러움에 관한 몇 가지 실험적 정의를 확인할 수 있습니다.

프레임 렌더링 통계

DevTools에서 렌더링 설정을 통해 '프레임 렌더링 통계'를 사용 설정하면 새로운 애니메이션 프레임의 실시간 보기를 확인할 수 있습니다. 새로운 애니메이션 프레임은 색상으로 구분됩니다. 이 프레임은 완전히 드롭된 프레임 업데이트와 부분 업데이트를 구분하기 위해 색상으로 구분됩니다. 보고된 fps는 완전히 표시된 프레임에만 해당합니다.

DevTools 성능 프로필 녹화 파일의 프레임 뷰어

DevTools 성능 패널에는 오래 전부터 프레임 뷰어가 있었습니다. 그러나 최신 렌더링 파이프라인의 실제 작동 방식과 약간 동기화되지 않았습니다. 최근에는 최신 Chrome Canary에서도 많은 개선사항이 적용되어 애니메이션 문제의 디버깅이 크게 쉬워질 것으로 기대됩니다.

이제 프레임 뷰어의 프레임이 vsync 경계와 더 잘 정렬되고 상태에 따라 색상이 지정됩니다. 위에 설명된 모든 뉘앙스에 대한 전체 시각화는 아직 제공되지 않지만 가까운 시일 내에 추가할 계획입니다.

Chrome 추적

마지막으로 세부정보를 자세히 살펴볼 때 사용하는 Chrome 추적을 사용하면 새 Perfetto UI(또는 about:tracing)를 통해 '웹 콘텐츠 렌더링' 트레이스를 기록하고 Chrome의 그래픽 파이프라인을 자세히 살펴볼 수 있습니다. 이 작업은 쉽지 않지만 최근 Chromium에 이를 더 쉽게 수행할 수 있는 몇 가지 기능이 추가되었습니다. 프레임의 수명 문서에서 사용 가능한 기능을 간략히 살펴볼 수 있습니다.

트레이스 이벤트를 통해 다음을 확실하게 확인할 수 있습니다.

• 실행 중인 애니메이션(TrackerValidation라는 이벤트 사용)
• PipelineReporter라는 이벤트를 사용하여 애니메이션 프레임의 정확한 타임라인을 가져옵니다.
• 애니메이션 업데이트가 끊기는 경우 PipelineReporter 이벤트 내의 이벤트 분류를 사용하여 애니메이션이 더 빠르게 실행되지 못하게 하는 요소를 정확하게 파악합니다.
• 입력 기반 애니메이션의 경우 시각적 업데이트를 가져오는 데 걸리는 시간을 확인합니다(EventLatency라는 이벤트 사용).

다음 단계

웹 바이탈 이니셔티브는 웹에서 우수한 사용자 환경을 구축하기 위한 측정항목과 안내를 제공하는 것을 목표로 합니다. 총 차단 시간 (TBT)과 같은 실습 기반 측정항목은 잠재적인 상호작용 문제를 파악하고 진단하는 데 중요합니다. 애니메이션 부드러움에 관한 유사한 실험실 기반 측정항목을 설계할 계획입니다.

개별 애니메이션 프레임 데이터를 기반으로 포괄적인 측정항목을 설계하기 위한 아이디어를 계속해서 검토하는 동안 새로운 소식을 전해드리겠습니다.

향후 실험실은 물론 필드에서 실제 사용자를 위해 애니메이션의 매끄러운 동작을 효과적으로 측정할 수 있는 API를 설계하고자 합니다. 이 사이트에서 새로운 소식도 기대해 주세요.

의견

애니메이션의 부드러움을 측정하기 위해 Chrome에 제공된 최근의 모든 개선사항과 개발자 도구를 기쁘게 생각합니다. 이 도구를 사용해 보고 애니메이션을 벤치마킹한 후 결과를 알려주세요.

제목에 '[Smoothness Metrics](부드러움 측정항목)'를 포함하여 web-vitals-feedback Google 그룹에 의견을 보낼 수 있습니다. 여러분의 의견을 기다리겠습니다.