자바스크립트 실행 최적화

JavaScript는 종종 시각적 변화를 유발합니다. 어떤 경우에는 스타일 조작을 통해 직접 구현되거나, 어떤 경우에는 데이터 검색 또는 정렬과 같은 시각적 변화를 일으키는 계산을 통해 구현됩니다. 타이밍이 나쁘거나 실행 시간이 긴 JavaScript는 성능 문제의 일반적인 원인입니다. 따라서 가능한 한 이러한 영향을 최소화할 수 있는 방법을 찾아야 합니다.

JavaScript는 종종 시각적 변화를 유발합니다. 때로는 스타일 조작을 통해서, 때로는 계산을 통해 데이터 검색 또는 정렬과 같은 시각적 변화를 초래합니다. 타이밍이 좋지 않음 장기 실행 자바스크립트가 성능 문제의 일반적인 원인입니다. 따라서 가능한 한 이러한 영향을 최소화할 수 있는 방법을 찾아야 합니다.

작성하는 JavaScript는 실제로 실행되는 코드와 같은 것은 아닙니다. 최신 브라우저는 JIT 컴파일러를 사용하여 최대한 빠른 실행을 제공하기 위한 최적화 방법과 요령이 고스란히 담겨 있습니다. 코드의 역학이 크게 바뀝니다.

그럼에도 불구하고 앱의 실행을 돕기 위해 확실히 할 수 있는 몇 가지 사항이 있습니다. JavaScript에 적합합니다.

요약

• 시각적 업데이트에 setTimeout 또는 setInterval을 피합니다. 대신 항상 requestAnimationFrame을 사용하세요.
• 장기 실행 JavaScript를 기본 스레드가 아닌 Web Workers로 이전합니다.
• 마이크로 작업을 사용하여 여러 프레임에서 DOM을 변경합니다.
• Chrome DevTools의 타임라인 및 자바스크립트 프로파일러를 사용하여 자바스크립트의 영향을 평가합니다.

시각적 변화를 위해 requestAnimationFrame 사용

화면에서 시각적 변화가 일어나고 있을 때는 클릭하기만 하면 됩니다. JavaScript가 requestAnimationFrame를 사용하는 것입니다.

/**
    * 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를 사용하여 애니메이션, 문제는 콜백이 프레임의 특정 지점에서 실행된다는 점입니다. 이런 경우 프레임을 누락하여 버벅거림이 발생하는 경우가 많습니다.

실제로 jQuery는 animate 동작에 setTimeout를 사용했습니다. 를 사용하도록 변경되었습니다. 버전 3의 requestAnimationFrame 이전 버전의 jQuery를 사용하는 경우 requestAnimationFrame를 사용하도록 패치합니다. 이 방법을 사용하는 것이 좋습니다.

복잡성 감소 또는 Web Workers 사용

JavaScript는 브라우저의 기본 스레드에서 스타일 계산, 레이아웃 및 페인트를 사용합니다. JavaScript가 오랫동안 실행되면 이러한 다른 작업을 차단하지만, 프레임 누락이 발생할 수 있습니다.

JavaScript가 실행되는 시점과 실행 시간을 전략적으로 정해야 합니다. 예를 들어 자바스크립트 애니메이션을 3~4ms의 리전으로 실행됩니다 이보다 오래 걸리면 시간이 너무 오래 걸릴 위험이 있습니다. 유휴 상태인 경우 걸리는 시간에 대해 조금 더 편안하게 할 수 있습니다.

많은 경우 순수한 컴퓨팅 작업을 웹 작업자 예를 들어 DOM 액세스가 필요하지 않은 경우입니다. 데이터 조작 또는 순회 정렬이나 검색과 같은 여러 가지 유형이 있으며, 로드 및 모델 생성과 마찬가지로 이 모델에 적합한 경우가 많습니다.

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...
});

모든 작업이 이 모델에 적합한 것은 아닙니다. 웹 작업자는 DOM 액세스 권한이 없습니다. 작업이 기본 스레드에 있어야 하는 경우 큰 작업을 각각 몇 밀리초 이내에 걸리는 마이크로 작업으로 세분화하고 각 프레임에서 requestAnimationFrame 핸들러 내에서 실행하는 일괄 처리 접근 방식을 고려하세요.

이 접근 방식은 UX 및 UI에 영향을 미치므로 사용자가 이를 알고 있는지 확인해야 합니다. 진행률 또는 활동 표시기를 사용하여 작업이 처리 중임을 알립니다. 어떤 경우든 이 접근 방식은 앱의 기본 스레드를 사용 가능한 상태로 유지하여 사용자 상호작용을 고려해야 합니다

JavaScript의 '프레임 비용' 알아보기

프레임워크, 라이브러리 또는 자체 코드를 평가할 때는 JavaScript 코드를 프레임 단위로 실행하는 데 드는 비용을 알 수 있습니다. 이것은 특히 다음과 같이 성능에 중요한 애니메이션 작업을 할 때 중요합니다. 사용할 수 있습니다.

Chrome DevTools의 성능 패널은 JavaScript의 비용입니다. 일반적으로 다음과 같은 하위 수준의 레코드를 가져옵니다.

기본 섹션에는 JavaScript 호출의 Flame Chart가 제공되므로 정확히 어떤 함수가 호출되었고 각각 얼마나 오래 걸렸는지 분석할 수 있습니다.

이 정보를 통해 캠페인의 성능에 미치는 영향을 JavaScript를 실행하고, 문제가 있는 핫스팟을 찾아서 수정하기 함수를 실행하는 데 너무 오래 걸립니다. 앞서 언급했듯이 장기 실행 자바스크립트를 삭제하거나, 삭제할 수 없는 경우 웹 작업자가 연결되고 기본 스레드가 확보되어 다른 작업을 계속할 수 있습니다.

자세한 내용은 런타임 성능 분석 시작하기를 참고하세요. 확인할 수 있습니다

JavaScript 미세 최적화 피하기

브라우저가 한 가지 버전을 다른 버전보다 100배 빠르게 실행할 수 있다는 점은 요소의 offsetTop 요청이 연산보다 빠른 경우 등 getBoundingClientRect(). 그러나 다음과 같은 함수만 호출하는 것이 거의 항상 사실입니다. 이 횟수가 프레임당 적은 횟수이므로 일반적으로 프레임 상의 이 측면에 집중하는 데 JavaScript의 성능 일반적으로 절약되는 시간은 밀리초의 일부에 불과합니다.

게임이나 컴퓨팅 비용이 많이 드는 애플리케이션을 만드는 경우는 예외일 가능성이 높습니다. 일반적으로 많은 계산을 단일 프레임에 맞추고 모든 것이 도움이 됩니다.

간단히 말해서, 마이크로 최적화는 일반적으로 목표에 매핑되지 않기 때문에 매우 주의해야 합니다. 제공할 수 있습니다.