작업자 개요

웹 워커와 서비스 워커가 사이트의 성능을 개선하는 방법과 웹 워커와 서비스 워커 중 어느 쪽을 사용해야 하는지 알아봅니다.

Andrew Guan

Demián Renzulli

이 개요에서는 웹 워커와 서비스 워커가 웹사이트의 성능을 개선하는 방법과 웹 워커와 서비스 워커 중 어느 쪽을 사용해야 하는지 설명합니다. 창 및 서비스 워커 통신의 구체적인 패턴은 이 시리즈의 나머지 부분을 확인하세요.

직원이 웹사이트를 개선하는 방법

브라우저는 단일 스레드 (기본 스레드)를 사용하여 웹페이지의 모든 JavaScript를 실행하고 페이지 렌더링 및 가비지 컬렉션 실행과 같은 작업을 실행합니다. 과도한 JavaScript 코드를 실행하면 기본 스레드가 차단되어 브라우저가 이러한 작업을 실행하는 데 지연이 발생하고 사용자 환경이 저하될 수 있습니다.

iOS/Android 애플리케이션 개발에서 앱의 기본 스레드가 사용자 이벤트에 계속 응답할 수 있도록 하는 일반적인 패턴은 작업을 추가 스레드로 오프로드하는 것입니다. 실제로 최신 버전의 Android에서는 기본 스레드를 너무 오래 차단하면 앱이 비정상 종료됩니다.

웹에서 JavaScript는 단일 스레드 개념을 중심으로 설계되었으며 공유 메모리와 같이 앱에 있는 것과 같은 멀티스레딩 모델을 구현하는 데 필요한 기능이 없습니다.

이러한 제한사항에도 불구하고 웹에서 작업자를 사용하여 백그라운드 스레드에서 스크립트를 실행하면 이와 유사한 패턴을 구현할 수 있으므로 기본 스레드를 방해하지 않고 작업을 실행할 수 있습니다. 작업자는 공유 메모리 없이 별도의 스레드에서 실행되는 전체 JavaScript 범위입니다.

이 게시물에서는 두 가지 유형의 작업자 (웹 작업자 및 서비스 작업자)와 그 유사점 및 차이점, 프로덕션 웹사이트에서 이를 사용하는 가장 일반적인 패턴에 대해 알아봅니다.

웹 작업자 및 서비스 워커

유사점

웹사이트에서 사용할 수 있는 두 가지 유형의 작업자는 웹 작업자와 서비스 작업자입니다. 두 플랫폼에는 몇 가지 공통점이 있습니다.

• 둘 다 보조 스레드에서 실행되므로 JavaScript 코드가 기본 스레드와 사용자 인터페이스를 차단하지 않고 실행될 수 있습니다.
• Window 및 Document 객체에 액세스할 수 없으므로 DOM과 직접 상호작용할 수 없으며 브라우저 API에 대한 액세스 권한이 제한됩니다.

차이점

웹 워커에 위임할 수 있는 대부분의 작업은 서비스 워커에서도 실행할 수 있고 그 반대의 경우도 가능하다고 생각할 수 있지만, 두 작업에는 중요한 차이점이 있습니다.

• 웹 워커와 달리 서비스 워커를 사용하면 fetch 이벤트를 통해 네트워크 요청을 가로채고 push 이벤트를 통해 백그라운드에서 푸시 API 이벤트를 수신 대기할 수 있습니다.
• 페이지는 여러 웹 작업자를 생성할 수 있지만 단일 서비스 워커는 등록된 범위 내의 모든 활성 탭을 제어합니다.
• 웹 작업자의 전체 기간은 속한 탭에 밀접하게 결합되지만 서비스 작업자의 수명 주기는 탭과 무관합니다. 따라서 웹 워커가 실행 중인 탭을 닫으면 웹 워커가 종료되지만 서비스 워커는 사이트에 활성 탭이 열려 있지 않더라도 백그라운드에서 계속 실행될 수 있습니다.

사용 사례

두 유형의 작업자 간의 차이는 어떤 상황에서 어떤 작업자를 사용해야 하는지 알려줍니다.

웹 워커의 사용 사례는 일반적으로 UI 차단을 방지하기 위해 작업 (예: 대규모 계산)을 보조 스레드로 오프로드하는 것과 관련이 있습니다.

• 예: 비디오 게임 PROXX를 빌드한 팀은 사용자 입력과 애니메이션을 처리하기 위해 기본 스레드를 최대한 자유롭게 두려고 했습니다. 이를 위해 웹 워커를 사용하여 별도의 스레드에서 게임 로직과 상태 유지 관리를 실행했습니다.

서비스 워커 태스크는 일반적으로 네트워크 프록시로 작동하고, 백그라운드 태스크를 처리하고, 캐싱 및 오프라인과 같은 작업과 더 관련이 있습니다.

예: 팟캐스트 PWA에서는 사용자가 전체 에피소드를 오프라인 저장하여 오프라인 상태에서 들을 수 있도록 허용할 수 있습니다. 서비스 워커, 특히 Background Fetch API를 사용하여 이 작업을 실행할 수 있습니다. 이렇게 하면 에피소드가 다운로드되는 동안 사용자가 탭을 닫아도 작업이 중단되지 않습니다.

도구 및 라이브러리

창과 작업자 통신은 다양한 하위 수준 API를 사용하여 구현할 수 있습니다. 다행히 이 프로세스를 추상화하여 가장 일반적인 사용 사례를 처리하는 라이브러리가 있습니다. 이 섹션에서는 각각 웹 워커와 서비스 워커의 창을 처리하는 두 가지 도구인 Comlink와 Workbox를 다룹니다.

Comlink

Comlink는 Web Worker를 사용하는 웹사이트를 빌드할 때 많은 기본 세부정보를 처리하는 작은 (1.6k) RPC 라이브러리입니다. PROXX 및 Squoosh와 같은 웹사이트에서 사용되었습니다. 동기 및 코드 샘플의 요약은 여기에서 확인할 수 있습니다.

Workbox

Workbox는 서비스 워커를 사용하는 웹사이트를 빌드하는 데 많이 사용되는 라이브러리입니다. 캐싱, 오프라인, 백그라운드 동기화 등에 관한 일련의 권장사항을 패키징합니다. workbox-window 모듈은 서비스 워커와 페이지 간에 메시지를 교환하는 편리한 방법을 제공합니다.

다음 단계

이 시리즈의 나머지 부분에서는 창 및 서비스 워커 통신 패턴에 중점을 둡니다.

• 명령형 캐싱 가이드: 페이지에서 서비스 워커를 호출하여 리소스를 미리 캐시합니다 (예: 미리 가져오기 시나리오).
• 업데이트 브로드캐스트: 서비스 워커에서 페이지를 호출하여 중요한 업데이트 (예: 새 버전의 웹사이트 사용 가능)를 알립니다.
• 양방향 통신: 서비스 워커에 작업(예: 대용량 다운로드)을 위임하고 페이지에 진행 상황을 계속 알립니다.

창과 웹 작업자 통신 패턴은 웹 작업자를 사용하여 브라우저의 기본 스레드에서 JavaScript 실행을 참고하세요.