Towards an animation smoothness metric (한글)

이 글은 아래 원문을 번역한 글로 의역이 있을 수 있습니다. 정확한 의미를 파악하고 싶으신 분은 원문을 참고해주시기 바랍니다.

 

원문: https://web.dev/smoothness/

저작권 정보: https://creativecommons.org/licenses/by/4.0/

 

---

 

애니메이션을 측정하는 것,  애니메이션 프레임에 관해 생각하는 방법, 그리고 전반적인 페이지 동작을 부드럽게 하는 것에 대해서 알아봅시다.

 

당신은 아마 페이지가 스크롤 중에나 애니메이션을 보여주는 도중에 “버벅”거리거나 “정지” 되는 것을 경험해 봤을 겁니다. 우리는 이런 경험들을 부드럽지 않다고 얘기하곤 하죠. 이런 유형의 문제들을 해결하기 위해서, 크롬 팀은 애니메이션 감지를 위한 실험 도구에 더 많은 지원을 추가하고, Chromium 안의 렌더링 파이프라인 진단을 꾸준히 개선해 왔습니다.

우리는 최근 진행한 것들에 대해서 공유하고, 도구 가이드를 제공하고, 그리고 향후 부드러운 애니메이션을 위한 몇가지 아이디어를 논의하고자 합니다. 항상 그랬듯, 우린 여러분의 피드백을 정말 듣고 싶습니다.

 

이 포스트에서는 아래 3개의 메인 토픽을 다루고 있습니다.

• 애니메이션과 애니메이션 프레임들에 대해 빠르게 살펴봅니다.
• 전반적인 애니메이션의 부드러움을 측정하는 것에 대한 현재 저희들의 생각들
• 오늘날 실험 도구에서 활용해 볼 수 있는 몇가지 실용적인 제안들

애니메이션이란 뭘까요?

애니메이션은 콘텐츠에 생명을 불어 넣어 줍니다! 콘텐츠를 움직이게 하면서, 특히 사용자 인터렉션에 대한 반응으로, 애니메이션들은 보다 자연스럽고 이해하기 쉽고 재미있는 경험을 만들 수 있습니다.

하지만 애니메이션을 제대로 구현하지 않거나, 혹은 단지 너무 많은 애니메이션을 추가하는 것은 사용자 경험을 저하시키고 결국 재미가 없어지게 만들 수도 있습니다. 우리는 아마 너무 많은 “유용한” 전환 효과들을 추가한 인터페이스를 마주한 적이 있을 겁니다. 이런 것들은 저조한 퍼포먼스에서 반감을 주는 경험이 됩니다. 몇몇 사용자들은 기본 설정으로 되어 있는 축소된 모션들을 선호하게 됩니다.

어떻게 하면 성능 좋은 애니메이션들 만들수 있는지, 어떻게 개발자 도구를 사용해서 애니메이션을 검사하는지 등 애니메이션에 대해서 더 자세히 알아보세요.

애니메이션은 어떻게 동작 할까요?

간단히 요약하면, 렌더링 파이프라인은 다음과 같이 몇가지 순차적인 단계로 이뤄집니다.

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

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

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

이러한 단계는 순차적이기 때문에, 속성 측면에서는 파이프라인 아래쪽 단계에서 애니메이션을 정의하는 것이 중요합니다. 프로세스 초기에 업데이트가 발생할 수록, 비용이 증가하고 부드럽게 보이지 않을 수 있습니다. (자세한 내용은 렌더링 성능을 참조하세요.)

 

레이아웃 속성을 애니메이션화 하는 것은 편할 수 있지만, (그렇게 하는 것의 비용이 당장 눈에 띄지 않더라도) 결국 비용이 더 들게 됩니다. 애니메이션들은 가능한 복합 단계에서 정의해야 합니다.

 

CSS 를 선언해서 애니메이션을 정의하거나 웹 애니메이션을 사용하는 것은, 합성 단계에서 애니메이션화 하는 것을 보장해주고, 부드럽고 효과적인 애니메이션들 보장하는 좋은 첫번째 단계 입니다. 하지만 아직, 효율적인 애니메이션에도 성능 제한이 있기 때문에 이것만으로는 원활함을 보장 할 수 없습니다. 그래서 측정이 항상 중요한 것입니다!

애니메이션 프레임이란 뭘까요?

페이지의 시각적 표현에 대한 업데이트는 보여지는데 시간이 걸립니다. 시각적인 변경은 새로운 애니메이션 프레임을 생성하고, 최종적으로 사용자의 디스플레이에 렌더링됩니다.

 

