RAIL - ChoDragon9/posts GitHub Wiki

https://web.dev/rail/

RAIL은 웹 앱의 주요 작업인 Response, Animation, Idle, Load의 약자다. 사용자의 경험을 주요 작업으로 나누고 각각의 성능 목표를 정의하는 데 도움이 된다. 성능 목표는 사용자가 지연을 인식하는 방식에 대한 컨텍스트 및 UX 연구를 기반으로 정의되었다.

이 기간 내에 응답하면 애니메이션이 부드럽다고 인식한다. 왜냐하면, 사용자는 모션 추적이 능숙하기 때문이다. 브라우저가 새 프레임을 화면에 그리는 데 걸리는 시간을 포함하면, 프레임당 16ms이다.

이 기간 내에 응답하면 즉각적인 반응으로 느낀다. 이 기간을 넘어가면 행동과 응답이 끊어졌다고 느낀다.

이 기간 내에서는 자연스럽고 지속적인 작업 진행의 일부로 느낀다. 대부분 웹 페이지 로드나 페이지 변경 작업을 나타낸다.

1000ms를 넘으면 사용자는 수행 중인 작업에 집중하지 못한다.

10000ms를 넘으면 사용자는 실망하고 작업을 포기할 가능성이 크다. 나중에 다시 방문하지 않을 수 있다.

사용자는 본인의 네트워크 상태와 하드웨어에 따라 성능 지연을 다르게 인식한다. 빠른 네트워크 상태에 빠른 데스크톱 컴퓨터에서는 사이트를 로드하는 것을 1초 이내에 발생하는 것에 익숙하다. 하지만 느린 3G 연결로 모바일 장치에 사이트를 로드하는 것은 더 오래 걸리기 때문에 모바일 사용자는 인내심이 더 많다. 그래서 모바일에서는 5초 이내에 로드하는 것이 더 현실적인 목표다.

사용자 입력이 시작하고 상호작용이 즉각적인 것처럼 느끼도록 하려면 100ms 이내에 반응해야 한다. 버튼 클릭, 애니메이션 시작과 같은 대부분의 입력을 의미하고, 터치 드래그와 스크롤을 해당되지 않는다.

이벤트 처리 시간은 50ms 이내에 처리해야 한다. 만약에 50ms 이상 걸리면 사용자에게 다른 반응을 먼저 제공해야 한다.

[1] Idle Time Garbage Collection Scheduling > 4. Idle Task Scheduling

크롬 브라우저에서는 유휴 시간을 50ms[1]로 제한한다. 사용자가 발생하는 입력은 최대 50ms 동안 대기할 수 있다. 그래서 입력 처리 시간은 최대 50ms 동안 사용할 수 있다고 가정하는 것이다.

Animation은 비주얼 애니메이션, 로딩, 스크롤, 드래그와 같은 것을 의미한다.

각 프레임을 10ms 이하로 생성해야 한다. 왜냐하면, 프레임의 최대 시간은 16ms이지만 브라우저는 렌더링하는 데 약 6ms가 필요하므로 처리시간은 10ms가 된다.

애니메이션이 60fps가 안될 때는 렌더링 성능을 참조해서 해결한다.

유휴 시간에 데이터 로드, 사용자 입력 응답이 발생하는 데, 유휴 시간을 가지지 않으면 이것들을 방해할 수 있다.

첫 번째 로드는 모바일 사용자 장치와 느린 네트워크를 고려해서 5초 이내에 로드 돼야하고, 후속 로드는 2초 이내에 로드하는 것이 좋다. 첫 번째 로드에서 모든 리소스를 로드 할 필요는 없이 지연 로딩 이미지, 코드 번들링을 통해 지연 로드로 후속 로드를 하는 게 좋다.

네트워크 속도 및 대기 시간, 하드웨어(예: 느린 CPU), 캐시, JS 구문 분석 등이 로드에 영향을 미친다.