Как веб-работники и сервис-воркеры могут улучшить производительность вашего сайта и когда использовать веб-воркеров, а не сервис-воркеров.
В этом обзоре объясняется, как веб-работники и сервис-воркеры могут улучшить производительность вашего веб-сайта, а также когда использовать веб-воркеров, а не сервис-воркеров. Прочтите остальную часть этой серии , чтобы узнать о конкретных моделях взаимодействия окон и сервисных работников.
Как сотрудники могут улучшить ваш сайт
Браузер использует один поток ( основной поток ) для запуска всего JavaScript на веб-странице, а также для выполнения таких задач, как рендеринг страницы и сбор мусора. Запуск чрезмерного кода JavaScript может заблокировать основной поток, что задержит выполнение браузером этих задач и приведет к ухудшению пользовательского опыта.
При разработке приложений iOS/Android распространенной схемой обеспечения того, чтобы основной поток приложения оставался свободным для реагирования на пользовательские события, является разгрузка операций дополнительным потокам. Фактически, в последних версиях Android слишком длительная блокировка основного потока приводит к сбою приложения .
В Интернете JavaScript был разработан на основе концепции одного потока, и ему не хватает возможностей, необходимых для реализации модели многопоточности, подобной той, которая есть в приложениях, например, общей памяти.
Несмотря на эти ограничения, аналогичная схема может быть достигнута в Интернете, используя рабочие процессы для запуска сценариев в фоновых потоках, что позволяет им выполнять задачи, не мешая основному потоку. Воркеры — это целая область JavaScript, работающая в отдельном потоке без какой-либо общей памяти.
В этом посте вы узнаете о двух разных типах воркеров (веб-воркеров и сервис-воркеров), их сходствах и различиях, а также наиболее распространенных шаблонах их использования на рабочих веб-сайтах.
Веб-работники и сервисные работники
Сходства
Веб-воркеры и сервис-воркеры — это два типа воркеров, доступных для веб-сайтов. У них есть некоторые общие черты:
- Оба выполняются во вторичном потоке, что позволяет выполнять код JavaScript без блокировки основного потока и пользовательского интерфейса.
- У них нет доступа к объектам
WindowиDocument, поэтому они не могут напрямую взаимодействовать с DOM, а также имеют ограниченный доступ к API браузера.
Различия
Можно подумать, что большинство вещей, которые можно делегировать веб-воркеру, можно сделать и сервис-воркеру, и наоборот, но между ними есть важные различия:
- В отличие от веб-воркеров, сервис-воркеры позволяют перехватывать сетевые запросы (через событие
fetch) и прослушивать события Push API в фоновом режиме (через событиеpush). - Страница может порождать несколько веб-воркеров, но один сервис-воркер контролирует все активные вкладки в области , в которой он был зарегистрирован.
- Продолжительность жизни веб-воркера тесно связана с вкладкой, к которой он принадлежит, тогда как жизненный цикл сервис-воркера не зависит от нее. По этой причине закрытие вкладки, на которой работает веб-воркер, приведет к его прекращению, в то время как сервис-воркер может продолжать работать в фоновом режиме, даже если на сайте нет открытых активных вкладок.
Случаи использования
Различия между обоими типами воркеров позволяют предположить, в каких ситуациях можно использовать тот или иной:
Варианты использования веб-воркеров чаще всего связаны с перенесением работы (например, тяжелых вычислений ) на вторичный поток, чтобы избежать блокировки пользовательского интерфейса.
- Пример: команда, создавшая видеоигру PROXX , хотела оставить основной поток как можно более свободным, чтобы позаботиться о пользовательском вводе и анимации. Для этого они использовали веб-воркеров для запуска игровой логики и обслуживания состояния в отдельном потоке.
Задачи сервисных работников обычно больше связаны с работой в качестве сетевого прокси, обработкой фоновых задач и такими вещами, как кэширование и автономный режим.
Пример. В подкасте PWA можно разрешить пользователям загружать полные эпизоды, чтобы слушать их в автономном режиме. Для этой цели можно использовать сервис-воркера и, в частности, API фоновой выборки . Таким образом, если пользователь закроет вкладку во время загрузки эпизода, задачу не придется прерывать.
Инструменты и библиотеки
Взаимодействие окон и рабочих может быть реализовано с использованием различных API нижнего уровня. К счастью, существуют библиотеки, которые абстрагируют этот процесс и заботятся о наиболее распространенных случаях использования. В этом разделе мы рассмотрим два из них, которые отвечают за окна для веб-воркеров и сервис-воркеров соответственно: Comlink и Workbox .
Комлинк
Comlink — это небольшая (1,6 КБ) библиотека RPC , которая заботится о многих основных деталях при создании веб-сайтов, использующих Web Workers. Он использовался на таких сайтах, как PROXX и Squoosh . Краткое изложение его мотивов и примеры кода можно найти здесь .
Рабочий ящик
Workbox — популярная библиотека для создания веб-сайтов, использующих сервис-воркеров. Он содержит набор лучших практик по таким вещам, как кэширование, автономный режим, фоновая синхронизация и т. д. Модуль workbox-window обеспечивает удобный способ обмена сообщениями между сервис-воркером и страницей.
Следующие шаги
Остальная часть этой серии посвящена шаблонам взаимодействия окон и сервисных работников:
- Руководство по обязательному кэшированию : вызов сервисного работника со страницы для предварительного кэширования ресурсов (например, в сценариях предварительной выборки).
- Широковещательные обновления : вызов страницы от сервисного работника, чтобы сообщить о важных обновлениях (например, доступна новая версия веб-сайта).
- Двусторонняя связь : делегирование задачи сервисному работнику (например, тяжелая загрузка) и информирование страницы о ходе выполнения.
Шаблоны взаимодействия между оконными и веб-работниками см. в разделе Использование веб-работников для запуска JavaScript вне основного потока браузера .