RAIL은 성능을 고려하기 위한 구조를 제공하는 사용자 중심 성능 모델입니다. 이 모델은 사용자 환경을 주요 작업 (예: 탭, 스크롤, 로드)으로 분류하고 각 작업의 성능 목표를 정의하는 데 도움을 줍니다.
RAIL은 웹 앱 수명 주기의 4가지 측면, 즉 응답, 애니메이션, 유휴, 로드를 나타냅니다. 사용자는 이러한 컨텍스트마다 성능 기대치가 다르므로 성능 목표는 컨텍스트와 사용자의 지연 인식 방식에 관한 UX 연구를 기반으로 정의됩니다.
사용자 중심
실적을 높이기 위해 사용자에게 초점을 맞춥니다. 아래 표는 사용자가 성능 지연을 인식하는 방식에 관한 주요 측정항목을 설명합니다.
성능 지연에 대한 사용자의 인식| 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만 실제 입력 처리에 사용할 수 있다고 가정하는 것이 안전합니다. 이 효과는 아래 다이어그램에 시각화되어 있습니다. 이는 유휴 작업 중에 수신된 입력이 큐에 추가되어 사용 가능한 처리 시간이 어떻게 단축되는지 보여줍니다.
애니메이션: 10ms 안에 프레임 생성
목표:
애니메이션의 각 프레임을 10ms 이내에 제작합니다. 기술적으로 각 프레임의 최대 예산은 16ms (초당 1,000ms / 초당 60프레임 약 16ms)이지만 브라우저에서 각 프레임을 렌더링하는 데 약 6ms가 필요하므로 프레임당 10ms가 가이드라인입니다.
시각적인 부드러움을 목표로 합니다. 사용자는 프레임 속도가 다양한 경우 알아차립니다.
가이드라인:
애니메이션과 같이 압박이 심한 시점에서 핵심은 할 수 있는 곳에서는 아무것도 하지 않는 것이고, 할 수 없는 절대 최소 조치는 하는 것입니다. 가능하면 100ms 응답을 활용하여 값비싼 작업을 미리 계산하여 60fps에 도달할 가능성을 최대화할 수 있습니다.
다양한 애니메이션 최적화 전략은 렌더링 성능을 참고하세요.
- 진입 및 이탈, 트윈, 로드 표시기 등의 시각적 애니메이션
- 스크롤 여기에는 사용자가 스크롤을 시작했다가 놓아서 페이지가 계속 스크롤되는 플링이 포함됩니다.
- 드래그. 애니메이션은 지도 화면 이동 또는 손가락을 모아 확대/축소하는 등의 사용자 상호작용을 따르는 경우가 많습니다.
유휴: 유휴 시간 극대화
목표: 유휴 시간을 극대화하여 페이지가 사용자 입력에 50ms 이내에 응답할 확률을 높입니다.
가이드라인:
유휴 시간을 사용하여 지연된 작업을 완료합니다. 예를 들어 초기 페이지 로드의 경우 데이터를 가능한 한 적게 로드한 다음 유휴 시간을 사용하여 나머지 데이터를 로드합니다.
유휴 시간 동안 50ms 이내에 작업 수행 그보다 오래 걸리면 앱이 50ms 이내에 사용자 입력에 응답하는 데 방해가 될 수 있습니다.
사용자가 유휴 시간 작업 중에 페이지와 상호작용하는 경우 사용자 상호작용은 항상 가장 높은 우선순위를 가져야 하며 유휴 시간 작업을 중단해야 합니다.
로드: 5초 이내에 콘텐츠를 전송하고 상호작용할 수 있습니다.
페이지 로드 속도가 느리면 사용자의 주의가 산만해지고 사용자는 작업이 중단된 것으로 인식합니다. 빠르게 로드되는 사이트는 평균 세션 시간이 길고 이탈률이 낮으며 광고 조회가능성이 높습니다.
목표:
사용자의 기기 및 네트워크 기능을 기준으로 빠른 로드 성능을 위해 최적화합니다. 현재 첫 번째 로드에 적합한 목표는 페이지를 로드하고 3G 연결이 느린 중급형 휴대기기에서 5초 이내에 상호작용하는 것입니다.
후속 로드의 경우 2초 이내에 페이지를 로드하는 것이 좋습니다.
가이드라인:
사용자들 사이에서 일반적인 휴대기기 및 네트워크 연결에서 부하 성능을 테스트합니다. Chrome 사용자 환경 보고서를 사용하여 사용자의 연결 분포를 확인할 수 있습니다. 사이트에 관한 데이터를 사용할 수 없는 경우 모바일 경제 2019에서는 글로벌 기준이 Moto G4와 같은 중저가 Android 휴대전화와 느린 3G 네트워크 (400ms RTT 및 400kbps 전송 속도로 정의됨)를 글로벌 기준으로 삼을 것을 권장합니다. 이 조합은 WebPageTest에서 사용할 수 있습니다.
일반적인 모바일 사용자의 기기가 2G, 3G 또는 4G 연결을 사용한다고 주장할 수도 있지만, 실제로는 패킷 손실 및 네트워크 편차로 인해 실제 연결 속도가 훨씬 더 느립니다.
완전한 로드라는 인상을 남기기 위해 5초 이내에 모든 항목을 로드할 필요는 없습니다. 이미지 지연 로드, 코드 분할 자바스크립트 번들, web.dev에서 제안된 최적화를 고려해 보세요.
RAIL 측정 도구
RAIL 측정을 자동화하는 데 도움이 되는 몇 가지 도구가 있습니다. 필요한 정보의 유형과 선호하는 워크플로 유형에 따라 사용할 방법이 다릅니다.
Chrome DevTools
Chrome DevTools는 페이지가 로드되거나 실행되는 동안 발생하는 모든 사항에 관한 심층 분석을 제공합니다. 성능 패널 UI에 익숙해지려면 런타임 성능 분석 시작하기를 참고하세요.
특히 다음과 같은 DevTools 기능이 유용합니다.
CPU를 제한하여 성능이 낮은 기기를 시뮬레이션합니다.
네트워크를 제한하여 느린 연결을 시뮬레이션합니다.
기본 스레드 활동 보기를 사용하여 기록 중에 기본 스레드에서 발생한 모든 이벤트를 볼 수 있습니다.
테이블에서 기본 스레드 활동을 확인하여 가장 많은 시간이 소요된 활동을 기준으로 활동을 정렬합니다.
초당 프레임 수(FPS)를 분석하여 애니메이션이 실제로 원활하게 실행되는지 측정합니다.
Performance Monitor를 사용하여 실시간으로 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 미만에 로드합니다.