화면에는 일정 간격으로 업데이트가 됩니다. 그래서 시각적 업데이트는 일괄 처리가 됩니다. 많은 디스플레이들이 1초에 60회 정도 (즉, 60Hz) 의 고정된 간격으로 업데이트를 합니다.일부 최신 디스플레이는 더 높은 비율로 제공하기도 합니다. (90-120Hz 가 흔해지고 있습니다.) 대부분의 경우 이런 디스플레이들은 필요에 따라 갱신 비율을 능동적으로 조정하거나, 완전히 가변적인 프레임 비율을 제공할 수 있습니다.

 

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

 

어느 시점에서는 디스플레이에 의해 할당된 시간 내에 모든 시각적 업데이트를 완료하기가 너무 어려울 수 있습니다. 이 경우 브라우저는 프레임을 드롭합니다. 화면이 검은색으로 되는 것이 아니라, 단지 다시 스스로 반복을 합니다. 당신은 같은 시각적 업데이트를 조금 더 길게 보게 됩니다. — 이전 프레임에서 제공되었던 애니메이션 프레임과 동일한 것이 표시됩니다.

 

이런 일은 실제로 자주 일어납니다! 특히 웹 플랫폼에서 흔히 볼 수 있는 정적 또는 문서와 같은 컨텐츠의 경우, 반드시 인식할 수 있는 것은 아닙니다. 드롭된 프레임은 애니메이션과 같은 중요한 시각적 업데이트가 있을 때만 알 수 있습니다. 이를 위해 부드러운 움직임을 보여주기 위해 지속적인 애니메이션 업데이트가 필요합니다.

어떤 것이 애니메이션 프레임에 영향을 줄까요?

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

몇 가지 예를 봅시다.

• 대상 디바이스에서 빠르게 디코딩할 수 없을 정도로 용량이 크거나 리소스가 많이 사용되는 콘텐츠를 사용하는 것
• 많은 GPU 메모리를 필요로 하는 너무 많은 레이어를 사용 하는 것
• 지나치게 복잡한 CSS 스타일 또는 웹 애니메이션을 정의 하는 것
• 빠른 렌더링 최적화를 할 수 없게 하는 안티 패턴 디자인을 사용하는 것.
• 메인 스레드에서 JS가 너무 많은 일을 해서, 시각적 업데이트를 차단하는 긴 작업으로 이끄는 것

하지만 언제 애니메이션 프레임이 데드라인을 놓쳐서 프레임 드랍을 일으키는 것을 알 수 있을까요?

