모듈 작업자로 웹 스레딩

이제 웹 작업자의 JavaScript 모듈을 사용하면 무거운 작업을 백그라운드 스레드로 더 쉽게 옮길 수 있습니다.

Jason Miller

JavaScript는 단일 스레드이므로 한 번에 하나의 작업만 실행할 수 있습니다. 이는 직관적이며 웹의 많은 사례에서 잘 작동하지만 데이터 처리, 파싱, 연산, 분석과 같은 무거운 작업을 수행해야 할 때는 문제가 될 수 있습니다. 점점 더 복잡한 애플리케이션이 웹에서 제공됨에 따라 멀티 스레드 처리에 대한 필요성이 증가하고 있습니다.

웹 플랫폼에서 스레딩 및 동시 로드의 기본 요소는 Web Workers API입니다. 작업자는 스레드 간 통신을 위한 메시지 전달 API를 노출하는 운영체제 스레드 위에 있는 가벼운 추상화입니다. 이는 비용이 많이 드는 계산을 수행하거나 대규모 데이터 세트를 처리할 때 매우 유용할 수 있으며, 하나 이상의 백그라운드 스레드에서 비용이 많이 드는 작업을 수행하는 동안 기본 스레드가 원활하게 실행될 수 있습니다.

다음은 작업자 사용의 일반적인 예입니다. 작업자 스크립트는 기본 스레드의 메시지를 수신 대기하고 자체 메시지를 다시 전송하여 응답합니다.

page.js:

const worker = new Worker('worker.js');
worker.addEventListener('message', e => {
  console.log(e.data);
});
worker.postMessage('hello');

worker.js:

addEventListener('message', e => {
  if (e.data === 'hello') {
    postMessage('world');
  }
});

Web Worker API는 10년 넘게 대부분의 브라우저에서 사용할 수 있었습니다. 이는 작업자가 우수한 브라우저 지원을 받고 최적화가 잘 되어 있다는 의미이지만, JavaScript 모듈보다 훨씬 이전에 만들어졌다는 의미이기도 합니다. 작업자가 설계되었을 때는 모듈 시스템이 없었기 때문에 작업자에 코드를 로드하고 스크립트를 구성하는 API는 2009년에 일반적이었던 동기식 스크립트 로드 방식과 유사하게 유지되었습니다.

기록: 클래식 작업자

Worker 생성자는 문서 URL을 기준으로 하는 기존 스크립트 URL을 사용합니다. 새 작업자 인스턴스에 대한 참조를 즉시 반환하며, 이 참조는 메시징 인터페이스와 작업자를 즉시 중지하고 삭제하는 terminate() 메서드를 노출합니다.

const worker = new Worker('worker.js');

웹 작업자 내에서 importScripts() 함수를 사용하여 추가 코드를 로드할 수 있지만, 각 스크립트를 가져오고 평가하기 위해 작업자 실행을 일시중지합니다. 또한 기존 <script> 태그와 같이 전역 범위에서 스크립트를 실행합니다. 즉, 한 스크립트의 변수를 다른 스크립트의 변수로 덮어쓸 수 있습니다.

worker.js:

importScripts('greet.js');
// ^ could block for seconds
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

// global to the whole worker
function sayHello() {
  return 'world';
}

이러한 이유로 웹 작업자는 역사적으로 애플리케이션 아키텍처에 큰 영향을 미쳤습니다. 개발자는 최신 개발 관행을 포기하지 않고도 웹 작업자를 사용할 수 있도록 영리한 도구와 해결 방법을 만들어야 했습니다. 예를 들어 webpack과 같은 번들러는 코드 로드에 importScripts()를 사용하는 생성된 코드에 작은 모듈 로더 구현을 삽입하지만, 변수 충돌을 방지하고 종속 항목 가져오기 및 내보내기를 시뮬레이션하기 위해 함수에 모듈을 래핑합니다.

모듈 작업자 입력

JavaScript 모듈의 인체공학적 이점과 성능 이점을 갖춘 웹 작업자를 위한 새로운 모드가 Chrome 80에서 제공되며, 이를 모듈 작업자라고 합니다. 이제 Worker 생성자가 새로운 {type:"module"} 옵션을 허용하여 <script type="module">와 일치하도록 스크립트 로드 및 실행을 변경합니다.

const worker = new Worker('worker.js', {
  type: 'module'
});

모듈 작업자는 표준 JavaScript 모듈이므로 import 및 export 문을 사용할 수 있습니다. 모든 JavaScript 모듈과 마찬가지로 종속 항목은 특정 컨텍스트 (기본 스레드, 작업자 등)에서 한 번만 실행되며, 이후의 모든 가져오기는 이미 실행된 모듈 인스턴스를 참조합니다. JavaScript 모듈의 로드 및 실행도 브라우저에 의해 최적화됩니다. 모듈의 종속 항목은 모듈이 실행되기 전에 로드될 수 있으므로 전체 모듈 트리를 동시에 로드할 수 있습니다. 모듈 로드는 파싱된 코드도 캐시하므로 기본 스레드와 작업자에서 사용되는 모듈은 한 번만 파싱하면 됩니다.

