장기 작업 최적화

'기본 스레드를 차단하지 마세요'와 '장기 작업을 중단하세요'라는 말을 들었지만 이러한 작업을 실행한다는 것이 무슨 뜻일까요?

JavaScript 앱을 빠르게 유지하기 위한 일반적인 조언은 다음과 같은 팁으로 요약되는 경향이 있습니다.

• "기본 스레드를 차단하지 않습니다."
• "장기 작업을 분할하세요."

이것은 훌륭한 조언이지만, 어떤 작업이 관련되어 있을까요? JavaScript를 적게 제공하는 것도 좋지만 응답 속도가 더 높은 사용자 인터페이스를 자동으로 제공하나요? 그럴 수도 있지만 아닐 수도 있습니다.

JavaScript에서 작업을 최적화하는 방법을 이해하려면 먼저 작업이 무엇인지, 브라우저가 작업을 처리하는 방식을 알아야 합니다.

할 일이란 무엇인가요?

작업은 브라우저가 실행하는 모든 개별 작업입니다. 이러한 작업에는 렌더링, HTML 및 CSS 파싱, JavaScript 실행 및 사용자가 직접 제어할 수 없는 기타 유형의 작업이 포함됩니다. 이 모든 작업 중에서 작성하는 JavaScript가 아마도 가장 큰 작업 소스일 것입니다.

JavaScript와 관련된 작업은 다음과 같은 두 가지 방식으로 성능에 영향을 미칩니다.

• 브라우저가 시작 중에 JavaScript 파일을 다운로드하면 나중에 실행될 수 있도록 해당 JavaScript를 파싱하고 컴파일하는 작업을 대기열에 넣습니다.
• 페이지 수명 중 다른 시간에는 이벤트 핸들러, JavaScript 기반 애니메이션 및 분석 수집과 같은 백그라운드 활동을 통해 상호작용을 유도하는 등 JavaScript가 작동할 때 작업이 대기열에 추가됩니다.

웹 작업자 및 이와 유사한 API를 제외하고 이 모든 작업은 기본 스레드에서 발생합니다.

기본 스레드란 무엇인가요?

기본 스레드는 대부분의 작업이 브라우저에서 실행되며 작성하는 거의 모든 JavaScript가 실행되는 곳입니다.

기본 스레드는 한 번에 하나의 작업만 처리할 수 있습니다. 50밀리초보다 오래 걸리는 모든 작업을 장기 작업이라고 합니다. 50밀리초를 초과하는 작업의 경우 작업의 총 시간에서 50밀리초를 뺀 시간을 작업의 차단 기간이라고 합니다.

브라우저는 길이와 관계없이 작업이 실행되는 동안 상호작용이 발생하는 것을 차단하지만, 작업이 너무 오래 실행되지 않는 한 사용자가 이를 인지할 수 없습니다. 하지만 긴 작업이 많을 때 사용자가 페이지와 상호작용하려고 하면 사용자 인터페이스가 응답하지 않는 것처럼 느껴지며, 기본 스레드가 매우 오랫동안 차단되어 있는 경우 심지어 손상될 수도 있습니다.

기본 스레드가 너무 오랫동안 차단되지 않도록 하려면 긴 작업을 여러 개의 작은 작업으로 나누면 됩니다.

이것이 중요한 이유는 작업이 분리될 때 브라우저가 사용자 상호작용을 포함하여 우선순위가 더 높은 작업에 훨씬 더 빨리 응답할 수 있기 때문입니다. 그런 다음 나머지 태스크가 완료될 때까지 실행되므로 처음에 큐에 넣은 작업이 완료됩니다.

위 그림의 맨 위에서 사용자 상호작용으로 큐에 추가된 이벤트 핸들러는 하나의 긴 작업을 기다려야 시작할 수 있습니다. 이 경우 상호작용이 발생하는 것이 지연됩니다. 이 시나리오에서는 사용자가 지연이 발생했을 수 있습니다. 하단에서 이벤트 핸들러가 더 빨리 실행되기 시작할 수 있으며 상호작용이 즉각적으로 느껴졌을 수 있습니다.