requestAnimationFrame() 폴링을 사용하는 방법도 있지만, 그것은 몇가지 단점을 가지고 있습니다. requestAnimationFrame() 또는 “rAF” 는 렌더링 파이프라인의 다음 페인트 단계 전에, 브라우저에게 지금 애니메이션을 수행하길 원하고 있다고 말하며 수행할 기회를 요청합니다. 만약 당신의 콜백 함수가 예상한 때에 호출되지 않으면, 그것은 페인트가 실행되지 않은 것이고, 그리고 하나 혹은 그 이상의 프레임들이 스킵되고 있는 것입니다. 얼마나 자주 rFA 가 불리는지 카운팅하고 폴링함으로써, 당신은 일종의 “초당 프레임 수”(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() 폴링을 사용하는 것이 좋은 생각이 아닌 몇가지 이유가 있습니다.

• 모든 스크립트가 각자의 폴링 루프를 설정해야 합니다.
• 주요 경로(critical path)를 차단할 수 있습니다.
• rAF 폴링이 빠르다고 해도, requestIdleCallback() 을 막을 수 있습니다. 연속적으로 사용될 때, 긴 idle 블록 상태(single 프레임을 초과한 블록)를 스케줄을 할 수 없는 경우가 생깁니다.
• 비슷하게, 긴 idle 블록이 없으면 브라우저가 다른 장시간의 실행 작업을 스케줄링 할 수 없습니다. (긴 가비지 콜렉션이나 다른 백그라운드 작업 혹은 추측(speculative) 작업 등)
• 폴링이 온/오프를 전환하면 프레임 용량이 초과한 경우를 놓칠 수 있습니다.
• 폴링은 브라우저가 가변 업데이트 빈도(예를 들어, 전원 또는 가시성 상태 등 때문에)를 사용하는 경우 거짓된 양성 (false-positive)를 보고합니다.
• 그리고 가장 중요한 것은 실제로 모든 유형의 애니메이션 업데이트를 캡처하지 않는다는 것입니다.

메인 스레드에 너무 많은 작업을 수행하면 애니메이션 프레임을 볼 수 있는 기능에 영향을 줄 수 있습니다. 메인 스레드(레이아웃 등)에 작업이 너무 많으면 rAF 구동 애니메이션이 프레임 드롭과 rAF 콜백 감소 및 FPS 저하로 어떻게 이어지는지 Jank Sample을 확인해 보세요.

 

메인 스레드가 정지하면 시각적인 업데이트가 중단되기 시작합니다. 버벅거리면서 말이죠!

 

많은 측정 툴은 메인 스레드가 시기 적절하게 산출되고 애니메이션 프레임이 원활하게 실행될 수 있는 능력에 광범위하게 초점을 맞추고 있습니다.하지만 이게 전부는 아닙니다! 다음 예를 생각해 보겠습니다.

 

스크롤링 동영상 참고 

https://web.dev/smoothness/#what-impacts-animation-frames

 

위 비디오는 메인 스레드에 정기적으로 긴 작업을 주입하는 페이지를 보여줍니다. 이러한 긴 작업은 특정 유형의 시각적 업데이트를 제공하는 페이지의 기능을 완전히 손상시킵니다. requestAnimationFrame() 에 해당하는 왼쪽 상단 모서리에서 FPS 가 0 으로 보여지는 것을 볼 수 있습니다.

 

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

 

이는 메인 스레드에 다수의 드롭된 프레임이 동시에 포함되어 있지만 컴포지터 스레드에는 정상적으로 전달된 프레임이 다수 존재하는 예입니다. 긴 작업이 완료되고 나면, 메인 스레드 페인트 업데이트는 시각적으로 변경할 수 없습니다. rAF 폴링에서는 프레임이 0으로 떨어지는 것을 알 수 있지만 시각적으로는 차이를 알 수 없습니다.

 

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

 

긴 작업이 나쁜 이유는 여러 가지가 있습니다. 이러한 작업은 긴 작업 API나 이벤트 타이밍 API와 같은 전용 성능 API를 사용하여 캡처됩니다. 하지만 긴 태스크가 idle 기간 동안 전적으로 설계에 의해 추가되어 좋은 일이 될수도 있는 isInputPending() 같은 기능들도 있습니다.

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

위의 예는 이 이야기에 단순히 requestAnimationFrame() 보다 더 많은 것이 있음을 보여주고 있습니다.

애니메이션 업데이트와 애니메이션 프레임은 언제 중요할까요? 다음은 검토 중인 몇 가지 기준이자 피드백을 받고 싶은 부분입니다.

• 메인 스레드 및 컴포지터 스레드 업데이트
• 페인트 업데이트 누락
• 애니메이션 감지
• 품질 vs 수량

메인 및 컴포지터 스레드 업데이트

애니메이션 프레임 업데이트는 불린(boolean) 이 아닙니다. 프레임이 완전히 폐기되는 것도 완전히 표시되는 것도 아닙니다. 애니메이션 프레임이 부분적으로 표시 되는 이유는 여러 가지가 있습니다.다시 말해서, 오래된 콘텐츠를 포함하는 동시에 새로운 시각적 업데이트가 제공될 수 있습니다.

 

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

 

선언적인 애니메이션을 사용하여 합성 속성을 애니메이션화하는 것이 권장되는 중요한 이유 중 하나는 메인 스레드가 사용 중일 때에도 애니메이션을 컴포지터 스레드로 완전히 구동할 수 있다는 것입니다. 이러한 유형의 애니메이션은 계속해서 효율적이고 병렬적으로 시각적 업데이트를 생성할 수 있습니다.

 

다른 한편으로는, 메인 스레드 갱신이 최종적으로 보여주는 것에 이용 가능하게 되는 경우도 있습니다. 다만, 몇개의 프레임의 데드라인을 놓친 후에만 가능합니다. 여기서 브라우저에 새로운 업데이트가 추가되지만 최신 업데이트는 아닐 수 있습니다.

 

대략적으로 말하면, 새로운 시각적인 업데이트가 포함되어 있는 프레임은 모두 새로운 시각적 업데이트 없이 부분 프레임으로 간주됩니다. 부분 프레임은 매우 일반적입니다. 이상적으로는 부분 업데이트에는 애니메이션과 같은 가장 중요한 시각적 업데이트가 포함되지만 애니메이션이 컴포지터 스레드에 의해 구동되는 경우에만 가능합니다.

페인트 업데이트 누락

부분 업데이트의 또 다른 유형은 이미지 등의 미디어가 프레임 표시에 맞춰 디코딩 및 래스터라이징을 완료하지 않은 경우입니다.

 

또는 페이지가 완전히 고정된 상태여도, 브라우저는 빠른 스크롤 중에 시각적인 업데이트를 렌더링하는 데 지연될 수 있습니다. 이는 GPU 메모리를 절약하기 위해 가시 뷰포트를 벗어난 콘텐츠의 픽셀 렌테이션이 폐기될 수 있기 때문입니다. 픽셀을 렌더링하는 데 시간이 걸리고 손가락을 튕기는 것처럼 큰 스크롤 후에 모든 것을 렌더링하는 데 단일 프레임보다 더 오래 걸릴 수 있습니다.이것은 보통 체커보드 라고 불립니다.

 

각 프레임 렌더링을 통해 실제로 화면에 나타난 최신 비주얼 업데이트의 양을 추적할 수 있습니다. 많은 프레임(또는 시간)에 걸쳐 이 기능을 측정하는 것을 프레임 스루풋 이라고 합니다.

 

GPU가 정말로 다운되면 브라우저(또는 플랫폼)는 비주얼 업데이트를 시도하는 속도를 억제하기 시작할 수 있으며, 이로 인해 유효 프레임 속도가 저하될 수 있습니다.이를 통해 폐기된 프레임업데이트 수를 줄일 수 있지만 시각적으로는 여전히 낮은 프레임 스루풋으로 나타납니다.

 

다만, 모든 타입의 낮은 프레임 스루풋이 나쁜 것은 아닙니다. 페이지가 대부분 idle 상태이고 활성 애니메이션이 없는 경우, 낮은 프레임률은 높은 프레임률만큼 시각적으로 매력적입니다. (배터리를 절약할 수 있습니다!)

 

그럼 프레임 스루풋은 언제 중요 할까요?

애니메이션 감지

높은 프레임의 스루풋(throughput) 은 특히 중요한 애니메이션이 있는 기간 동안 중요합니다. 다른 애니메이션 유형은 특정 스레드(메인, 컴포지터 또는 워커)의 시각적 업데이트에 의존하므로 시각적 업데이트는 마감 시간 내에 업데이트를 제공하는 스레드에 의존합니다.스레드 업데이트에 따라 달라지는 활성 애니메이션이 있을 때마다 지정된 스레드 가 평활도에 영향 을 미친다고 합니다.

 

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

 

requestAnimationFrame() 와 함께라도 모든 rAF 콜이 반드시 비주얼 업데이트 또는 애니메이션을 생성한다고 가정할 수는 없습니다. 예를 들어 rAF 폴링을 사용하여 프레임 비율을 추적하는 것만으로 평활도 측정에 영향을 미치는 것은 아닙니다.이는 시각적 업데이트가 없기 때문입니다.

 

툴링의 애니메이션 검출과 브라우저의 애니메이션 구현의 구체적인 내용은 지속적으로 발전하고 개선됩니다. Chrome은 최근 배경색 애니메이션을 메인 스레드에서 컴포지터로 옮겼습니다!

품질 vs 수량

마지막으로 애니메이션과 애니메이션 프레임 업데이트를 감지하는 것은 애니메이션 업데이트의 양만 캡처하고 품질은 캡처하지 않기 때문에 여전히 이야기의 일부에 불과합니다.

 

예를 들어, 비디오를 시청하는 동안 프레임 비율이 60fps로 일정하게 표시되는 경우가 있습니다.엄밀히 말하면 이것은 매우 부드럽지만 비디오 자체의 비트환율이 낮거나 네트워크 버퍼링에 문제가 있을 수 있습니다.이는 애니메이션 평활도 메트릭에 의해 직접 캡처되지 않지만 사용자에게 여전히 거슬릴 수 있습니다.

 

또는, 이 게임을 통해 canvas (오프스크린 캔버스 등의 기술을 사용하여 안정된 프레임률을 보장함) 고품질 게임 자산을 장면에 로드하지 못하거나 렌더링 아티팩트를 표시하는 동안 애니메이션 프레임 측면에서 기술적으로 완벽하게 매끄러울 수 있습니다.

 

물론 사이트에는 정말 재미없는 애니메이션이 몇 개 있을 수 있습니다. :)