JavaScript 모듈로 전환하면 동적 가져오기를 사용하여 작업자 실행을 차단하지 않고 코드를 지연 로드할 수도 있습니다. 동적 가져오기는 전역 변수에 의존하는 대신 가져온 모듈의 내보내기가 반환되므로 importScripts()를 사용하여 종속 항목을 로드하는 것보다 훨씬 명시적입니다.

worker.js:

import { sayHello } from './greet.js';
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

import greetings from './data.js';
export function sayHello() {
  return greetings.hello;
}

우수한 성능을 보장하기 위해 모듈 작업자 내에서는 이전 importScripts() 메서드를 사용할 수 없습니다. JavaScript 모듈을 사용하도록 작업자를 전환하면 모든 코드가 엄격 모드로 로드됩니다. 또 다른 주목할 만한 변경사항은 JavaScript 모듈의 최상위 범위에서 this 값이 undefined인 반면, 기존 작업자에서는 값이 작업자의 전역 범위라는 점입니다. 다행히도 전역 범위에 대한 참조를 제공하는 self 전역이 항상 존재해 왔습니다. 서비스 워커를 비롯한 모든 유형의 워커와 DOM에서 사용할 수 있습니다.

modulepreload로 작업자 미리 로드

모듈 작업자에 따른 한 가지 상당한 성능 개선사항은 작업자와 그 종속 항목을 미리 로드하는 기능입니다. 모듈 작업자를 사용하면 스크립트가 표준 JavaScript 모듈로 로드되고 실행됩니다. 즉, modulepreload를 사용하여 미리 로드하고 미리 파싱할 수도 있습니다.

<!-- preloads worker.js and its dependencies: -->
<link rel="modulepreload" href="worker.js">

<script>
  addEventListener('load', () => {
    // our worker code is likely already parsed and ready to execute!
    const worker = new Worker('worker.js', { type: 'module' });
  });
</script>

미리 로드된 모듈은 기본 스레드와 모듈 작업자 모두에서 사용할 수 있습니다. 이는 두 컨텍스트에서 모두 가져오는 모듈이나 모듈이 기본 스레드에서 사용될지 아니면 작업자에서 사용될지 미리 알 수 없는 경우에 유용합니다.

이전에는 웹 작업자 스크립트를 미리 로드하는 데 사용할 수 있는 옵션이 제한적이었고 반드시 안정적이지는 않았습니다. 기존 작업자에는 미리 로드를 위한 자체 '작업자' 리소스 유형이 있었지만 <link rel="preload" as="worker">를 구현한 브라우저는 없었습니다. 따라서 웹 작업자를 미리 로드하는 데 사용할 수 있는 기본 기법은 <link rel="prefetch">를 사용하는 것이었으며, 이는 전적으로 HTTP 캐시에 의존했습니다. 올바른 캐싱 헤더와 함께 사용하면 작업자 스크립트가 다운로드될 때까지 작업자 인스턴스화가 기다리지 않아도 됩니다. 하지만 modulepreload와 달리 이 기법은 종속 항목 미리 로드 또는 사전 파싱을 지원하지 않았습니다.

공유 작업자는 어떤가요?

공유 작업자는 Chrome 83부터 JavaScript 모듈을 지원하도록 업데이트되었습니다. 전용 작업자와 마찬가지로 이제 {type:"module"} 옵션을 사용하여 공유 작업자를 구성하면 작업자 스크립트가 클래식 스크립트가 아닌 모듈로 로드됩니다.

const worker = new SharedWorker('/worker.js', {
  type: 'module'
});

JavaScript 모듈을 지원하기 전에는 SharedWorker() 생성자에 URL과 선택적 name 인수만 필요했습니다. 이는 기존 공유 작업자 사용에 계속 작동하지만 모듈 공유 작업자를 만들려면 새 options 인수를 사용해야 합니다. 사용 가능한 옵션은 이전 name 인수를 대체하는 name 옵션을 포함하여 전용 작업자의 옵션과 동일합니다.

서비스 워커는 어떤가요?

서비스 워커 사양은 모듈 워커와 동일한 {type:"module"} 옵션을 사용하여 JavaScript 모듈을 진입점으로 허용하도록 이미 업데이트되었지만 이 변경사항은 아직 브라우저에 구현되지 않았습니다. 이 경우 다음 코드를 사용하여 JavaScript 모듈을 통해 서비스 워커를 인스턴스화할 수 있습니다.

navigator.serviceWorker.register('/sw.js', {
  type: 'module'
});

사양이 업데이트되었으므로 브라우저에서 새로운 동작을 구현하기 시작했습니다. JavaScript 모듈을 서비스 워커로 가져오는 것과 관련된 몇 가지 추가적인 복잡성이 있기 때문에 시간이 걸립니다. 서비스 워커 등록은 업데이트 트리거 여부를 결정할 때 가져온 스크립트를 이전 캐시 버전과 비교해야 하며, 이는 서비스 워커에 사용되는 JavaScript 모듈에 구현되어야 합니다. 또한 서비스 워커는 업데이트를 확인할 때 특정 경우에 스크립트의 캐시를 우회할 수 있어야 합니다.

추가 리소스 및 심화 학습