이제 작업을 분할하는 것이 중요한 이유를 알았으니 JavaScript에서 이를 수행하는 방법을 알아보겠습니다.

작업 관리 전략

소프트웨어 아키텍처에서 일반적인 조언은 작업을 더 작은 기능으로 나누는 것입니다.

function saveSettings () {
  validateForm();
  showSpinner();
  saveToDatabase();
  updateUI();
  sendAnalytics();
}

이 예에는 5개의 함수를 호출하여 양식을 검증하고, 스피너를 표시하고, 애플리케이션 백엔드로 데이터를 전송하고, 사용자 인터페이스를 업데이트하고, 분석을 전송하는 saveSettings()이라는 함수가 있습니다.

개념적으로 saveSettings()는 잘 설계된 것입니다. 이러한 함수 중 하나를 디버그해야 하는 경우 프로젝트 트리를 순회하여 각 함수가 수행하는 작업을 파악할 수 있습니다. 이처럼 작업을 분할하면 프로젝트를 쉽게 탐색하고 유지관리할 수 있습니다.

하지만 여기서 잠재적인 문제는 JavaScript가 이러한 각 함수를 별도의 작업으로 실행하지 않는다는 것입니다. 이러한 함수가 saveSettings() 함수 내에서 실행되기 때문입니다. 즉, 5개 함수가 모두 하나의 태스크로 실행됩니다.

최상의 시나리오에서는 이러한 함수 중 하나만이 작업의 전체 길이에 50밀리초 이상을 기여할 수 있습니다. 최악의 경우, 특히 리소스가 제한된 기기에서 이러한 작업의 대부분이 훨씬 더 오래 실행될 수 있습니다.

수동으로 코드 실행 연기

개발자가 작업을 더 작은 작업으로 나누는 데 사용한 한 가지 메서드는 setTimeout()와 관련이 있습니다. 이 기법을 사용하여 함수를 setTimeout()에 전달합니다. 이렇게 하면 0의 제한 시간을 지정하더라도 콜백 실행이 별도의 작업으로 연기됩니다.

function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Defer work that isn't user-visible to a separate task:
  setTimeout(() => {
    saveToDatabase();
    sendAnalytics();
  }, 0);
}

이를 수익 창출이라고 하며 순차적으로 실행해야 하는 일련의 함수에 가장 적합합니다.

그러나 코드가 항상 이러한 방식으로 구성되는 것은 아닙니다. 예를 들어 대량의 데이터를 루프로 처리해야 하는 경우 반복이 많으면 이 작업에 시간이 매우 오래 걸릴 수 있습니다.

function processData () {
  for (const item of largeDataArray) {
    // Process the individual item here.
  }
}

여기서 setTimeout()를 사용하는 것은 개발자의 에르고노믹스로 인해 문제가 될 수 있으며, 각각의 반복이 빠르게 실행되더라도 전체 데이터 배열을 처리하는 데 매우 오랜 시간이 걸릴 수 있습니다. 모두 합쳐지면 setTimeout()는 작업에 적합한 도구가 아닙니다. 적어도 이런 식으로 사용할 때는 아닙니다.

async/await를 사용하여 양보 지점 생성

사용자에게 표시되는 중요한 작업이 우선순위가 낮은 작업보다 먼저 발생하도록 하려면 작업 대기열을 잠시 중단하여 브라우저가 더 중요한 작업을 실행할 수 있도록 하여 기본 스레드를 양보하면 됩니다.

앞서 설명한 것처럼 setTimeout를 사용하여 기본 스레드에 양보할 수 있습니다. 그러나 편의성과 가독성을 위해 Promise 내에서 setTimeout를 호출하고 resolve 메서드를 콜백으로 전달할 수 있습니다.