그러니까 그게 그 시간치고는 꽤 괜찮았던 것 같다구요!

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

프레임이 부분적으로 표시되는 경우도 있고, 프레임의 드롭이 부드러움에 영향을 주지 않는 경우도 있기 때문에 각 프레임에 완전성 또는 부드러움 정도의 수치가 있다고 생각하기 시작했습니다.

다음은 단일 애니메이션 프레임의 상태를 최적의 경우에서 최악의 경우 순서로 해석하는 방법의 스펙트럼입니다.

 

업데이트 필요 없음	idle 시간, 이전 프레임을 반복합니다.
완전표시	메인 스레드 업데이트가 기한 내에 커밋되었거나 메인 스레드 업데이트가 필요하지 않았습니다.
부분적으로 표시됨	컴포지터만. 지연된 메인 스레드 업데이트는 시각적 변화가 없습니다.
부분적으로 표시됨	컴포지터 전용. 메인 스레드에 시각적 업데이트가 있었지만, 해당 업데이트에는 부드러움에 영향을 미치는 애니메이션이 포함되지 않았습니다.
부분적으로 표시됨	컴포지터 전용. 메인 스레드에 부드러움에 영향을 주는 시각적 업데이트가 있었지만 이전에 오래된 프레임이 도착하여 대신 사용되었습니다.
부분적으로 표시됨	컴포지터 전용. 원하는 메인 업데이트 없이 컴포지터 업데이트에 매끄러운 정도에 영향을 미치는 애니메이션이 있습니다.
부분적으로 표시됨	컴포지터 전용이지만 컴포지터 업데이트에는 스무스함에 영향을 주는 애니메이션이 없습니다.
드롭된 프레임	업데이트 없음.원하는 컴포지터 업데이트가 없어 메인 업데이트가 지연되었습니다.
드롭된 프레임	컴포지터 업데이트가 필요했지만 지연되었습니다.
오래된 프레임	갱신이 필요한 경우 렌더러에 의해 생성되었지만 GPU가 vSync 마감일 전에 업데이트를 제공하지 않았습니다.

