RAIL은 성능에 관해 생각할 수 있는 구조를 제공하는 사용자 중심 성능 모델입니다. 이 모델은 사용자의 경험을 주요 작업 (예: 탭, 스크롤, 로드)으로 분류하고 각 작업의 성능 목표를 정의하는 데 도움을 줍니다.
RAIL은 웹 앱 수명 주기의 네 가지 측면(응답, 애니메이션, 유휴, 로드)을 나타냅니다. 사용자는 이러한 각 컨텍스트에 대해 서로 다른 성능 기대치를 가지고 있으므로 성능 목표는 컨텍스트와 사용자가 지연을 인식하는 방식에 관한 UX 연구를 기반으로 정의됩니다.
사용자 중심
사용자를 실적 개선 노력의 중심에 두세요. 아래 표에는 사용자가 성능 지연을 인식하는 방식의 주요 측정항목이 설명되어 있습니다.
성능 지연에 대한 사용자 인식| 0~16ms | 사용자는 동작을 매우 잘 추적하며 애니메이션이 매끄럽지 않으면 싫어합니다. 초당 60개의 새 프레임이 렌더링되는 한 애니메이션이 부드럽게 인식됩니다. 이는 브라우저가 새 프레임을 화면에 페인트하는 데 걸리는 시간을 포함하여 프레임당 16ms이므로 앱이 프레임을 생성하는 데 약 10ms가 남습니다. |
| 0~100ms | 이 시간 내에 사용자 작업에 응답하면 사용자에게 결과가 즉시 표시됩니다. 이보다 길어지면 행동과 반응 간의 연결이 끊어집니다. |
| 100~1,000ms | 이 창에서는 작업이 자연스럽고 연속적인 진행의 일부로 느껴집니다. 웹의 대부분 사용자에게 페이지를 로드하거나 뷰를 변경하는 것은 작업에 해당합니다. |
| 1,000ms 이상 | 1,000밀리초 (1초)가 지나면 사용자는 수행 중인 작업에 집중하지 못합니다. |
| 10000ms 이상 | 10,000밀리초 (10초)가 지나면 사용자는 답답해하고 작업을 포기할 가능성이 높습니다. 나중에 다시 돌아올 수도 있고 그렇지 않을 수도 있습니다. |
목표 및 가이드라인
RAIL 맥락에서 목표와 가이드라인이라는 용어는 다음과 같은 구체적인 의미를 갖습니다.
목표: 사용자 환경과 관련된 주요 실적 측정항목입니다. 예를 들어 100밀리초 이내에 페인팅하려면 탭합니다. 인간의 인식은 비교적 일정하므로 이러한 목표는 조만간 변경될 가능성이 낮습니다.
Guidelines를 참조하세요. 목표 달성에 도움이 되는 추천입니다. 현재 하드웨어 및 네트워크 연결 조건에 따라 달라질 수 있으므로 시간이 지남에 따라 변경될 수 있습니다.
응답: 50ms 이내에 이벤트 처리
목표: 사용자가 상호작용이 즉각적으로 이루어진다고 느낄 수 있도록 사용자 입력에 의해 시작된 전환을 100ms 내에 완료합니다.
가이드라인:
100ms 이내에 응답이 표시되도록 하려면 50ms 이내에 사용자 입력 이벤트를 처리하세요. 이는 버튼 클릭, 양식 컨트롤 전환, 애니메이션 시작과 같은 대부분의 입력에 적용됩니다. 터치 드래그나 스크롤에는 적용되지 않습니다.
직관적이지 않게 들릴 수 있지만 사용자 입력에 즉시 응답하는 것이 항상 올바른 방법은 아닙니다. 이 100ms 창을 사용하여 다른 비용이 많이 드는 작업을 할 수 있지만 사용자를 차단하지 않도록 주의하세요. 가능하면 백그라운드에서 작업을 실행합니다.
완료하는 데 50ms보다 오래 걸리는 작업의 경우 항상 피드백을 제공하세요.
50ms 또는 100ms
목표는 100ms 미만으로 입력에 응답하는 것인데 예산이 50ms인 이유는 무엇인가요? 일반적으로 입력 처리 외에 다른 작업도 실행되며 이러한 작업이 허용되는 입력 응답에 사용할 수 있는 시간의 일부를 차지하기 때문입니다. 애플리케이션이 유휴 시간 동안 권장되는 50ms 청크로 작업을 실행하는 경우 이러한 작업 청크 중 하나에서 입력이 발생하면 최대 50ms 동안 대기열에 추가될 수 있습니다. 이를 고려하면 실제 입력 처리에 사용할 수 있는 시간은 나머지 50ms뿐이라고 가정해도 됩니다. 이 효과는 유휴 작업 중에 수신된 입력이 대기열에 추가되어 사용 가능한 처리 시간을 줄이는 방식을 보여주는 아래 다이어그램에 시각화되어 있습니다.
애니메이션: 10ms 내에 프레임 생성
목표:
애니메이션의 각 프레임을 10ms 이내에 생성합니다. 기술적으로 각 프레임의 최대 예산은 16ms (1000ms / 초당 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는 페이지가 로드되거나 실행되는 동안 발생하는 모든 상황에 관한 심층 분석을 제공합니다. 런타임 성능 분석 시작하기를 참고하여 Performance 패널 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,000ms 미만으로 대화형 콘텐츠를 로드합니다.