function yieldToMain () {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

yieldToMain() 함수의 이점은 모든 async 함수에서 await할 수 있다는 것입니다. 이전 예를 기반으로 실행할 함수 배열을 만들고 각 함수가 실행된 후 기본 스레드에 양보할 수 있습니다.

async function saveSettings () {
  // Create an array of functions to run:
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ]

  // Loop over the tasks:
  while (tasks.length > 0) {
    // Shift the first task off the tasks array:
    const task = tasks.shift();

    // Run the task:
    task();

    // Yield to the main thread:
    await yieldToMain();
  }
}

그 결과, 한때 모놀리식 작업이 이제는 개별 작업으로 나뉩니다.

전용 스케줄러 API

setTimeout는 작업을 분할하는 효과적인 방법이지만 단점이 있습니다. 후속 작업에서 실행되도록 코드를 지연하여 기본 스레드에 항복하면 해당 작업이 큐의 끝에 추가됩니다.

페이지의 모든 코드를 제어하는 경우 작업의 우선순위를 지정하는 기능이 있는 자체 스케줄러를 만들 수 있습니다. 하지만 타사 스크립트는 스케줄러를 사용하지 않습니다. 사실상 이러한 환경에서는 작업의 우선순위를 지정할 수 없습니다. 청크로만 묶거나 사용자 상호작용에 명시적으로 항복할 수 있습니다.

스케줄러 API는 postTask() 함수를 제공하여 보다 세분화된 작업 예약을 지원하며 브라우저가 작업의 우선순위를 지정하여 우선순위가 낮은 작업이 기본 스레드에 전달되도록 합니다. postTask()는 프로미스를 사용하고 세 가지 priority 설정 중 하나를 허용합니다.

• 'background': 우선순위가 가장 낮은 작업의 경우
• 'user-visible': 우선순위가 중간인 작업의 경우 priority가 설정되지 않은 경우 기본값입니다.
• 'user-blocking': 높은 우선순위로 실행해야 하는 중요한 작업에 적합합니다.

다음 코드를 예로 들어 보겠습니다. 여기서 postTask() API는 가능한 가장 높은 우선순위로 작업 3개를 실행하고 나머지 두 작업은 가능한 가장 낮은 우선순위로 실행하는 데 사용됩니다.

function saveSettings () {
  // Validate the form at high priority
  scheduler.postTask(validateForm, {priority: 'user-blocking'});

  // Show the spinner at high priority:
  scheduler.postTask(showSpinner, {priority: 'user-blocking'});

  // Update the database in the background:
  scheduler.postTask(saveToDatabase, {priority: 'background'});

  // Update the user interface at high priority:
  scheduler.postTask(updateUI, {priority: 'user-blocking'});

  // Send analytics data in the background:
  scheduler.postTask(sendAnalytics, {priority: 'background'});
};

여기서 작업 우선순위는 사용자 상호작용과 같이 브라우저가 우선시하는 작업이 필요에 따라 그 중간에서 작동할 수 있도록 예약됩니다.

다음은 postTask()를 사용하는 방법을 보여주는 간단한 예입니다. 필요에 따라 여러 TaskController 인스턴스의 우선순위를 변경하는 기능을 포함하여 작업 간에 우선순위를 공유할 수 있는 여러 TaskController 객체를 인스턴스화할 수 있습니다.

곧 출시될 scheduler.yield() API를 사용한 연속 내장 수익

스케줄러 API에 제안된 추가 기능 중 하나는 브라우저의 기본 스레드에 양보하도록 특별히 설계된 scheduler.yield()입니다. 이는 이 가이드의 앞부분에서 설명한 yieldToMain() 함수와 유사하게 사용합니다.