이 상태들을 어느 정도 수치로 만들 수 있습니다. 그리고 이 점수를 해석하는 한 가지 방법은 사용자가 관찰할 수 있는 확률로 간주하는 것입니다. 드롭된 프레임이 1개라도 그다지 눈에 띄지 않는 경우가 있습니다만, 연속해서 드롭된 프레임의 시퀀스가 매끄러움에 영향을 주는 것은 확실합니다.

모든 것을 종합해서: 드롭된 프레임 비율 메트릭

각 애니메이션 프레임의 상태를 자세히 살펴봐야 하는 경우도 있지만, 간단히 "한 눈에" 점수를 할당하는 것만으로 유용합니다.

 

프레임이 부분적으로 표시될 수 있고 완전히 건너뛴 프레임 업데이트도 실제로 평활도에 영향을 주지 않을 수 있으므로 프레임 카운트에만 초점을 맞추는 것이 아니라 브라우저가 중요할 때 시각적으로 완전한 업데이트를 제공할 수 없는 정도에 초점을 맞추고자 합니다.

정신 모델은 다음 항목에서 이동해야 합니다.

1. 초당 프레임 수(Frames per second)
2. 누락되었거나 중요한 애니메이션 업데이트 감지, 대상
3. 특정 기간 동안 드롭된 비율

중요한 것은 중요한 업데이트를 기다리는 시간의 비율입니다.이는 사용자가 실제로 웹 콘텐츠의 부드러움을 경험하는 자연스러운 방식과 일치한다고 생각합니다. 지금까지, 이하의 메트릭을 초기 세트로서 사용해 왔습니다.

• 평균 드롭된 비율 (Percend Dropped): 전체 타임라인에서 idle 상태 이외의 모든 애니메이션 프레임
• 최악의 프레임 손실률: 슬라이딩 윈도우 1초 이상 측정.
• 드롭된 프레임 비율의 95번째 백분위수: 슬라이딩 윈도우 1초 동안 측정됩니다.

이러한 점수는 현재 일부 Chrome 개발자 도구에서 확인할 수 있습니다.이러한 메트릭은 프레임 전체의 throughput에만 초점을 맞추고 있지만 프레임 지연 등의 다른 요인도 평가하고 있습니다.

 

이 이름들은 다소 역사적입니다. "Percent Dropped" 명명법은 말 그대로 "was a frame dropped" 개념과 일치하지 않게 되었습니다. 전 절에서 설명한 바와 같이, 각 애니메이션 프레임은 전체적인 확률로 이어지는 복잡한 조건 배열입니다. 이러한 이름은 시간이 지남에 따라 진화될 것으로 예상됩니다.

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

