모듈 작업자로 웹 스레딩

이제 웹 워커의 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 생성자가 <script type="module">와 일치하도록 스크립트 로드 및 실행을 변경하는 새 {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로 worker 미리 로드

모듈 작업자와 함께 제공되는 상당한 성능 개선 사항 중 하나는 작업자와 그 종속 항목을 미리 로드할 수 있는 기능입니다. 모듈 작업자를 사용하면 스크립트가 표준 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">를 구현한 브라우저는 없었습니다. 따라서 웹 작업자를 미리 로드하는 데 사용할 수 있는 기본 기법은 HTTP 캐시에만 전적으로 의존하는 <link rel="prefetch">를 사용하는 것이었습니다. 올바른 캐싱 헤더와 함께 사용하면 작업자 인스턴스화가 작업자 스크립트를 다운로드하기 위해 기다릴 필요가 없게 되었습니다. 그러나 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 모듈에 구현되어야 합니다. 또한 서비스 워커는 업데이트를 확인할 때 경우에 따라 스크립트의 캐시를 우회할 수 있어야 합니다.

추가 리소스 및 추가 읽기