Optimize JavaScript execution

📌본 문서는 Optimize JavaScript execution을 번역한 문서이며 오역, 의역이 존재할 수 있습니다. 이외에 추가적으로 참고한 Reference는 문서 마지막에 기재해 놓았습니다.

서론

자바스크립트는 Style을 직접 조작하거나, 데이터 정렬 혹은 검색등의 작업을 통해서 시각적인 업데이트를 만듭니다. 그리고 이 자바스크립트의 실행 시간이 길거나 혹은 실행되는 타이밍이 안좋은 경우 퍼포먼스 이슈로 이어질 수 있습니다. 우리는 가능한한 이 영향을 최소화해야 합니다.

우리가 작성하는 자바스크립트 코드는 실제 실행되는 코드와는 다르기 때문에, 자바스크립트 성능을 분석한다는 것은 예술에 가까운 행위일 수 있습니다. 모던 브라우저는 JIT 컴파일러뿐만 아니라 여러 최적화와 트릭을 사용하기 때문에, 코드의 동작을 크게 바꿔놓기 때문입니다.

그럼에도 불구하고 자바스크립트가 좀 더 잘 실행될 수 있도록 돕는 몇 가지 분명한 방법이 존재합니다.

1. 시각적인 업데이트는 setTimeout, setInterval 대신 rAF를 이용합니다.
2. 실행 시간이 긴 자바스크립트는 main thread가 아닌 Web Worker에서 실행시킵니다.
3. 여러 프레임에 걸쳐서 DOM 변화가 일어난다면, micro-task를 이용합니다.

🤔 1번하고 같은 이야기같습니다. 아마 rAF의 콜백 함수는 micro-task queue에 enqueue가 되고, 여러 프레임에 걸쳐서 DOM 변화가 일어나는 경우는 animation 상황을 이야기하는 듯 합니다. rAF를 사용하라는 의미겠죠?

4. 자바스크립트 영향 분석을 위해서 Chrome의 DevTool과 Javascript Profiler를 이용합니다.

1. 시각적인 업데이트는 setTimeout, setInterval 대신 rAF를 이용합니다.

rAF는 콜백 함수를 프레임의 시작 지점에서 호출하여 Frame loss를 최소화합니다.

/**
    * If run as a requestAnimationFrame callback, this
    * will be run at the start of the frame.
    */
function updateScreen(time) {
    // Make visual updates here.
}

requestAnimationFrame(updateScreen);

setTimeout이나 setInterval을 사용하여 시각적인 업데이트를 하려하는 경우, 콜백 함수가 프레임 간격의 랜덤한 지점에서 호출되며, 최악의 경우, 다음 프레임이 보여지기 바로 직전에 호출되어 Frame Loss로 이어질 수 있습니다.

jQuery도 한때는 애니메이션을 위해 setTimeout을 사용했으나, version3에 오면서 rAF를 사용하기 시작했습니다. 만약 옛날 버전의 jQuery를 사용한다면, rAF를 사용하는 version3으로의 업데이트를 강력하게 권고드립니다.

🤔 setTimeout이나 setInterval의 콜백 함수가 모니터 주사율보다 더 빠르게 실행이 된다면, 이 역시도 Frame Loss로 이어질 수 있습니다. 가령 16.7ms의 Frame 간격을 갖는 모니터에서, 4.7ms로 setTimeout을 호출하는 경우, 4번이 호출되어도 3번은 Loss로 이어질 수 있습니다.
하지만 rAF의 경우, 호출 시간이 모니터 주사율에 의해 결정되기 때문에 위와 같은 Frame Loss는 걱정하지 않아도 되며, repaint 이전에 호출되는 것을 보장합니다.

2. 실행 시간이 긴 자바스크립트는 main thread가 아닌 Web Worker에서 실행시킵니다.

자바스크립트는 브라우저의 main thread에서 실행되며, 스타일 계산, 레이아웃, 페인트 등이 차례대로 실행됩니다. 만약 자바스크립트 실행 시간이 너무 길다면, 자바스크립트 이후의 작업들이 차례대로 block이 되어 frame loss로 이어질 수 있습니다.

자바스크립트를 언제, 그리고 얼마나 오랫 동안 실행시킬 것인지에 대해서 전략적으로 접근해야 합니다. 스크롤과 같은(?) 애니메이션이 존재한다면, 이상적으로는 자바스크립트의 실행 시간이 3~4ms 이내여야 합니다. 만약 이 시간보다 길어지게 된다면, frame loss로 이어질 수 있습니다. 만약 유휴 시간에 있다면, 조금 더 여유를 가질 수 있습니다.(스크롤 애니메이션에 대한 내용같은데 해석이 안되네요)

