Этот раздел не является нормативным.
Веб-приложения традиционно предполагают, что сеть доступна. Это предположение пронизывает платформу. HTML-документы загружаются через HTTP и обычно получают все свои подресурсы через последующие HTTP-запросы. Это ставит веб-контент в невыгодное положение по сравнению с другими стеками технологий.
Работник службы спроектирован в первую очередь для исправления этого баланса, предоставляя контекст Web Worker, который может быть запущен средой выполнения, когда вот-вот начнутся переходы. Этот управляемый событиями рабочий процесс зарегистрирован по источнику и пути (или шаблону), что означает, что к нему можно обращаться, когда происходит навигация в это место. События, соответствующие сетевым запросам, отправляются работнику, и ответы, сгенерированные этим работником, могут переопределять поведение сетевого стека по умолчанию. Это концептуально ставит работника службы между сетью и средством визуализации документов, позволяя работнику службы предоставлять контент для документов даже в автономном режиме.
Веб-разработчики, знакомые с предыдущими попытками решить проблему офлайн, сообщают о дефиците гибкости в этих решениях. В результате работник службы в высшей степени процедурен, что обеспечивает максимальную гибкость за счет дополнительной сложности для разработчиков. Частично эта сложность возникает из-за необходимости держать работников службы гибкими в отношении однопоточной модели выполнения. В результате API-интерфейсы, предоставляемые работниками служб, почти полностью асинхронны — шаблон, знакомый в других контекстах JavaScript, но подчеркнутый здесь необходимостью избегать блокировки загрузки документов и ресурсов.
Разработчики, использующие «Кэш Приложений HTML5» (HTML5 Application Cache), также сообщают, что некоторые атрибуты дизайна вносят вклад в неисправимые ошибки. Ключевой принцип разработки работника службы заключается в том, что ошибки всегда должны быть исправлены. Многие детали процесса обновления работника службы предназначены для того, чтобы избежать этих опасностей.
Работники службы запускаются и поддерживаются их отношением к событиям, а не к документам. Этот дизайн во многом заимствован у разработчиков и поставщиков из опыта работы с Общими Работниками Shared Workers и Фоновыми Страницами Chrome. Ключевым уроком этих систем является необходимость ограничить время выполнения контекстов фоновой обработки, как для экономии ресурсов, так и для обеспечения того, чтобы потеря и перезапуск фонового контекста были первоочередными задачами разработчиков. В результате работники службы более чем мимолётно похожи на Страницы Событий Chrome, преемников Фоновых Страниц. Работники службы могут быть запущены пользовательскими агентами без прикрепленного документа и могут быть убиты пользовательским агентом практически в любой момент. Концептуально работников службы можно рассматривать как Общих Работников (Shared Workers), которые могут запускаться, обрабатывать события и умирать, даже не обрабатывая сообщения из документов. Разработчикам рекомендуется иметь в виду, что работники службы могут запускаться и завершаться много раз в секунду.
Работники службы — это общие, управляемые событиями, ограниченные по времени контексты скриптов, которые выполняются в источнике (origin). Эти свойства делают их естественными конечными точками для ряда служб времени выполнения, которые могут пережить контекст конкретного документа, например обработка push-уведомлений, фоновая синхронизация данных, ответы на запросы ресурсов из других источников или получение централизованных обновлений дорогостоящих для расчета данных (например, геолокации или гироскопа).
Информационные ссылки
Стандарт Service Workers Nightly — https://w3c.github.io/ServiceWorker/#motivations
