모듈 작업자로 웹 스레딩

이제 웹 워커의 JavaScript 모듈을 사용하여 작업 부담을 백그라운드 스레드로 더 쉽게 옮길 수 있습니다.

제이슨 밀러

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 모듈이 오래 전부터 존재한다는 의미이기도 합니다. worker를 설계할 때는 모듈 시스템이 없었기 때문에 코드를 worker에 로드하고 스크립트를 작성하는 API는 2009년에 일반적으로 사용된 동기식 스크립트 로드 방식과 유사하게 유지되었습니다.

기록: 기존 작업자

작업자 생성자는 문서 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()를 사용하는 생성된 코드에 삽입하지만 모듈을 함수로 래핑하여 변수 충돌을 방지하고 종속 항목 가져오기 및 내보내기를 시뮬레이션합니다.

모듈 작업자 입력

인체공학과 성능상 이점을 제공하는 자바스크립트 모듈을 갖춘 웹 작업자를 위한 새로운 모드가 Chrome 80에 출시됩니다. 이제 Worker 생성자가 새 {type:"module"} 옵션을 허용합니다. 이 옵션은 스크립트 로드 및 실행을 <script type="module">와 일치하도록 변경합니다.

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

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

또한 자바스크립트 모듈로 이동하면 작업자 실행을 차단하지 않고도 지연 로드 코드에 동적 가져오기를 사용할 수 있습니다. 동적 가져오기는 전역 변수를 사용하는 대신 가져온 모듈의 내보내기가 반환되므로 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 모듈을 사용하도록 작업자를 전환하면 모든 코드가 엄격 모드로 로드됩니다. 또 다른 주목할 만한 변경사항은 자바스크립트 모듈의 최상위 범위에 있는 this 값이 undefined인 반면 기존 작업자에서는 값이 작업자의 전역 범위라는 점입니다. 다행히 전역 범위에 대한 참조를 제공하는 self 전역이 항상 있습니다. 서비스 워커와 DOM을 포함한 모든 유형의 worker에서 사용할 수 있습니다.

modulepreload로 작업자 미리 로드

모듈 작업자를 통해 얻을 수 있는 상당한 성능 개선은 작업자와 종속 항목을 미리 로드할 수 있는 기능입니다. 모듈 워커를 사용하면 스크립트가 표준 자바스크립트 모듈로 로드 및 실행되므로 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부터 자바스크립트 모듈 지원으로 공유 작업자가 업데이트되었습니다. 전용 작업자와 마찬가지로 {type:"module"} 옵션으로 공유 작업자를 구성하면 이제 작업자 스크립트를 기본 스크립트가 아닌 모듈로 로드합니다.

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

자바스크립트 모듈을 지원하기 전에는 SharedWorker() 생성자가 URL과 선택적 name 인수만 예상했습니다. 이렇게 해도 기본 공유 작업자에서는 계속 작동하지만 모듈 공유 작업자를 만들려면 새 options 인수를 사용해야 합니다. 사용 가능한 옵션은 이전 name 인수를 대체하는 name 옵션을 포함하여 전용 작업자의 옵션과 동일합니다.

서비스 워커는 어떨까요?

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

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

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

추가 리소스 및 추가 자료