Эта статья является продолжением моей предыдущей статьи, в которой я рассказывал о Web Workers. В этом посте я расскажу о сервис-воркерах.
Service Worker – это скрипт, работающий в фоновом режиме браузера без участия пользователя. Он действует как прокси-сервер между браузером (веб-приложением) и сетью, позволяя вам контролировать, как обрабатываются сетевые запросы с вашей страницы. Этот скрипт может перехватывать сетевые запросы, помогать в создании эффективных автономных интерфейсов и обновлять активы, находящиеся на сервере, среди прочего.
Предпосылки
Есть определенные моменты, которые вы должны учитывать при работе с Service Workers.
⦁ Во время разработки вы можете использовать локальный хост, но для его развертывания на сайте вам потребуется настроить HTTPS на вашем сервере.
⦁ Service Worker завершается, когда он не используется, и перезапускается, когда он в следующий раз понадобится, поэтому вы не можете полагаться на глобальное состояние в Service Worker. Если есть информация, которую вам нужно сохранить и повторно использовать при перезапусках, вы можете использовать Индексированную БД.
⦁ Сервисные работники не могут напрямую обращаться к DOM. Вместо этого он может взаимодействовать со страницами, которыми он управляет, отвечая на сообщения, отправленные через интерфейс postMessage, и эти страницы могут при необходимости манипулировать DOM.
Жизненный цикл сервисного работника
Жизненный цикл Service Worker полностью отделен от вашей веб-страницы.
Чтобы установить Service Worker, вы должны сначала зарегистрировать его на своей главной странице. Регистрация Service Worker приведет к тому, что браузер загрузит файл Service Worker и инициирует шаг install в фоновом режиме.
На этапе установка вы можете кэшировать ресурсы, которые можно будет загрузить позже. Если установка прошла успешно, сервисные работники переходят к этапу активации.
После этапа активации сервис-воркер будет контролировать все страницы, попадающие в его область действия, хотя страница, на которой зарегистрирован сервис-воркер в первый раз, не будет контролироваться, пока не будет загружена снова. Это связано с тем, что событие выборки страницы не будет проходить через Service Worker, если сам запрос страницы не прошел через Service Worker.
Как только Service Worker получает контроль, он будет находиться в одном из двух состояний: либо Service Worker будет остановлен для экономии памяти, либо он будет обрабатывать события выборки и сообщения, которые происходят, когда сетевой запрос или сообщение отправляется с вашей страницы.
Ниже приведена упрощенная схема жизненного цикла
Зарегистрировать сервисного работника
Чтобы запустить Service Worker, вы должны сначала зарегистрировать его на своей главной странице. Это сообщает браузеру, где находится ваш файл JavaScript Service Worker.
В index.html мы добавили скрипт для регистрации Service Worker. Этот код проверяет, доступен ли API Service Worker, и если да, то Service Worker в /sw.js регистрируется после загрузки страницы. Расположение файла, которое я использовал для sw.js, находится в корне домена. Это означает, что областью действия Service Worker будет весь источник. Другими словами, этот Service Worker будет получать события для всего в этом домене. Если мы сохраним файл Service Worker в /public/sw.js, тогда Service Worker будет видеть события выборки только для страниц, URL-адрес которых начинается с /public/ (т. е. /public/page1/, /public/page2/).
Установить сервис-воркер
После регистрации переходим к этапу установки. Это первое событие, которое получает Service Worker. Он запускается, как только запускается Service Worker, и вызывается только один раз для каждого Service Worker. На этом этапе вам нужно кэшировать некоторые статические ресурсы. Если все файлы успешно закэшированы, Service Worker устанавливается. Если какой-либо из файлов не загрузится и не кэшируется, то шаг установки завершится ошибкой, и Service Worker не будет активирован (т. е. не будет установлен).
В приведенном выше примере Service Worker прослушивает события install. cache.open создаст новый кеш с именем SERVICE_WORKER, а затем с помощью cache.addAll мы добавим все URL-адреса, которые хотим кэшировать. events.waitUntil продлевает время жизни события установки до тех пор, пока переданное обещание не будет успешно разрешено или не будет отклонено. Если обещание отклонено, установка считается неудачной, а Service Worker забрасывается.
Здесь мы кэшировали одно изображение, один файл CSS и автономную страницу, которая будет загружена, если у нас возникнут проблемы с сетью. Страница offline.html использует тот же CSS и изображение, что и главная страница, для повторного использования кэшированных файлов.
Вы можете проверить, включен ли ваш Service Worker, проверив chrome://inspect/#service-workers или выбрав параметр Service Workers в Application. вкладка браузера
Вы также можете проверить кеш, созданный в браузерах.
⦁ Для Chrome установите флажок Хранилище кэша на вкладке Приложение, где будет создан кэш SERVICE_WORKER. Он будет содержать все файлы, которые вы кэшировали.
⦁ Для Mozilla перейдите на вкладку Хранилище, где Хранилище кеша будет содержать кеш с именем SERVICE_WORKER.
Активация сервис-воркера
После установки Service Worker следующим шагом будет его активация. После активации Service Worker начнет контролировать все страницы, попадающие в его область действия.
Это событие является идеальным местом для удаления старого кэшированного статического контента, если была создана более новая версия того же самого (об этом будет рассказано позже).
Запросы кэширования и возврата
Теперь, когда Service Worker активирован и контролирует все страницы в своей области, нашим следующим шагом должен быть возврат кэшированного ответа.
Когда пользователь переходит на другую страницу или обновляет ее, Service Worker начнет получать события выборки.
Мы определили прослушиватель событий fetch, и в нем есть два условия. Во-первых, когда пользователь пытается перейти на HTML-страницу и возникает ошибка (например, сетевая ошибка), мы просто возвращаем автономную страницу из кеша. В другом случае мы сопоставляем наш кеш с запрошенным URL-адресом, и если у нас есть соответствующий ответ, мы возвращаем кешированное значение, в противном случае мы возвращаем результат вызова fetch, который сделает сетевой запрос и вернет данные, если что-то может. извлекаться из сети.
caches.match() просматривает запрос и находит все закэшированные результаты из любого кеша, созданного вашим Service Worker. Метод event.respondWith() предотвращает обработку выборки браузером по умолчанию, что позволяет вам самостоятельно предоставить обещание в качестве ответа.
Чтобы протестировать эту функциональность, вы можете использовать встроенные в Chrome инструменты разработчика. Перейдите на вкладку Сеть и измените онлайн на офлайн и обновите страницу.
Бум !! вы будете перенаправлены на автономную страницу (offline.html).
Обновление сервис-воркера
Когда пользователь переходит на ваш сайт, браузер пытается повторно загрузить файл сценария, определяющий Service Worker в фоновом режиме. Если в файле Service Worker есть разница хотя бы в байте по сравнению с тем, что у него есть на данный момент, он считает его новым.
Этот новый Service Worker будет установлен. Но в этот момент старый сервис-воркер все еще контролирует текущие страницы, поэтому новый сервис-воркер переходит в состояние ожидания. Как только текущие открытые страницы вашего веб-приложения будут закрыты, старый Service Worker будет уничтожен браузером, а затем вновь установленный Service Worker получит полный контроль. Это когда будет запущено его событие «активировать».
Если вы хотите, чтобы ваш новый Service Worker переопределял старый, используйте self.skipWaiting().
Одной из общих задач, которую мы выполняем в событии activate, является управление кешем. Здесь мы можем стереть старые кеши, созданные старыми сервис-воркерами. Причина сделать это здесь заключается в том, что если вы очистите все старые кеши на этапе установки, старый Service Worker, который контролирует все текущие страницы, внезапно перестанет обслуживать файлы из этого кеша.
Этот код выше перебирает все кэши в Service Worker и удаляет все кэши, которые не определены в белом списке кэшей.
Это объединенный код файла Service Worker (sw.js).
Случаи применения
То, что мы обсуждали выше, — это основные способы использования Service Worker, но Service Workers — это гораздо больше. Их можно использовать для предоставления некоторых уникальных функций:
Push-уведомления — это сообщения, которые появляются на устройстве пользователя. Они позволяют пользователям подписаться на своевременные обновления из веб-приложений.
Фоновая синхронизация: позволяет отложить действия до тех пор, пока у пользователя не будет стабильного подключения.
Периодическая синхронизация (в будущем) — API, предоставляющий функции для управления периодической фоновой синхронизацией.
Геозона (в будущем). Веб-приложение получает уведомление, когда устройство пересекает геозону, без необходимости периодически запрашивать Geolocation API.
Спасибо, что нашли время, чтобы прочитать мою статью.
