Missed the action at this year's Chrome Dev Summit? Catch up with our playlist on YouTube. Watch now.

RAIL 모델로 성능 측정

RAIL은 사용자 중심 성능 모델입니다. 모든 웹 앱은 수명 주기에 다음과 같은 뚜렷한 네 가지 측면이 있으며, 여기에 성능이 각기 다른 방식으로 적용됩니다.

RAIL 성능 모델

TL;DR

  • 사용자에게 주안점을 두세요. 최종 목표는 사이트가 기기 유형을 불문하고 어디서나 빠른 성능을 발휘하는 것이 아닙니다. 궁극적으로 사용자를 만족시키는 것이 중요합니다.
  • 사용자에게 즉각적으로 반응하세요. 사용자 입력은 100ms 내에 인지해야 합니다.
  • 애니메이션이나 스크롤 시에 10ms 이내에 프레임을 생성하세요.
  • 메인 스레드의 유휴 시간을 극대화하세요.
  • 사용자가 계속 참여하게 만드세요. 대화형 콘텐츠는 1000ms 이내에 전달하세요.

사용자에게 주안점 두기

성능 개선 노력의 초점은 사용자에게 맞추어야 합니다. 사용자가 사이트에서 보내는 시간의 대부분은 페이지가 로드되기를 기다리는 시간이 아니라 사용 중 응답을 대기하는 시간입니다. 사용자가 성능 지연을 어떻게 받아들이는지 제대로 파악해야 합니다.

지연 및 사용자 반응
0 - 16ms 사람들은 움직임을 뒤쫓는 재주가 특히 탁월하며, 부드럽지 못한 애니메이션을 싫어합니다. 초당 60개의 새 프레임으로 렌더링되면 사용자는 애니메이션을 부드럽다고 인식합니다. 이것은 프레임당 16ms에 해당하고 여기에는 브라우저가 새 프레임을 화면에 그리는 시간이 포함되며, 약 10ms는 앱이 프레임을 생성하는 시간으로 남겨둡니다.
0 - 100ms 이 시간 범위 내에 사용자 동작에 응답하면 결과가 신속하다는 느낌을 사용자가 받게 됩니다. 이보다 더 오래 걸리면 동작과 반응 사이의 연결이 끊어집니다.
100 - 300ms 사용자가 약간의 지연을 인지할 수 있습니다.
300 - 1000ms 이 시간 범위 내의 지연은 작업이 자연스럽고 지속적으로 이어지는 과정의 일부분으로 느껴집니다. 웹 상의 대부분의 사용자에게 있어 페이지 로드와 뷰 변경이 하나의 작업으로 보입니다.
1000ms 이상 1초가 넘어가면 사용자가 자신이 수행 중인 작업에서 집중력을 잃게 됩니다.
10,000ms 이상 사용자가 짜증을 내고 작업을 중도 포기할 가능성이 커지며, 나중에 다시 돌아오지 않을 수도 있습니다.

응답: 100ms 이내에 응답

사용자 입력에 100ms 이내에 응답하지 않으면 지연을 느낍니다. 이는 버튼 클릭, 양식 컨트롤 전환, 애니메이션 시작과 같은 대부분의 입력에 적용됩니다. 이것은 터치 드래그나 스크롤에는 적용되지 않습니다.

여러분이 응답하지 않으면 동작과 반응 사이의 연결이 끊어집니다. 사용자는 이런 현상을 잘 알아챕니다.

사용자의 작업에 즉시 응답하는 것이 명백한 정답으로 보일 수 있지만, 이것이 늘 옳은 방안은 아닙니다. 이 100ms의 시간 범위를 다른 고비용 작업에 사용해도 좋지만, 사용자를 가로막지 않도록 주의하세요. 가능하면 백그라운드에서 작업을 수행하세요.

완료하는 데 500ms 이상이 걸리는 작업의 경우, 항상 피드백을 제공하세요.

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

애니메이션은 단순히 멋진 UI 효과가 아닙니다. 예를 들어, 스크롤과 터치 드래그도 일종의 애니메이션입니다.