HUD 성능

Chromium은 플래그 뒤에 깔끔한 퍼포먼스 HUD가 숨겨져 있습니다.chrome://flags/#show-performance-metrics-hud 코어 Web 바이탈등의 라이브 스코어를 참조할 수 있습니다. 또, 시간 경과에 따른 드롭 프레임 비율에 근거해 애니메이션의 매끄러움에 관한 몇개의 실험적인 정의도 참조할 수 있습니다.

 

프레임 렌더링 통계 번호

렌더링 설정을 통해 개발 도구에서 “프레임 렌더링 상태” 를 활성화 시키면 새로운 애니메이션 프레임의 라이브 뷰를 볼 수 있습니다. 그것은 완전히 드롭된 프레임 업데이트와 다른 색상으로 구분할 수 있습니다. 보고되는 fps 들은 완전히 표시되는 프레임들입니다.

 

DevTools 성능 프로필 기록의 프레임 뷰어

DevTools 성능 패널에는 오랫동안 프레임 뷰어가 있었습니다. 그러나 현대 렌더링 파이프라인이 실제로 작동하는 방식과 다소 맞지 않게 되었습니다. 최신 Chrome Canary에서도 많은 개선이 이루어지고 있으며, 애니메이션 문제들을 디버깅하는 것이 크게 완화될 것으로 생각됩니다.

현재 프레임 뷰어의 프레임은 vSync 경계에 더 잘 맞춰지고 상태에 따라 색상으로 구분됩니다. 위에서 설명한 모든 뉘앙스에 대한 완전한 시각화는 아직 없지만 가까운 장래에 추가될 예정입니다.

 

크롬 트레이싱

마지막으로 Chrome Tracing을 사용하여 세부 정보를 자세히 살펴볼 수 있습니다. 새로운 Perfetto UI (혹은 about:tracing ) 을 통해서 “웹 콘텐츠 렌더링”을 추적할 수 있고, Chrome의 그래픽 파이프라인을 자세히 조사할 수 있습니다. 어려운 작업일 수도 있지만, 최근 Chromium에 추가된 몇 가지 사항을 쉽게 할 수고를 덜기 위해서입니다. 프레임의 라이프 문서에서 어떤 것이 이용가능한지 정보를 얻을 수 있습니다.

트레이스 이벤트를 통해 다음 사항을 결정할 수 있습니다.

• 어떤 애니메이션이 실행중인지 (TrackerValidation 란 이름의 이벤트 사용)
• 애니메이션 프레임들의 정확한 타임라인 가져오기(PipeineReporter 란 이름의 이벤트 사용)
• 품질이 안좋은 애니메이션 업데이트의 경우 애니메이션 실행 속도를 높이는 데 방해가 되는 요소를 정확히 파악합니다(PipelineReporter 란 이름의이벤트 사용).
• 입력 기반 애니메이션의 경우 시각적 업데이트를 받는 데 걸리는 시간을 확인하세요 (EventLatency 란 이름의 이벤트 사용)

 

다음에는

Web Vitals 계획은 웹에서 훌륭한 사용자 경험을 구축하기 위한 측정 기준과 지침을 제공하는 것을 목적으로 합니다. TBT(Total Blocking Time) 및 TTI(Time to Interactive)와 같은 랩 기반 메트릭은 잠재적인 인터랙티브 문제를 파악하고 진단하는 데 매우 중요합니다.애니메이션의 매끄러움을 실현하기 위해서, 같은 랩 베이스의 메트릭을 설계할 예정입니다.

개별 애니메이션 프레임 데이터를 기반으로 포괄적인 메트릭을 설계하기 위한 아이디어를 계속 검토하는 동안 계속 알려드리겠습니다.

향후는, 랩 뿐만이 아니라, 현장에서도 실제 유저의 애니메이션의 매끄러움을 측정할 수 있는 API를 설계하고 싶다고 생각하고 있습니다. 거기서도 최신 정보를 봐 주세요.

피드백

우리는 애니메이션의 매끄러움을 측정하기 위해 Chrome에 탑재된 최근의 모든 개선과 개발자 도구에 기대하고 있습니다.이 도구들을 사용해 보고 애니메이션을 벤치마킹한 후 어떤 결과를 가져올지 알려주세요.

제목에 "Smoothness Metrics"를 사용하여 웹 바이탈피드백 Google 그룹에 의견을 보낼 수 있습니다.여러분의 의견을 듣고 싶습니다!