데이터 조작 혹은 탐색, 정렬과 같이 DOM에 접근하지 않는 경우라면 Web Worker에게 계산 작업을 맡길 수 있습니다.

var dataSortWorker = new Worker("sort-worker.js");
dataSortWorker.postMesssage(dataToSort);

// The main thread is now free to continue working on other things...

dataSortWorker.addEventListener('message', function(evt) {
    var sortedData = evt.data;
    // Update data on screen...
});

Web Worker는 DOM 접근 권한이 없으므로, DOM에 접근해야하는 작업을 맡기는 것은 유효하지 않습니다. (😥해석이 어렵네요) Where your work must be on the main thread, consider a batching approach, where you segment the larger task into micro-tasks, each taking no longer than a few milliseconds, and run inside of requestAnimationFrame handlers across each frame.

이 방식을 사용하는 경우, 진행률을 유저에게 보여줌으로써 작업이 진행되고 있음을 알려주어야 합니다. 어찌됐건 이 접근 방법은, 앱의 main thread를 좀 더 free하게 만들고, 응답성을 높이는데 도움을 줍니다.

🤔 아마도 renderer process 내부의 여러 스레드 중, 이벤트나 렌더링을 담당하는 main thread가 너무 무거워지는 것을 방지하기 위해, Web Worker를 이용해서 자바스크립트의 복잡한 연산을 다른 thread에서 병렬로 처리한다. 정도로 이해하면 되지 않을까 싶습니다. 관련한 추가 내용은 아래 문서를 참고하시면 될 듯 합니다.

Web Worker
브라우저 프로세스
Minimize main thread work
Main Thread

3. 하나의 프레임을 만드는데 요구되는 자바스크립트 비용을 파악하세요

프레임워크나 라이브러리, 혹은 당신의 코드를 평가할때, 프레임 단위로 Javascript를 실행하는데 드는 비용을 평가하는 것이 중요합니다. 이것은 특히나 성능에 치명적일 수 있는 transition이나 scrolling 애니메이션에서 매우 중요합니다.

Chrome DevTools는 이러한 자바스크립트 비용을 측정하는데 도움을 줍니다.

여기서 Main Section은 자바스크립트 호출에 대한 Flame Chart를 제공하기 때문에, 쉽게 어떤 함수가 호출됐고, 얼마나 오랫동안 실행되는지 알 수 있습니다.

이러한 정보를 토대로 앱에서 자바스크립트가 성능에 얼마나 영향을 끼치는지 확인할 수 있으며, 실행에 많은 시간이 소요되는 함수를 찾아서 수정할 수 있습니다. 앞서 말했듯이, 우리는 실행 시간이 긴 자바스크립트를 제거하거나, 불가능하다면 Web Worker로 이동시켜야 합니다.

4. 자바스크립트를 너무 micro단위까지 최적화하려고 하지마세요

어떤 객체의 offsetTop을 구하는 것이, getBoundingClientRect()를 계산하는 것 보다 100배 가량 빠르다는 것을 알고 있나요? 알고있으면 좋을지도 모르지만, 이러한 함수들은 프레임당 호출되는 횟수가 매우 적고, 이러한 비용을 아껴봤자 고작 ms단위밖에 아끼지 못합니다. 너무 micro하게 최적화하려 하는 것은 비효율적일 수 있습니다.

게임과 같이 연산 비용이 많이 드는 앱을 설계한다면, 프레임 하나당 많은 연산이 들어가기 때문에 이러한 조언이 예외일 수 있습니다

rAF에 대한 추가적인 내용

CPU 자원을 고려합니다(CPU Optimization). 다른 탭에 있는 경우, rAF내의 콜백 함수 호출은 멈추게 됩니다.

setTimeout/setInterval의 특징

• 둘 다 CPU 자원을 고려하지 않습니다. 다른 탭에 있어도, 콜백 함수는 계속해서 실행됩니다.
• setInterval의 경우 콜백 함수의 실행 시간이 딜레이보다 길어지게 되면 너무 많은 콜백 함수가 태스크 큐에서 대기하게 됩니다.

What requestAnimationFrame is ?
Why requestAnimationFrame is better than setTimeout and setInterval in HTML5
Window.requestAnimationFrame