Веб-отзывчивость и производительность становятся все более важными как для пользовательского опыта, так и для SEO. Одна большая вещь, которая всегда мешала нам в этих областях, — это длительное выполнение JavaScript. Вызов скриптов внизу документа и использование асинхронного JavaScript помогают, но, конечно же, не могут решить все ваши проблемы.
Допустим, вам нужно выполнить много обработки изображений и некоторые другие дорогостоящие вычисления при загрузке вашей страницы. Хотя вы можете выполнять часть этой работы асинхронно, в конце концов все все равно должно обрабатываться одним и тем же потоком JavaScript. Что делают рабочие, так это предоставляют другие потоки для запуска вашего кода. По сути, рабочие процессы — это просто файлы JavaScript, которые можно запускать в отдельных потоках одновременно с вашим основным потоком JavaScript.
Типичные типы работников, с которыми вы сталкиваетесь, — это выделенные работники, общие работники и работники службы. Вы можете просто создать новый воркер как переменную в своем коде, а затем использовать соответствующие методы и обработчики событий каждого воркера для связи между этим воркером и основным потоком в вашем проекте. При написании кода в рабочем файле важно помнить, что рабочие процессы не имеют доступа к глобальной области действия вашего окна, а вместо этого имеют свои собственные области, методы и функции, к которым у них есть доступ. Из-за этого есть некоторые вещи, которые вы не можете делать внутри работника. Например, вы не можете манипулировать DOM из воркера или использовать некоторые свойства окна. Для связи между этими работниками и вашим основным потоком вы используете postMessage(“example-data”) для отправки данных. Обработчик событий onMessage используется для обработки этих вызовов postMessage.
Выделенные рабочие процессы, new Worker(“example.js”), представляют собой файлы JavaScript, которые доступны только сценарию, вызвавшему их изначально. Это хороший способ переместить определенную часть автономной логики в отдельный поток, если вам нужен доступ только к этому коду из одного источника.
С другой стороны, к общим рабочим процессам, new SharedWorker('example.js'), можно получить доступ из нескольких различных сценариев или контекстов просмотра. Из-за этого связь между этими работниками и вашими сценариями имеет дополнительный шаг. К вашему воркеру прикреплен объект порта, который необходимо вызвать, чтобы использовать ваши функции postMessage() и onMessage. Хотя это делается неявно для вас в выделенном сервис-воркере, вы должны указать это в общем воркере, так как интерфейс MessageEvent, используемый для связи с воркерами, иногда может возвращать массив портов. Короче говоря, это просто дополнительный шаг при общении с общим воркером, но вы можете получить доступ к этому воркеру из любых скриптов, окон или iFrames, которые вы используете, при условии, что они находятся в одном домене.
Служащие немного другие. Это рабочие процессы, настроенные для перехвата и обработки сетевых запросов. Они часто используются для работы в автономном режиме, но также могут использоваться для обработки кэширования, обновления ресурсов или других фоновых серверов и операций, связанных с запросами. Они немного сложнее, так как требуют первоначальной регистрации, локальной установки при начальной загрузке страницы, которая обрабатывает такие вещи, как настройка локальных кешей, а затем активация, чтобы сделать воркер доступным для использования. Хотя это требует некоторой настройки, преимущества возможности обработки нестабильных соединений могут быть огромным преимуществом.
Если ваше приложение страдает от тяжелых вычислений, и вам нужен способ сделать тяжелую работу, не блокируя ваш основной поток, работники, вероятно, будут отличным решением. Если вы хотите узнать больше о работниках, вот несколько замечательных ресурсов:
API веб-воркеров — веб-документы MDN
Использование веб-воркеров — веб-документы MDN
API Service Worker — веб-документы MDN
Использование сервис-воркеров — веб-документы MDN
Веб-воркеры против сервис-воркеров против ворклетов — Ире Адеринокун
