모듈 작업자로 웹 스레딩

이제 웹 워커의 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년에 흔했던 동기 스크립트 로드 방식과 유사하게 유지되었습니다.

기록: 기존 작업자

작업자 생성자는 문서 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 모듈이므로 가져오기 및 내보내기 문을 사용할 수 있습니다. 모든 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">를 구현하지 않았습니다. 따라서 웹 워커를 미리 로드하는 데 사용할 수 있는 기본 기술은 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 옵션이 포함됩니다.

서비스 워커는 어떤가요?

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

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

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

추가 리소스 및 추가 읽기