장기 작업 최적화

'기본 스레드를 차단하지 마세요', '긴 작업을 분할하세요'라는 말을 들어보셨을 것입니다. 하지만 이러한 작업을 한다는 것은 무엇을 의미할까요?

Jeremy Wagner

Brendan Kenny

게시일: 2022년 9월 30일, 최종 업데이트: 2024년 12월 19일

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밀리초 이상을 기여할 수 있습니다. 최악의 경우, 특히 리소스가 제한된 기기에서 이러한 작업이 훨씬 더 오래 실행될 수 있습니다.

이 경우 saveSettings()는 사용자 클릭에 의해 트리거되며, 전체 함수 실행이 완료될 때까지 브라우저가 응답을 표시할 수 없으므로 이 긴 작업의 결과로 UI가 느리고 응답하지 않으며, 다음 페인트에 대한 상호작용 (INP)이 저조한 것으로 측정됩니다.

수동으로 코드 실행 연기

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

개발자가 작업을 더 작은 작업으로 나누기 위해 사용하는 한 가지 방법은 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()가 5회 중첩된 후에는 브라우저가 추가 setTimeout()마다 최소 5밀리초의 지연 시간을 적용하기 시작합니다.

setTimeout에는 양보와 관련하여 또 다른 단점이 있습니다. setTimeout를 사용하여 후속 작업에서 실행할 코드를 지연시켜 기본 스레드에 양보하면 해당 작업이 큐의 끝에 추가됩니다. 대기 중인 다른 작업이 있으면 지연된 코드보다 먼저 실행됩니다.

전용 양보 API: scheduler.yield()

scheduler.yield()는 브라우저의 기본 스레드에 양보하도록 특별히 설계된 API입니다.

언어 수준 문법이나 특수 구문이 아닙니다. scheduler.yield()는 향후 작업에서 확인될 Promise를 반환하는 함수일 뿐입니다. Promise가 해결된 후 실행되도록 연결된 모든 코드 (명시적 .then() 체인 또는 비동기 함수에서 await한 후)는 향후 작업에서 실행됩니다.

실제로는 await scheduler.yield()를 삽입하면 함수가 해당 지점에서 실행을 일시중지하고 기본 스레드로 양보합니다. 함수의 연속이라고 하는 함수의 나머지 부분은 새 이벤트 루프 태스크에서 실행되도록 예약됩니다. 해당 작업이 시작되면 대기 중인 프로미스가 처리되고 함수는 중단된 부분부터 계속 실행됩니다.

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

  // Yield to the main thread:
  await scheduler.yield()

  // Work that isn't user-visible, continued in a separate task:
  saveToDatabase();
  sendAnalytics();
}

하지만 다른 양보 접근 방식에 비해 scheduler.yield()의 실질적인 이점은 연속에 우선순위가 지정된다는 점입니다. 즉, 작업 중간에 양보하면 현재 작업의 연속이 다른 유사한 작업이 시작되기 전에 실행됩니다.

이렇게 하면 서드 파티 스크립트의 작업과 같은 다른 작업 소스의 코드가 코드 실행 순서를 방해하지 않습니다.

교차 브라우저 지원

scheduler.yield()는 아직 모든 브라우저에서 지원되지 않으므로 대체가 필요합니다.

한 가지 해결책은 scheduler-polyfill를 빌드에 추가하는 것입니다. 그러면 scheduler.yield()를 직접 사용할 수 있습니다. 폴리필은 다른 작업 예약 함수로 대체하는 작업을 처리하므로 브라우저 전반에서 유사하게 작동합니다.

또는 scheduler.yield()를 사용할 수 없는 경우 Promise로 래핑된 setTimeout만 대체로 사용하여 몇 줄로 더 간단한 버전을 작성할 수 있습니다.

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }

  // Fall back to yielding with setTimeout.
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

scheduler.yield()를 지원하지 않는 브라우저는 우선순위가 지정된 연속을 가져오지 않지만 브라우저가 응답성을 유지하도록 양보합니다.

마지막으로, 연속 작업에 우선순위가 지정되지 않은 경우 코드가 기본 스레드에 양보할 수 없는 경우가 있을 수 있습니다 (예: 양보하면 한동안 작업을 완료하지 못할 위험이 있는 알려진 사용 중인 페이지). 이 경우 scheduler.yield()는 일종의 점진적 개선으로 처리될 수 있습니다. scheduler.yield()를 사용할 수 있는 브라우저에서는 양보하고 그렇지 않으면 계속 진행합니다.

이는 기능을 감지하고 편리한 한 줄로 단일 마이크로태스크를 기다리는 것으로 대체하여 수행할 수 있습니다.

