RAIL은 성능에 대해 생각할 수 있는 구조를 제공하는 사용자 중심 성능 모델입니다. 이 모델은 사용자의 경험을 주요 작업 (예: 탭, 스크롤, 로드)으로 분류하고 각 작업의 실적 목표를 정의하는 데 도움이 됩니다.
RAIL은 웹 앱 수명 주기의 네 가지 측면인 응답, 애니메이션, 유휴, 로드를 나타냅니다. 사용자는 이러한 각 컨텍스트에 대해 서로 다른 성능 기대치를 가지므로 실적 목표는 컨텍스트와 사용자가 지연을 인식하는 방식에 관한 UX 연구를 기반으로 정의됩니다.
사용자 중심
사용자를 성능 개선 노력의 중심에 두세요. 아래 표에서는 사용자가 성능 지연을 인식하는 방식에 관한 주요 측정항목을 설명합니다.
성능 지연에 관한 사용자 인식| 0~16ms | 사용자는 움직임을 추적하는 데 매우 능숙하며 애니메이션이 매끄럽지 않으면 싫어합니다. 초당 60개의 새 프레임이 렌더링되는 한 애니메이션이 매끄럽다고 인식합니다. 이는 프레임당 16ms로, 브라우저가 새 프레임을 화면에 그리는 데 걸리는 시간을 포함하여 앱이 프레임을 생성하는 데 약 10ms가 소요됩니다. |
| 0~100ms | 이 시간 내에 사용자 작업에 응답하면 사용자는 결과가 즉각적이라고 느낍니다. 이보다 길어지면 행동과 반응 간의 연결이 끊어집니다. |
| 100~1,000ms | 이 창에서는 작업이 자연스럽고 연속적인 진행 과정의 일부로 느껴집니다. 웹의 대부분 사용자에게 페이지를 로드하거나 뷰를 변경하는 것은 하나의 작업입니다. |
| 1,000ms 이상 | 1,000밀리초 (1초)가 지나면 사용자는 수행 중인 작업에 집중하지 못합니다. |
| 10,000ms 이상 | 10,000밀리초 (10초)를 초과하면 사용자는 불만을 느끼고 작업을 포기할 가능성이 높습니다. 나중에 다시 돌아올 수도 있고 그렇지 않을 수도 있습니다. |
목표 및 가이드라인
RAIL의 맥락에서 목표 및 가이드라인이라는 용어는 특정한 의미를 갖습니다.
목표: 사용자 환경과 관련된 주요 실적 측정항목입니다. 예를 들어 탭하여 페인트하는 데 100밀리초 미만이 소요됩니다. 인간의 인식은 비교적 일정하므로 이러한 목표는 조만간 변경되지 않을 것입니다.
Guidelines를 참조하세요. 목표를 달성하는 데 도움이 되는 추천입니다. 이는 현재 하드웨어 및 네트워크 연결 상태에 따라 달라질 수 있으므로 시간이 지남에 따라 변경될 수 있습니다.
응답: 50ms 이내에 이벤트 처리
목표: 사용자가 상호작용이 즉각적이라고 느끼도록 100ms 이내에 사용자 입력으로 시작된 전환을 완료합니다.
가이드라인:
100ms 이내에 눈에 보이는 응답을 보장하려면 50ms 이내에 사용자 입력 이벤트를 처리하세요. 이는 버튼 클릭, 양식 컨트롤 전환, 애니메이션 시작과 같은 대부분의 입력에 적용됩니다. 터치 드래그 또는 스크롤에는 적용되지 않습니다.
직관에 반하는 것처럼 들릴 수 있지만, 사용자 입력에 즉시 응답하는 것이 항상 올바른 결정은 아닙니다. 이 100ms 기간을 사용하여 다른 비용이 많이 드는 작업을 실행할 수 있지만 사용자를 차단하지 않도록 주의해야 합니다. 가능하면 백그라운드에서 작업합니다.
완료하는 데 50ms 이상 걸리는 작업의 경우 항상 피드백을 제공합니다.
50ms 또는 100ms?
목표는 100ms 이내에 입력에 응답하는 것인데 예산이 50ms인 이유는 무엇인가요? 일반적으로 입력 처리 외에도 다른 작업이 진행되고 있으며, 이 작업이 허용 가능한 입력 응답에 사용할 수 있는 시간의 일부를 차지하기 때문입니다. 애플리케이션이 유휴 시간 동안 권장되는 50ms 청크로 작업을 실행하는 경우, 입력은 이러한 작업 청크 중 하나에서 발생하는 경우 최대 50ms 동안 큐에 추가될 수 있습니다. 이를 고려하면 나머지 50ms만 실제 입력 처리에 사용할 수 있다고 가정하는 것이 안전합니다. 이 효과는 아래 다이어그램에 시각화되어 있습니다. 이 다이어그램은 유휴 작업 중에 수신된 입력이 어떻게 큐에 추가되어 사용 가능한 처리 시간을 줄이는지 보여줍니다.
애니메이션: 10ms 내에 프레임 생성
목표:
애니메이션의 각 프레임을 10ms 이내에 생성합니다. 기술적으로 각 프레임의 최대 예산은 16ms (1,000ms/초당 60프레임 ≈ 16ms)이지만 브라우저에서 각 프레임을 렌더링하는 데 약 6ms가 필요하므로 프레임당 10ms 가이드라인이 적용됩니다.
시각적 부드러움을 목표로 합니다. 사용자는 프레임 속도가 달라지면 이를 알아차립니다.
가이드라인:
애니메이션과 같이 압박이 심한 지점에서는 가능한 한 아무것도 하지 않고, 불가능한 경우에는 절대적으로 최소한의 작업만 하는 것이 핵심입니다. 가능하면 100ms 응답을 사용하여 비용이 많이 드는 작업을 미리 계산하여 60fps를 달성할 가능성을 극대화하세요.
다양한 애니메이션 최적화 전략은 렌더링 성능을 참고하세요.
- 들어가기 및 나가기, 트윈, 로드 표시기와 같은 시각적 애니메이션
- 스크롤 중입니다. 여기에는 사용자가 스크롤을 시작한 후 손을 떼고 페이지가 계속 스크롤되는 플링이 포함됩니다.
- 드래그 중 애니메이션은 지도 화면 이동이나 손가락을 모으거나 벌려 확대/축소하는 등의 사용자 상호작용을 따르는 경우가 많습니다.
유휴: 유휴 시간 최대화
목표: 유휴 시간을 최대화하여 페이지가 50ms 이내에 사용자 입력에 응답할 가능성을 높입니다.
가이드라인:
유휴 시간을 사용하여 지연된 작업을 완료합니다. 예를 들어 초기 페이지 로드의 경우 가능한 한 적은 데이터를 로드한 다음 유휴 시간을 사용하여 나머지를 로드합니다.
유휴 시간 동안 50ms 이하로 작업을 실행합니다. 이보다 길면 50ms 이내에 사용자 입력에 응답하는 앱의 기능이 방해받을 수 있습니다.
사용자가 유휴 시간 작업 중에 페이지와 상호작용하는 경우 사용자 상호작용은 항상 가장 높은 우선순위를 가져야 하며 유휴 시간 작업을 중단해야 합니다.
로드: 5초 이내에 콘텐츠를 전송하고 상호작용 가능 상태로 전환
페이지 로드가 느리면 사용자의 주의가 분산되고 사용자는 작업이 중단된 것으로 인식합니다. 빠르게 로드되는 사이트는 평균 세션 시간이 길고, 이탈률이 낮으며, 광고 조회가능성이 높습니다.
목표:
사용자의 기기 및 네트워크 기능에 따라 빠른 로드 성능을 위해 최적화합니다. 현재 첫 로드의 좋은 목표는 느린 3G 연결을 사용하는 중급 휴대기기에서 5초 이내에 페이지를 로드하고 상호작용하는 것입니다.
후속 로드의 경우 2초 이내에 페이지를 로드하는 것이 좋습니다.
가이드라인:
사용자에게 일반적인 휴대기기 및 네트워크 연결에서 로드 성능을 테스트합니다. Chrome 사용자 경험 보고서를 사용하여 사용자의 연결 분포를 확인할 수 있습니다. 사이트에서 데이터를 사용할 수 없는 경우 The Mobile Economy 2019에서는 Moto G4와 같은 중급 Android 휴대전화와 느린 3G 네트워크 (400ms RTT 및 400kbps 전송 속도로 정의됨)가 적절한 글로벌 기준이라고 제안합니다. 이 조합은 WebPageTest에서 사용할 수 있습니다.
일반적인 모바일 사용자의 기기가 2G, 3G 또는 4G 연결을 사용한다고 표시하더라도 실제로는 패킷 손실 및 네트워크 변동으로 인해 유효 연결 속도가 훨씬 느린 경우가 많습니다.
완전한 로드라는 인식을 주기 위해 모든 것을 5초 이내에 로드할 필요는 없습니다. 이미지 지연 로드, JavaScript 번들 코드 분할, web.dev에서 제안하는 기타 최적화를 고려하세요.
RAIL 측정 도구
RAIL 측정을 자동화하는 데 도움이 되는 몇 가지 도구가 있습니다. 어떤 것을 사용할지는 필요한 정보 유형과 선호하는 워크플로 유형에 따라 다릅니다.
Chrome DevTools
Chrome DevTools는 페이지가 로드되거나 실행되는 동안 발생하는 모든 사항에 관한 심층 분석을 제공합니다. 성능 패널 UI에 익숙해지려면 런타임 성능 분석 시작하기를 참고하세요.
특히 다음과 같은 DevTools 기능이 관련이 있습니다.
CPU를 제한하여 성능이 낮은 기기를 시뮬레이션합니다.
네트워크를 제한하여 느린 연결을 시뮬레이션합니다.
기본 스레드 활동 보기를 선택하여 녹화하는 동안 기본 스레드에서 발생한 모든 이벤트를 확인합니다.
표에서 기본 스레드 활동을 확인하여 가장 많은 시간이 소요된 활동을 기준으로 활동을 정렬합니다.
초당 프레임 수(FPS)를 분석하여 애니메이션이 실제로 원활하게 실행되는지 측정합니다.
성능 모니터를 사용하여 CPU 사용량, JS 힙 크기, DOM 노드, 초당 레이아웃 등을 실시간으로 모니터링합니다.
네트워크 섹션으로 녹화하는 동안 발생한 네트워크 요청을 시각화합니다.
녹화 중에 스크린샷을 캡처하여 페이지가 로드되거나 애니메이션이 실행되는 동안 페이지가 어떻게 표시되었는지 정확하게 재생합니다.
상호작용을 확인하여 사용자가 페이지와 상호작용한 후 페이지에서 발생한 이벤트를 빠르게 파악합니다.
문제가 될 수 있는 리스너가 실행될 때마다 페이지를 강조 표시하여 실시간으로 스크롤 성능 문제를 찾습니다.
실시간으로 페인트 이벤트 보기: 애니메이션 성능을 저하시킬 수 있는 비용이 많이 드는 페인트 이벤트를 식별합니다.
등대
Lighthouse는 Chrome DevTools, PageSpeed Insights, Chrome 확장 프로그램, Node.js 모듈, WebPageTest에서 사용할 수 있습니다. URL을 입력하면 느린 3G 연결로 중급 기기를 시뮬레이션하고 페이지에서 일련의 감사를 실행한 다음 로드 성능에 관한 보고서와 개선 방법에 관한 제안을 제공합니다.
특히 다음과 같은 감사가 관련이 있습니다.
응답
최초 입력 반응 시간 최댓값. 기본 스레드 유휴 시간을 기준으로 앱이 사용자 입력에 응답하는 데 걸리는 시간을 추정합니다.
총 차단 시간. 마우스 클릭, 화면 탭, 키보드 누르기와 같은 사용자 입력에 대한 응답이 차단되는 총 시간을 측정합니다.
상호작용까지의 시간 사용자가 모든 페이지 요소와 일관되게 상호작용할 수 있는 시점을 측정합니다.
로드
페이지 및 start_url을 제어하는 서비스 워커를 등록하지 않습니다. 서비스 워커는 사용자의 기기에 공통 리소스를 캐시하여 네트워크를 통해 리소스를 가져오는 데 소요되는 시간을 줄일 수 있습니다.
오프스크린 이미지 지연 필요할 때까지 화면 밖 이미지 로드를 연기합니다.
적절한 이미지 크기 설정하기 모바일 표시 영역에서 렌더링되는 크기보다 훨씬 큰 이미지를 제공하지 마세요.
과도한 DOM 크기 방지 페이지를 렌더링하는 데 필요한 DOM 노드만 전송하여 네트워크 바이트를 줄입니다.
WebPageTest
WebPageTest는 실제 브라우저를 사용하여 웹페이지에 액세스하고 타이밍 측정항목을 수집하는 웹 성능 도구입니다. webpagetest.org/easy에서 URL을 입력하여 느린 3G 연결을 사용하는 실제 Moto G4 기기에서 페이지의 로드 성능에 관한 자세한 보고서를 가져옵니다. Lighthouse 감사를 포함하도록 구성할 수도 있습니다.
요약
RAIL은 웹사이트의 사용자 환경을 고유한 상호작용으로 구성된 여정으로 바라보는 렌즈입니다. 사용자가 사이트를 어떻게 인식하는지 파악하여 사용자 경험에 가장 큰 영향을 미치는 실적 목표를 설정하세요.
사용자 중심
100ms 이내에 사용자 입력에 응답합니다.
애니메이션을 적용하거나 스크롤할 때 10ms 이내에 프레임을 생성합니다.
기본 스레드 유휴 시간을 최대화합니다.
5,000밀리초 이내에 상호작용 콘텐츠를 로드합니다.