async function saveSettings () {
  // Create an array of functions to run:
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ]

  // Loop over the tasks:
  while (tasks.length > 0) {
    // Shift the first task off the tasks array:
    const task = tasks.shift();

    // Run the task:
    task();

    // Yield to the main thread with the scheduler
    // API's own yielding mechanism:
    await scheduler.yield();
  }
}

이 코드는 대체로 익숙하지만 yieldToMain() 대신 await scheduler.yield()를 사용합니다.

scheduler.yield()의 이점은 연속성입니다. 즉, 일련의 작업 중간에 양보하면 다른 예약된 작업이 양보 지점 이후에 동일한 순서로 계속됩니다. 이렇게 하면 서드 파티 스크립트의 코드로 인해 코드 실행 순서가 중단되지 않습니다.

또한 priority: 'user-blocking'와 함께 scheduler.postTask()를 사용하면 user-blocking 우선순위가 높아 계속 진행될 가능성이 높아지므로 그동안 이 접근 방식을 대안으로 사용할 수 있습니다.

setTimeout() (또는 priority: 'user-visibile'가 있거나 명시적 priority가 없는 scheduler.postTask())을 사용하면 큐의 뒤에서 작업이 예약되므로 다른 대기 중인 작업이 계속되기 전에 실행될 수 있습니다.

isInputPending() 사용 안 함

isInputPending() API는 사용자가 페이지와 상호작용하려고 했는지 확인하고 입력이 대기 중인 경우에만 수익을 창출하는 방법을 제공합니다.

이렇게 하면 대기 중인 입력이 없을 때 JavaScript가 작업 대기열의 맨 뒤에 항복하여 끝나지 않고 계속 실행될 수 있습니다. 이렇게 하면 배송 의도에 설명된 것처럼 기본 스레드로 돌아오지 않을 수도 있는 사이트의 성능이 크게 향상될 수 있습니다.

하지만 이 API를 출시한 이후 수익률에 대한 이해가 늘어났고 특히 INP가 도입되었습니다. Google에서는 더 이상 이 API를 사용하지 않는 것이 좋으며, 대신 다음과 같은 여러 가지 이유로 입력 대기 중인지와 관계없이 수익을 창출하는 것이 좋습니다.

• 일부 상황에서 사용자가 상호작용했음에도 isInputPending()에서 false를 잘못 반환할 수 있습니다.
• 입력만으로 작업이 산출되는 것은 아닙니다. 애니메이션 및 기타 정기적인 사용자 인터페이스 업데이트는 반응형 웹페이지를 제공하는 데 똑같이 중요할 수 있습니다.
• 이후 scheduler.postTask() 및 scheduler.yield()와 같은 생성 문제를 해결하는 더 포괄적인 수익 API가 도입되었습니다.

결론

작업을 관리하는 것은 어렵지만 그렇게 하면 페이지에서 사용자 상호작용에 더 빠르게 반응할 수 있습니다. 작업 관리 및 우선순위 지정에 대한 한 가지 조언이 아닌 여러 가지 기법이 필요합니다. 재차 강조하지만, 작업을 관리할 때 고려해야 할 주요 사항은 다음과 같습니다.

• 사용자에게 표시되는 중요한 작업을 위해 기본 스레드에 양보합니다.
• postTask()로 작업의 우선순위를 지정하세요.
• scheduler.yield()(으)로 실험해 보세요.
• 마지막으로, 함수에서 가능한 한 적은 작업을 실행합니다.

이러한 도구를 하나 이상 사용하면 애플리케이션에서 사용자의 니즈에 우선순위를 두도록 작업을 구조화하는 동시에 덜 중요한 작업은 수행할 수 있도록 할 수 있어야 합니다. 그러면 반응 속도가 빠르고 사용하기 즐거운 사용자 환경이 개선됩니다.

이 가이드에 대해 기술적으로 조사해 주신 필립 월튼님께 감사의 인사를 전합니다.

썸네일 이미지 출처: Unsplash, Amirali Mirhashemian 제공