// Yield to the main thread if scheduler.yield() is available.
await globalThis.scheduler?.yield?.();

scheduler.yield()를 사용하여 장기 실행 작업 분할

scheduler.yield()를 사용하는 이러한 메서드를 사용하면 어떤 async 함수에서도 await할 수 있다는 이점이 있습니다.

예를 들어 실행할 작업 배열이 있고 이 작업이 긴 작업으로 이어지는 경우가 많다면 양보를 삽입하여 작업을 분할할 수 있습니다.

async function runJobs(jobQueue) {
  for (const job of jobQueue) {
    // Run the job:
    job();

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

runJobs()의 연속이 우선순위가 높지만, 사용자 입력에 시각적으로 응답하는 것과 같은 우선순위가 더 높은 작업이 실행될 수 있으며, 잠재적으로 긴 작업 목록이 완료될 때까지 기다릴 필요가 없습니다.

하지만 이는 양보를 효율적으로 사용하는 방법이 아닙니다. scheduler.yield()는 빠르고 효율적이지만 약간의 오버헤드가 있습니다. jobQueue의 일부 작업이 매우 짧은 경우 오버헤드가 빠르게 누적되어 실제 작업을 실행하는 것보다 양보하고 재개하는 데 더 많은 시간이 소요될 수 있습니다.

한 가지 방법은 작업을 일괄 처리하는 것으로, 마지막 양보 이후 충분한 시간이 지난 경우에만 작업 간에 양보하는 것입니다. 일반적인 기한은 작업이 긴 작업이 되지 않도록 50밀리초이지만, 응답성과 작업 대기열 완료 시간 간의 절충안으로 조정할 수 있습니다.

async function runJobs(jobQueue, deadline=50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    // Run the job:
    job();

    // If it's been longer than the deadline, yield to the main thread:
    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

그 결과 작업이 분할되어 실행하는 데 너무 오래 걸리지 않지만 실행기는 약 50밀리초마다 기본 스레드에 양보합니다.

isInputPending() 사용 안함

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

이렇게 하면 대기 중인 입력이 없는 경우 JavaScript가 양보하여 태스크 큐의 끝에 도달하는 대신 계속 진행할 수 있습니다. 이렇게 하면 Intent to Ship에 자세히 설명된 대로 기본 스레드로 다시 양보하지 않는 사이트의 성능이 크게 향상될 수 있습니다.

하지만 이 API가 출시된 이후, 특히 INP가 도입되면서 양보에 대한 이해가 높아졌습니다. 이 API를 사용하지 않는 것이 좋습니다. 대신 다음과 같은 여러 가지 이유로 입력 대기 여부와 관계없이 양보하는 것이 좋습니다.

• 사용자가 상호작용한 경우에도 경우에 따라 isInputPending()에서 false를 잘못 반환할 수 있습니다.
• 입력만 작업이 양보해야 하는 유일한 경우는 아닙니다. 애니메이션 및 기타 정기적인 사용자 인터페이스 업데이트는 반응형 웹페이지를 제공하는 데에도 중요할 수 있습니다.
• 이후 scheduler.postTask() 및 scheduler.yield()와 같은 양보 문제를 해결하는 더 포괄적인 양보 API가 도입되었습니다.

결론

작업을 관리하는 것은 어렵지만, 이렇게 하면 페이지가 사용자 상호작용에 더 빠르게 응답할 수 있습니다. 작업을 관리하고 우선순위를 정하는 데는 한 가지 조언만 있는 것이 아니라 다양한 기법이 있습니다. 다시 한번 말씀드리지만, 작업을 관리할 때 고려해야 할 주요 사항은 다음과 같습니다.

• 사용자 대상의 중요한 작업은 기본 스레드에 양보합니다.
• scheduler.yield() (크로스 브라우저 대체 포함)를 사용하여 인체공학적으로 양보하고 우선순위가 지정된 연속을 가져옵니다.
• 마지막으로 함수에서 가능한 한 적은 작업을 수행합니다.

scheduler.yield(), 명시적 작업 예약 관련 scheduler.postTask(), 작업 우선순위 지정에 관한 자세한 내용은 Prioritized Task Scheduling API 문서를 참고하세요.

이러한 도구 중 하나 이상을 사용하면 애플리케이션에서 작업의 구조를 지정하여 사용자의 요구사항을 우선시하면서도 덜 중요한 작업도 완료할 수 있습니다. 이를 통해 반응성이 뛰어나고 사용하기에 더 즐거운 더 나은 사용자 환경을 만들 수 있습니다.

이 가이드의 기술 검토를 도와주신 필립 월튼에게 감사의 말을 전합니다.