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

애니메이션 측정, 애니메이션 프레임 고려 방법 및 전반적인 페이지 부드러움에 대해 알아보세요.

스크롤 또는 애니메이션 중에 페이지가 '끊어지거나' '정지'되는 경우가 있을 수 있습니다. 이러한 사용 경험이 원활하지 않다고 말합니다. 이러한 유형의 문제를 해결하기 위해 Chrome팀은 애니메이션 감지를 위한 실험실 도구에 지원을 추가하고 Chromium 내의 렌더링 파이프라인 진단을 꾸준히 개선해 왔습니다.

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

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

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

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

애니메이션은 콘텐츠에 생동감을 불어넣습니다. 특히 사용자 상호작용에 응답하여 콘텐츠를 움직이게 하면 애니메이션을 더 자연스럽고 이해하기 쉬우며 재미있게 만들 수 있습니다.

그러나 잘못 구현되거나 너무 많은 애니메이션을 추가하면 사용 환경이 저하되고 전혀 재미없게 만들 수 있습니다. 아마도 '유용한' 전환 효과가 너무 많이 추가된 인터페이스와 상호작용했을 것입니다. 이러한 전환 효과는 성능이 저하될 때 실제로 경험하기 적기 때문입니다. 따라서 일부 사용자는 개발자가 적용해야 하는 사용자 환경설정인 감소된 모션을 선호할 수 있습니다.

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

간단히 요약하면 렌더링 파이프라인은 몇 가지 순차적 단계로 구성됩니다.

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

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

• 레이아웃 속성 조정
• paint 속성 조정
• 복합 속성 조정

이러한 단계는 순차적이므로 파이프라인의 더 아래쪽에 있는 속성을 기준으로 애니메이션을 정의하는 것이 중요합니다. 프로세스에서 업데이트가 일찍 이루어질수록 비용이 더 높아지고 원활하지 않을 수 있습니다. 자세한 내용은 렌더링 성능을 참고하세요.

레이아웃 속성에 애니메이션을 적용하는 것이 편리할 수 있지만, 비용이 즉시 명확하지 않더라도 비용을 발생시킵니다. 애니메이션은 가능한 경우 복합 속성 변경사항과 관련하여 정의해야 합니다.

선언적 CSS 애니메이션 또는 웹 애니메이션 사용을 정의하고 합성 속성에 애니메이션을 적용하는 것은 애니메이션을 원활하고 효율적으로 만들기 위한 좋은 첫 단계입니다. 하지만 효율적인 웹 애니메이션에도 성능 제한이 있기 때문에 이것만으로는 매끄러움이 보장되지 않습니다. 따라서 항상 측정하는 것이 중요합니다.

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

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

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

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

특정 시점에서는 디스플레이에서 할당된 기한 내에 모든 시각적 업데이트를 완료하기가 너무 어려워질 수 있습니다. 이 경우 브라우저가 프레임을 드롭합니다. 화면이 검은색으로 바뀌지 않고 반복만 표시됩니다. 동일한 시각적 업데이트, 즉 이전 프레임 기회에서 표시된 동일한 애니메이션 프레임이 조금 더 오래 표시됩니다.

실제로 이런 일이 자주 발생합니다. 특히 웹 플랫폼에서 흔히 발생하는 정적이거나 문서와 비슷한 콘텐츠의 경우 인식되지 않을 수도 있습니다. 드롭된 프레임은 부드러운 모션을 보여주기 위해 꾸준한 애니메이션 업데이트 스트림이 필요한 애니메이션과 같은 중요한 시각적 업데이트가 있는 경우에만 명확하게 나타납니다.

애니메이션 프레임에 영향을 미치는 요소는 무엇인가요?

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

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

• 대상 기기에서 빠르게 디코딩하기에는 너무 크거나 리소스를 많이 사용하는 콘텐츠를 사용하는 경우
• 너무 많은 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가 낮아지는지 알아보세요.

기본 스레드가 느려지면 시각적 업데이트가 끊기기 시작합니다. 버벅거림입니다.

많은 측정 도구는 기본 스레드가 제때 출력되고 애니메이션 프레임이 원활하게 실행되는 기능에 광범위하게 중점을 두었습니다. 그러나 이것이 전부는 아닙니다. 다음 예를 참고하세요.

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

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

이 예는 기본 스레드에서 드롭된 프레임을 많이 포함하지만 컴포지터 스레드에서 성공적으로 전달된 스크롤 프레임이 많이 있는 예입니다. 긴 작업이 완료되면 기본 스레드 페인트 업데이트에 제공할 시각적 변경사항이 없습니다. rAF 폴링은 프레임 드롭을 0으로 제안했지만 시각적으로 사용자는 차이를 알아차릴 수 없습니다.

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

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

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

애니메이션 업데이트와 애니메이션 프레임은 언제 중요할까요? 다음은 Google에서 고려하고 있으며 의견을 받고자 하는 몇 가지 기준입니다.

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

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

애니메이션 프레임 업데이트는 부울이 아닙니다. 프레임이 완전히 드롭되거나 완전히 표시되는 것은 아닙니다. 애니메이션 프레임이 부분적으로 표시되는 이유는 다양합니다. 즉, 새로운 시각적 업데이트가 표시되는 동시에 일부 오래된 콘텐츠가 있을 수 있습니다.

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

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

반면 기본 스레드 업데이트를 마침내 프레젠테이션에 사용할 수 있게 되었지만 몇 번의 프레임 기한을 놓친 후에야 할 수도 있습니다. 이 경우 브라우저에 새로운 일부 업데이트가 있지만 최신은 아닐 수 있습니다.

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

