웹 성능 최적화의 척도(RAIL)

(이 글은 아래의 영상 시리즈 속 내용을 바탕으로 제작되었습니다.)

www.youtube.com/watch?v=yJo9lZAEqb0&list=PLAwxTw4SYaPl09X4Rljhy7dZinRCzbHz6

 

출저 : https://miro.medium.com/max/2858/1*-jCHluH_XqUC7DAFa708xw.png

 

RAIL 이란?

웹 성능 최적화의 척도로 60fps 를 유지하는 것이 잘 소개되고는 하지만, 엄밀히 말해서 '매순간' 60fps 를 유지해야 하는 것은 아닙니다. 사실 그것은 불가능에 가깝습니다. 정확히 어느 순간을 최적화 해야 하는지를 판단하기 위한 척도로, 'RAIL' 이라는 개념이 대두됩니다.

 

 

R (Response)

 

Respond 는 이용자의 인터랙션에 얼마나 빨리 반응할 수 있느냐와 관련된 부분입니다. 즉, 이용자가 버튼을 클릭하거나 사이드바 토글을 수행할 때 이용자가 직접적으로 화면상에 그에 따른 시각적 변화를 볼 수 있기까지 걸리는 시간에 관한 부분입니다. 연구에 따르면, 이때 걸리는 시간은 100ms 이하여야 합니다.

 

 

 

A (Animation)

 

애니메이션은 말 그대로 화면상에 나타나게 되는 animation 의 부드러움의 정도와 연관있습니다. 이용자가 '부드럽다'라고 느낄 수 있는 애니메이션이 되려면, 애니메이션 한 프레임당 걸리는 시간은 16ms 이고, 브라우저는 애니메이션 처리 외에도 오버헤드(다른 작업)들을 가지고 있기에, 10ms ~ 12ms 사이에 한 프레임이 처리되도록 만들 필요가 있습니다.

*Response 에는 애니메이션이 따르기 마련이고, 이러한 애니메이션의 대부분에는 60fps 가 보장되어야 합니다.

 

이를 지킬 수 있는 가장 좋은 방법은 transform 과 opacity 속성을 최대한 활용하여 composit 과정만이 일어나도록 만드는 것입니다. 또한 애니메이션을 여러개 쓰는 것이 아니라 기존의 애니메이션을 거꾸로 되돌리는 등 재활용 방안을 찾아보는 것입니다.

 

I : Idle

 

이용자는 로드가 끝나자 마자 바로 인터랙션을 수행하지 않습니다. 아주 조금의 시간이겠지만, 페이지 로드가 끝난 후에 조금 멈칫 하고, 인터랙션을 시작하죠. 보통, 이 시간은 약 50ms 정도입니다. 이 찰나의 순간은 많은 연산이 필요한 작업을 수행할 수 있는 기회이기도 합니다. RAIL 에서는 이 시간을 최대한 활용할 것을 권장합니다.

Load 시점에서 마무리하지 못한 이미지 로드, 비디오 로드, 크게 중요하지 않은 요소 렌더링을 이 시점에 수행할 수 있습니다.

 

 

L : Load

 

이용자가 URL 을 통해 사이트에 접속하고, 이용자가 시각적으로 볼 수 있는 요소들이 화면에 나타나기 전까지의 시간입니다. RAIL 에서는 이 시간을 1초 이하로 만드는 것을 권장합니다.

 

이 Load 시점에 페이지가 동작하는데 필요한 모든 일을 수행하는 것은 현명한 선택이 아닙니다. 이용자가 로드가 완료되었음을 알 수 있도록 텍스트가 보이고 기본적이고 핵심적인 기능들만이 동작할 수 있도록 만들수만 있으면 됩니다. 여유가 된다면 이용자가 들어왔을 때 보이는 상단의 요소들을 보이게 하기 위해 상단 요소들을 모두 다운로드할 수도 있습니다.