RAIL 모델을 사용한 성능 측정

RAIL은 성능을 고려하기 위한 구조를 제공하는 사용자 중심 성능 모델입니다. 이 모델은 사용자 환경을 주요 작업 (예: 탭, 스크롤, 로드)으로 분류하고 각 작업의 성능 목표를 정의하는 데 도움을 줍니다.

RAIL은 웹 앱 수명 주기의 4가지 측면, 즉 응답, 애니메이션, 유휴, 로드를 나타냅니다. 사용자는 이러한 컨텍스트마다 성능 기대치가 다르므로 성능 목표는 컨텍스트와 사용자의 지연 인식 방식에 관한 UX 연구를 기반으로 정의됩니다.

RAIL 성능 모델의 4개 부분: 응답, 애니메이션, 유휴, 로드
RAIL 성능 모델의 4가지 부분

사용자 중심

실적을 높이기 위해 사용자에게 초점을 맞춥니다. 아래 표는 사용자가 성능 지연을 인식하는 방식에 관한 주요 측정항목을 설명합니다.

성능 지연에 대한 사용자의 인식
0~16밀리초 사용자는 모션을 추적하는 데 매우 능숙하며, 애니메이션이 매끄럽지 않으면 싫어합니다. 초당 60개의 새로운 프레임이 렌더링된다면 애니메이션을 부드럽게 인식합니다. 프레임당 16ms이며 브라우저에서 새 프레임을 화면에 그리는 데 걸리는 시간을 포함하여 앱에서 프레임을 생성하는 데 약 10ms가 걸립니다.
0~100ms 이 기간 내에 사용자 작업에 응답하면 사용자는 결과가 즉각적이라고 느낄 수 있습니다. 이보다 더 오래 걸리면 동작과 반응 사이의 연결이 끊어집니다.
100~1,000ms 이 시간 동안은 작업이 자연스럽고 지속적으로 진행되는 과정의 일부라고 느낍니다. 대부분의 웹 사용자에게 페이지 로드나 뷰 변경은 하나의 작업으로 간주됩니다.
1,000ms 이상 1,000밀리초 (1초)가 지나면 사용자는 수행 중인 작업에 집중하지 못하게 됩니다.
10,000밀리초 이상 10,000밀리초 (10초)가 지나면 사용자는 불만을 느끼고 작업을 중단할 가능성이 높습니다. 나중에 다시 확인할 수도 있고, 그렇지 않을 수도 있습니다.

목표 및 가이드라인

RAIL 맥락에서 목표가이드라인이라는 용어는 구체적인 의미를 지닙니다.

  • 목표. 사용자 환경과 관련된 주요 실적 측정항목입니다. 예를 들어 탭하면 100밀리초 이내에 페인팅할 수 있습니다. 사람의 인식은 비교적 일정하므로 이러한 목표는 금방 바뀌지 않을 것입니다.

  • Guidelines를 참조하세요. 목표를 달성하는 데 도움이 되는 권장사항입니다. 현재 하드웨어 및 네트워크 연결 조건에 따라 다를 수 있으므로 시간이 지남에 따라 변경될 수 있습니다.

응답: 50ms 이내에 이벤트 처리

목표: 사용자가 상호작용이 즉시 발생한 것처럼 느끼도록 100ms 이내에 사용자 입력에 의해 시작된 전환을 완료합니다.

가이드라인:

  • 100ms 이내에 시각적 응답을 제공하려면 50ms 이내에 사용자 입력 이벤트를 처리합니다. 이는 버튼 클릭, 양식 컨트롤 전환, 애니메이션 시작과 같은 대부분의 입력에 적용됩니다. 이는 터치 드래그나 스크롤에는 적용되지 않습니다.

  • 직관적이지 않을 수 있지만 사용자 입력에 즉시 응답하는 방법이 항상 올바른 것은 아닙니다. 이 100ms 기간을 사용하여 비용이 많이 드는 다른 작업을 실행할 수 있지만 사용자를 차단하지 않도록 주의하세요. 가능하면 백그라운드에서 작업하세요.

  • 완료하는 데 50밀리초 초보다 오래 걸리는 작업의 경우 항상 의견을 제공하세요.

50ms 또는 100ms 중 어느 쪽인가요?

목표는 100ms 미만에 입력에 응답하는 것이 있는데 예산이 50ms에 불과한 이유는 무엇일까요? 이는 일반적으로 입력 처리 외에도 다른 작업이 진행되며 이 작업이 허용되는 입력 응답에 사용할 수 있는 시간을 차지하기 때문입니다. 애플리케이션이 유휴 시간 동안 권장 50ms 단위로 작업을 실행한다면 이는 이러한 작업 청크 중 하나에서 입력이 발생하면 최대 50ms 동안 큐에 추가될 수 있음을 의미합니다. 따라서 나머지 50ms만 실제 입력 처리에 사용할 수 있다고 가정하는 것이 안전합니다. 이 효과는 아래 다이어그램에 시각화되어 있습니다. 이는 유휴 작업 중에 수신된 입력이 큐에 추가되어 사용 가능한 처리 시간이 어떻게 단축되는지 보여줍니다.