페인트 업데이트 누락

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

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

각 프레임 렌더링 기회를 통해 최신 시각적 업데이트가 실제로 화면에 얼마나 표시되었는지 추적할 수 있습니다. 여러 프레임 (또는 시간)에 걸쳐 이 작업을 수행할 수 있는 능력을 측정하는 것을 일반적으로 프레임 처리량이라고 합니다.

GPU가 정말 느려지면 브라우저 (또는 플랫폼)가 시각적 업데이트를 시도하는 속도를 제한하기 시작할 수도 있으므로 유효 프레임 속도가 저하될 수 있습니다. 이렇게 하면 기술적으로는 드롭된 프레임 업데이트 수를 줄일 수 있지만 시각적으로는 여전히 낮은 프레임 처리량으로 나타납니다.

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

그렇다면 프레임 처리량은 언제 중요할까요?

애니메이션 감지

높은 프레임 처리량은 특히 중요한 애니메이션이 있는 기간에 중요합니다. 다양한 애니메이션 유형은 특정 스레드 (기본, 컴포지터 또는 작업자)의 시각적 업데이트에 의존하므로 시각적 업데이트는 기한 내에 업데이트를 제공하는 스레드에 종속됩니다. 스레드 업데이트에 종속되는 활성 애니메이션이 있을 때마다 스레드가 부드러움에 영향을 미친다고 합니다.

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

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

질 vs. 양

마지막으로 애니메이션 및 애니메이션 프레임 업데이트 감지는 품질이 아닌 애니메이션 업데이트의 양만 캡처하므로 여전히 스토리의 일부에 불과합니다.

예를 들어 동영상을 시청하는 동안 60fps의 안정적인 프레임 속도가 표시될 수 있습니다. 기술적으로는 완벽하게 원활하지만 동영상 자체의 비트 전송률이 낮거나 네트워크 버퍼링 문제가 있을 수 있습니다. 이러한 애니메이션은 애니메이션의 부드러움 측정항목으로 직접 캡처되지 않지만 여전히 사용자를 부자연스럽게 느낄 수 있습니다.

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

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

내 말은, 아이들이 이 시간 동안 꽤 멋있었나 봐요.

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

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

다음은 단일 애니메이션 프레임의 상태를 해석하는 방법의 스펙트럼으로, 가장 낮은 경우에 해당합니다.

이러한 상태를 어느 정도 점수로 바꿀 수 있습니다. 이 점수를 해석하는 한 가지 방법은 사용자가 관찰할 수 있는 확률로 보는 것입니다. 드롭된 프레임 하나를 관찰하기는 어렵지만, 여러 드롭된 프레임의 시퀀스는 연속으로 매끄러운 정도에 영향을 미칩니다.

종합적으로 살펴보기: 드롭된 프레임 비율 측정항목

각 애니메이션 프레임의 상태를 자세히 확인해야 하는 경우도 있지만 환경에 관한 간단한 '한눈에' 점수를 할당하는 것도 유용합니다.

프레임이 부분적으로 표시될 수 있고 완전히 건너뛴 프레임 업데이트가 실제로 부드러움에 영향을 미치지 않을 수 있기 때문에 프레임 수 계산보다는 브라우저가 시각적으로 완전한 업데이트를 제공할 수 없는 범위에 더 집중하고자 합니다(중요할 때).

멘탈 모델은 다음에서 이동해야 합니다.

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

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

• 평균 드롭 비율: 전체 타임라인에서 유휴 상태가 아닌 모든 애니메이션 프레임의 경우
• 최악의 경우 드롭된 프레임 비율: 1초의 슬라이딩 윈도우에서 측정됩니다.
• 손실된 프레임 비율의 95번째 백분위수: 1초의 슬라이딩 윈도우에서 측정된 값입니다.

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

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

성능 HUD

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

프레임 렌더링 통계

새 애니메이션 프레임의 실시간 뷰를 보려면 DevTools에서 렌더링 설정을 통해 '프레임 렌더링 통계'를 사용 설정하세요. 이러한 프레임은 완전히 드롭된 프레임 업데이트와 부분 업데이트를 구별하기 위해 색상으로 구분됩니다. 보고된 fps는 완전히 표시된 프레임에만 적용됩니다.

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

DevTools 성능 패널에는 오래 전부터 Frames 뷰어가 있었습니다. 하지만 최신 렌더링 파이프라인이 실제로 작동하는 방식과 약간 어긋난 모습입니다. 최신 Chrome Canary에서도 최근에 많은 개선사항이 이루어졌으며, 이를 통해 애니메이션 문제를 훨씬 쉽게 디버깅할 수 있을 것으로 예상됩니다.

현재 프레임 뷰어의 프레임이 vsync 경계에 더 잘 맞게 정렬되고 상태에 따라 색상이 지정된 것을 확인할 수 있습니다. 위에서 설명한 모든 미묘한 차이에 대한 전체 시각화는 아직 어렵지만 가까운 시일 내에 더 추가할 계획입니다.

Chrome 추적

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

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

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

다음 단계

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

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

앞으로는 실험실은 물론 필드에서 실제 사용자의 애니메이션 부드러움을 성능 기준에 맞게 측정할 수 있는 API를 설계할 예정입니다. 이곳의 업데이트도 기대해 주세요.

의견

애니메이션 부드러움을 측정하기 위한 Chrome의 최신 개선사항과 개발자 도구가 모두 도입되었습니다. 여러 가지 도구를 사용해 보고 내 애니메이션을 벤치마킹한 다음 어디로 가면 되는지 알려주세요.

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