장기 작업 최적화

'기본 스레드를 차단하지 마세요', '긴 작업을 분할하세요'라는 말을 들어봤지만, 이러한 작업을 실행하는 것이 무슨 의미일까요?

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

JavaScript 앱을 빠르게 유지하기 위한 일반적인 조언은 다음과 같습니다.

  • '기본 스레드를 차단하지 마세요.'
  • '긴 작업을 나눠서 처리하세요.'

좋은 조언이지만 어떤 작업이 필요한가요? JavaScript를 더 적게 제공하는 것이 좋지만, 그렇다고 해서 더 반응이 빠른 사용자 인터페이스가 자동으로 제공되는 것은 아닙니다. 그럴 수도 있고, 아닐 수도 있습니다.

JavaScript에서 태스크를 최적화하는 방법을 이해하려면 먼저 태스크가 무엇인지, 브라우저에서 태스크를 어떻게 처리하는지 알아야 합니다.

태스크는 브라우저에서 실행하는 개별 작업입니다. 여기에는 렌더링, HTML 및 CSS 파싱, JavaScript 실행, 직접 제어할 수 없는 기타 유형의 작업이 포함됩니다. 이 중에서 개발자가 작성하는 JavaScript가 가장 많은 작업을 제공합니다.

Chrome DevTools의 성능 프로파일러에 표시된 작업의 시각화입니다. 작업은 스택의 맨 위에 있으며 클릭 이벤트 핸들러, 함수 호출, 그 아래에 있는 다른 항목이 있습니다. 이 작업에는 오른쪽의 렌더링 작업도 포함됩니다.
click 이벤트 핸들러에 의해 시작된 태스크로, Chrome DevTools의 성능 프로파일러에 표시됩니다.

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

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

웹 워커 및 유사 API를 제외한 모든 작업은 기본 스레드에서 실행됩니다.

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

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

기본 스레드는 한 번에 하나의 작업만 처리할 수 있습니다. 50밀리초 이상 걸리는 작업은 긴 작업입니다. 50밀리초를 초과하는 태스크의 경우 태스크의 총 시간에서 50밀리초를 뺀 값을 태스크의 차단 기간이라고 합니다.

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

Chrome DevTools의 성능 프로파일러에 있는 긴 작업입니다. 태스크의 차단 부분 (50밀리초 초과)은 빨간색 대각선 줄무늬 패턴으로 표시됩니다.
Chrome의 성능 프로파일러에 표시된 긴 작업입니다. 긴 태스크는 태스크 모서리에 빨간색 삼각형으로 표시되며 태스크의 차단 부분은 대각선 빨간색 줄무늬 패턴으로 채워집니다.

기본 스레드가 너무 오래 차단되지 않도록 하려면 긴 작업을 여러 개의 작은 작업으로 나눌 수 있습니다.

하나의 긴 작업과 더 짧은 작업으로 나눈 동일한 작업을 비교한 예 긴 작업은 하나의 큰 직사각형이지만 청크 작업은 총 너비가 긴 작업과 동일한 작은 상자 5개로 구성됩니다.
긴 단일 작업과 동일한 작업을 5개의 짧은 작업으로 분할한 작업을 시각화한 모습입니다.

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

작업을 분할하면 사용자 상호작용이 용이해지는 방식을 보여주는 그림 상단에서 긴 태스크는 태스크가 완료될 때까지 이벤트 핸들러가 실행되지 않도록 차단합니다. 하단에서 청크 처리된 작업을 사용하면 이벤트 핸들러가 더 빨리 실행될 수 있습니다.
작업이 너무 길고 브라우저가 상호작용에 충분히 빠르게 응답할 수 없는 경우와 더 긴 작업이 더 작은 작업으로 분할된 경우 상호작용에 어떤 일이 일어나는지 시각화합니다.