유휴 작업 중에 수신된 입력이 큐에 추가되어 사용 가능한 입력 처리 시간을 50ms로 단축하는 방법을 보여주는 다이어그램
유휴 태스크가 입력 응답 예산에 미치는 영향

애니메이션: 10ms 안에 프레임 생성

목표:

  • 애니메이션의 각 프레임을 10ms 이내에 제작합니다. 기술적으로 각 프레임의 최대 예산은 16ms (초당 1,000ms / 초당 60프레임 약 16ms)이지만 브라우저에서 각 프레임을 렌더링하는 데 약 6ms가 필요하므로 프레임당 10ms가 가이드라인입니다.

  • 시각적인 부드러움을 목표로 합니다. 사용자는 프레임 속도가 다양한 경우 알아차립니다.

가이드라인:

  • 애니메이션과 같이 압박이 심한 시점에서 핵심은 할 수 있는 곳에서는 아무것도 하지 않는 것이고, 할 수 없는 절대 최소 조치는 하는 것입니다. 가능하면 100ms 응답을 활용하여 값비싼 작업을 미리 계산하여 60fps에 도달할 가능성을 최대화할 수 있습니다.

  • 다양한 애니메이션 최적화 전략은 렌더링 성능을 참고하세요.

  • 진입 및 이탈, 트윈, 로드 표시기 등의 시각적 애니메이션
  • 스크롤 여기에는 사용자가 스크롤을 시작했다가 놓아서 페이지가 계속 스크롤되는 플링이 포함됩니다.
  • 드래그. 애니메이션은 지도 화면 이동 또는 손가락을 모아 확대/축소하는 등의 사용자 상호작용을 따르는 경우가 많습니다.

유휴: 유휴 시간 극대화

목표: 유휴 시간을 극대화하여 페이지가 사용자 입력에 50ms 이내에 응답할 확률을 높입니다.

가이드라인:

  • 유휴 시간을 사용하여 지연된 작업을 완료합니다. 예를 들어 초기 페이지 로드의 경우 데이터를 가능한 한 적게 로드한 다음 유휴 시간을 사용하여 나머지 데이터를 로드합니다.

  • 유휴 시간 동안 50ms 이내에 작업 수행 그보다 오래 걸리면 앱이 50ms 이내에 사용자 입력에 응답하는 데 방해가 될 수 있습니다.

  • 사용자가 유휴 시간 작업 중에 페이지와 상호작용하는 경우 사용자 상호작용은 항상 가장 높은 우선순위를 가져야 하며 유휴 시간 작업을 중단해야 합니다.

로드: 5초 이내에 콘텐츠를 전송하고 상호작용할 수 있습니다.

페이지 로드 속도가 느리면 사용자의 주의가 산만해지고 사용자는 작업이 중단된 것으로 인식합니다. 빠르게 로드되는 사이트는 평균 세션 시간이 길고 이탈률이 낮으며 광고 조회가능성이 높습니다.

목표:

가이드라인:

RAIL 측정 도구

RAIL 측정을 자동화하는 데 도움이 되는 몇 가지 도구가 있습니다. 필요한 정보의 유형과 선호하는 워크플로 유형에 따라 사용할 방법이 다릅니다.

Chrome DevTools

Chrome DevTools는 페이지가 로드되거나 실행되는 동안 발생하는 모든 사항에 관한 심층 분석을 제공합니다. 성능 패널 UI에 익숙해지려면 런타임 성능 분석 시작하기를 참고하세요.

특히 다음과 같은 DevTools 기능이 유용합니다.

등대

Lighthouse는 Chrome DevTools, PageSpeed Insights, Chrome 확장 프로그램, Node.js 모듈, WebPageTest 내에서 사용할 수 있습니다. 여기에 URL을 입력하면 3G 연결이 느린 중급 기기를 시뮬레이션하고 페이지에서 일련의 감사를 실행한 다음 로드 성능에 관한 보고서와 개선 방법에 관한 제안을 제공합니다.

특히 다음과 같은 감사가 중요합니다.

응답

로드

WebPageTest

WebPageTest는 실제 브라우저를 사용하여 웹페이지에 액세스하고 시간 측정항목을 수집하는 웹 성능 도구입니다. webpagetest.org/easy에 URL을 입력하여 3G 연결 속도가 느린 실제 Moto G4 기기의 페이지 로드 성능에 관한 자세한 보고서를 받아 보세요. Lighthouse 감사를 포함하도록 구성할 수도 있습니다.

요약

RAIL은 웹사이트의 사용자 환경을 고유한 상호작용으로 구성된 여정으로 보는 렌즈입니다. 사용자가 사이트에 대해 어떻게 생각하는지 파악하여 사용자 환경에 가장 큰 영향을 미치는 실적 목표를 설정합니다.

  • 사용자 중심

  • 100ms 이내에 사용자 입력에 응답합니다.

  • 애니메이션 처리 또는 스크롤 시 10ms 이내에 프레임을 생성합니다.

  • 기본 스레드의 유휴 시간을 극대화합니다.

  • 대화형 콘텐츠를 5,000ms 미만에 로드합니다.