애니메이션 프레임 속도가 다르면 사용자가 눈치챕니다. 목표는 초당 60프레임을 생성하는 것이고, 모든 프레임이 다음 단계를 거쳐야 합니다.

프레임 렌더링 단계

순전히 수학적인 측면에서 보자면, 모든 프레임에는 약 16ms의 시간이 할당됩니다(1000ms / 초당 60프레임 = 프레임당 16.66ms). 그러나 브라우저가 새 프레임을 화면에 그리는 시간이 필요하므로 코드는 10ms 이내에 실행이 끝나야 합니다.

애니메이션과 같이 압박이 심한 시점에서 핵심은 가능하면 아무 작업도 하지 않는 것이며 아니면 최소한의 작업만 수행하는 것입니다. 가능하면 항상 100ms의 응답 시한을 활용하여 고비용 작업을 사전에 계산하는 것이 좋습니다. 그러면 60fps의 목표를 달성할 가능성이 극대화됩니다.

자세한 내용은 렌더링 성능을 참조하세요.

유휴: 유휴 시간 극대화

유휴 시간을 활용하여 지연된 작업을 완료합니다. 예를 들어, 미리 로드하는 데이터를 최소한으로 유지하면 앱이 빠르게 로드되며, 유휴 시간을 활용하여 남은 데이터를 로드하세요.

지연된 작업은 약 50ms 단위의 블록으로 그룹화해야 합니다. 사용자가 상호작용을 시작하면 우선순위가 가장 높은 것이 이에 응답합니다.

100ms 미만의 응답을 허용하려면 앱이 50ms 미만의 간격마다 메인 스레드에게 통제권을 양보해야 합니다. 그래야만 픽셀 파이프라인을 실행하고 사용자 입력에 반응하는 등의 여러 작업을 수행할 수 있습니다.

50ms 블록 단위로 나누면 작업을 완료하면서도 즉각적인 응답을 보장할 수 있습니다.

로드: 콘텐츠를 1000ms 이내에 전달

사이트를 1초 이내에 로드하세요. 그렇지 않으면 사용자의 주의가 흐트러지고 작업에 대한 집중도가 산만해집니다.

무엇보다 중요 렌더링 경로 최적화에 집중하여 렌더링 차단을 해제하세요.

완전히 로드되었다는 인상을 주기 위해 모든 것을 1초 이내에 로드할 필요는 없습니다. 프로그레시브 렌더링을 활성화하고 백그라운드에서 다른 작업을 수행합니다. 필수가 아닌 로드는 유휴 시간으로 미룹니다(자세한 내용은 이 웹사이트 성능 최적화 Udacity 과정을 참조하세요).

주요 RAIL 지표 요약

RAIL 지표에 따라 사이트를 평가하려면 Chrome DevTools 타임라인 도구를 사용하여 사용자 작업을 기록합니다. 그런 다음, 다음과 같은 주요 RAIL 지표에 따라 타임라인에서 기록 시간을 점검합니다.

RAIL 단계 주요 지표 사용자 작업
응답 입력 지연 시간(탭부터 페인트까지)이 100ms 미만입니다. 사용자가 버튼을 누릅니다(예: 탐색 열기).
애니메이션 각 프레임 작업(JS부터 페인트까지)의 완료 시간은 16ms 미만입니다. 사용자가 페이지를 스크롤하거나, 손가락을 드래그하거나(예: 메뉴 열기), 애니메이션을 봅니다. 손가락을 드래그할 때 손가락 위치에 따라 앱의 응답성이 달라집니다(예: 당겨서 새로고침, 캐러셀을 스와이프). 이 지표는 연속된 드래그 상태에만 적용됩니다(처음 상태에 적용되는 것이 아님).
유휴 메인 스레드 JS 작업이 50ms 이하의 조각으로 나뉩니다. 사용자가 페이지와 상호작용하지 않지만, 다음 사용자 입력을 처리할 만큼 메인 스레드를 충분히 이용할 수 있어야 합니다.
로드 페이지가 1000ms 이내에 사용할 준비가 된 것으로 간주됩니다. 사용자가 페이지를 로드하고 주요 경로 콘텐츠를 봅니다.