위 그림 상단에서 사용자 상호작용에 의해 큐에 추가된 이벤트 핸들러는 시작하기 전에 하나의 긴 작업을 기다려야 했습니다. 이로 인해 상호작용이 지연됩니다. 이 시나리오에서는 사용자가 지연을 느낄 수 있습니다. 하단에서는 이벤트 핸들러가 더 일찍 실행될 수 있으며 상호작용이 즉각적으로 느껴졌을 수 있습니다.

이제 태스크를 분할하는 것이 중요한 이유를 알았으므로 JavaScript에서 이를 실행하는 방법을 알아보겠습니다.

작업 관리 전략

소프트웨어 아키텍처에서 일반적으로 권장되는 조언은 작업을 더 작은 함수로 분할하는 것입니다.

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

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

개념적으로 saveSettings()는 잘 설계되었습니다. 이러한 함수 중 하나를 디버그해야 하는 경우 프로젝트 트리를 탐색하여 각 함수가 하는 일을 파악할 수 있습니다. 이렇게 작업을 분할하면 프로젝트를 더 쉽게 탐색하고 유지할 수 있습니다.

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

Chrome의 성능 프로파일러에 표시된 saveSettings 함수 최상위 함수가 다른 5개의 함수를 호출하지만 모든 작업이 하나의 긴 작업에서 이루어지므로 함수 실행의 사용자에게 표시되는 결과는 모두 완료될 때까지 표시되지 않습니다.
5개의 함수를 호출하는 단일 함수 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()

Browser Support

  • Chrome: 129.
  • Edge: 129.
  • Firefox: not supported.
  • Safari: not supported.

Source

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();
}
Chrome의 성능 프로파일러에 표시된 saveSettings 함수가 이제 두 작업으로 분할되었습니다. 첫 번째 작업은 두 함수를 호출한 다음 생성되므로 레이아웃 및 페인트 작업이 실행되고 사용자에게 눈에 보이는 응답을 제공할 수 있습니다. 따라서 클릭 이벤트가 훨씬 빠른 64밀리초 만에 완료됩니다. 두 번째 작업은 마지막 세 함수를 호출합니다.
saveSettings() 함수의 실행이 이제 두 작업으로 분할됩니다. 따라서 작업 간에 레이아웃과 페인트를 실행할 수 있으므로 이제 훨씬 더 짧은 포인터 상호작용으로 측정된 대로 사용자에게 더 빠른 시각적 응답을 제공할 수 있습니다.

하지만 다른 생성 접근 방식에 비해 scheduler.yield()의 진정한 이점은 연속이 우선순위가 지정된다는 것입니다. 즉, 태스크 중간에 생성하면 현재 태스크의 연속이 다른 유사한 태스크가 시작되기 전에 실행됩니다.

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

포기하지 않는 작업, 포기하는 작업, 포기 및 연속을 사용하는 작업을 보여주는 세 가지 다이어그램 양보하지 않으면 긴 작업이 있습니다. 포기하면 더 짧은 작업이 많아지지만 다른 관련 없는 작업으로 인해 중단될 수 있습니다. 포기 및 연속을 사용하면 더 짧은 작업이 더 많지만 실행 순서는 유지됩니다.
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를 실행하고 그렇지 않은 경우에는 계속 진행합니다.

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

// 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밀리초마다 기본 스레드에만 양보합니다.

Chrome DevTools 성능 패널에 표시되는 일련의 작업 함수로, 실행이 여러 작업으로 분할됩니다.
작업이 여러 태스크로 일괄 처리됩니다.

isInputPending() 사용 안 함

Browser Support

  • Chrome: 87.
  • Edge: 87.
  • Firefox: not supported.
  • Safari: not supported.

Source

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 문서를 참고하세요.

이러한 도구 중 하나 이상을 사용하면 사용자의 요구사항에 우선순위를 두면서도 덜 중요한 작업도 계속 실행되도록 애플리케이션의 작업을 구성할 수 있습니다. 이렇게 하면 반응성이 높고 사용하기 더 즐거운 더 나은 사용자 환경을 만들 수 있습니다.

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

썸네일 이미지는 Amirali Mirhashemian님이 제공해 주신 Unsplash의 이미지입니다.