Что такое service worker
Визуализация работы сервис-воркеров
Доброго времени суток, друзья!
Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры (Service Workers), которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).
Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»
В данной статье мы рассмотрим несколько практических примеров использования сервис-воркеров, что впоследствии, смею надеяться, сделает счастливыми ваших пользователей.
Полагаю, прежде чем разбирать практические примеры, необходимо хотя бы в общих чертах рассмотреть теоретические основы работы сервис-воркеров. Для начинающих разработчиков это послужит хорошим подспорьем в дальнейших начинаниях.
Что есть сервис-воркер?
Серсис воркер — это скрипт, запускаемый браузером в фоновом процессе. Помните, что сервис-воркер совершенно не зависит от страницы, с которой он взаимодействует или которой он служит (to serve — служить).
По сути, сервис-воркер представляет собой прокси сервер между веб-приложением, браузером и сетью.
Сервис-воркеры позволяют веб-приложениям работать подобно нативным приложениям.
Несколько фактов о сервис-воркерах
Как сервис-воркеры работают? Беглый взгляд
Сервис-воркеры позволяют перехватывать запросы к серверу и кешировать эти запросы с целью повышения производительности приложений. Таким образом, повышение производительности обеспечивается благодаря кешированию всего контента.
Но лучше один раз увидеть, так что вот вам изображение, показывающее работу сервис-воркера:
Жизненный цикл сервис-воркера
Как я упоминал ранее, сервис-воркеры работают независимо от управляющей страницы. Если вы хотите установить сервис-воркер в своем приложении, первым делом нужно его зарегистрировать.
После этого браузер, запустивший установку сервис-воркера, переходит в фоновый режим:
Самые распространенные случаи использования
Теперь, когда мы знаем, как работают сервис-воркеры, настало время поговорить о том, где они используются.
Кеширование
Как отмечалось выше, сервис-воркеры могут использоваться для кеширования. Вот некоторые примеры:
Веб-пуш (Web Push)
Веб-пуш позволяет приложениям отправлять пуш-уведомления и отображать контент, получаемый в ответ на эти уведомления.
Более сложные примеры использования
API аналитики
У меня есть приложение. И я хочу добавить в него возможность следить за использованием приложения. Для этого я беру синхронное API для обновления собранных данных время от времени.
Балансировщик загрузки
Допустим, вы хотите иметь возможность выбирать лучшего провайдера контента, опираясь на показатели работы сервера. В этом случае вам нужен сервис-воркер для перехвата запросов и осуществления выбора.
Я настоятельно рекомендую вам посетить ServiceWorke.rs для более подробного изучения сервис-воркеров.
Отрабатываем навыки
Как я всегда говорю: «Хочешь научиться плавать — лезь в воду». Изучение теории — вещь замечательная, но пока не испачкаешь руки, ничему не научишься.
Регистрация сервис-воркера
Если мы вновь обратимся к иллюстрации жизненного цикла сервис-воркера, то увидим, что перво-наперво нам необходимо его установить. Чтобы это сделать нам нужно его зарегистрировать.
В работе сервис-воркера можно убедиться, перейдя по адресу: Chrome://inspect/#service-workers.
Что дальше?
Теперь нам нужно закешировать все файлы. Мы можем выбирать файлы для кеширования. Вот как это выглядит:
Вот что здесь происходит:
Удаляем неиспользуемый кеш
Далее нам необходимо удалить старые версии кеша:
Получение ответа
Ничто из приведенного выше не имеет смысла, если у нас нет возможности получить закешированный контент.
Его можно получить с помощью обработчика события «fetch»:
Что такое сервис-воркеры и как они помогают повысить производительность
Сервис-воркеры позволяют разработчикам эффективнее управлять кэшированием ресурсов, чтобы пользователи могли продолжать использовать приложение даже при разрыве интернет-соединения. В этой статье разберем, как сервис-воркер может вывести производительность на новый уровень.
Что такое сервис-воркеры
Service worker — это особый тип JavaScript воркера, который представляет собой сценарий, выполняемый в фоновом режиме браузера пользователя. Он похож на прокси-сервер, размещенный между вашим приложением, браузером и сетью. Помимо прочего, сервис-воркеры позволяют приложениям продолжать работу в автономном режиме в случае потери подключения к интернету.
Эти сценарии предоставляют разработчикам больший контроль над обработкой запросов приложений и позволяют избежать негативного пользовательского опыта, если запрос зависнет.
Как сервис-воркеры улучшают производительность
У всех такое было: вы просматриваете веб-сайт, нажимаете на ссылку и встречаетесь с какой-либо вариацией сообщения «Не удается подключиться к интернету». Вы нажимаете кнопку назад и видите то же самое. Пока соединение не будет восстановлено, вы можете только играть в dino runner, если используете Chrome. Сервис-воркеры позволяют избежать этого нежелательного сценария.
Одно из самых больших преимуществ сервис-воркеров — способность поддерживать работу в оффлайн-режиме. В прошлом для обеспечения ограниченной автономной поддержки можно было использовать API AppCache, но теперь есть сервис-воркеры, и они гораздо лучше.
Загрузка данных из локального кэша всегда занимает меньше времени, чем запрос к серверу. Если вы кэшируете все ресурсы вашего приложения, то можете значительно улучшить время загрузки для посетителей, возвратившихся на сайт. Возрастает вероятность того, что они будут возвращаться снова и снова.
Как работают сервис-воркеры?
Сценарии сервис-воркеров независимы от вашего сайта или приложения. У них свой собственный жизненный цикл:
После того, как воркер будет зарегистрирован из JavaScript, браузер установит его. Если он правильно сконфигурирован, то начнет кэшировать статические ресурсы страницы немедленно, в ином случае вам придется повторить установку.
Если установка прошла успешно, сценарий активируется и получает контроль над всеми страницами в своей области видимости. Чтобы воркер заработал, установившая его страница должна перезагрузиться. После этого он может переключаться между двумя состояниями: обработка событий fetch и message или прекращение работы для экономии памяти.
Необходимые условия
Сервис-воркеры — замечательная технология по многим причинам, но они теоретически могут предоставить хакерам возможности для проникновения в ваше веб-приложение. Для защиты от атак типа «человек посередине» сценарии могут быть зарегистрированы только на страницах, обслуживаемых по протоколу HTTPS. Во время разработки можно использовать воркеры через localhost, но для работающего приложения необходимо настроить защищенный протокол.
Стоит также отметить, что большинство основных веб-браузеров (кроме IE) уже поддерживают сервис-воркеры.
Как зарегистрировать сервис-воркер
Сервис-воркеры основаны на JavaScript обещаниях (promises), поэтому прежде чем начать работу, будет полезно в них разобраться.
Как установить сервис-воркер
Прежде чем ваш воркер сможет что-то сделать, вы должны установить обработчик события install и указать, какие файлы следует кэшировать. Откройте файл sw.js и добавьте следующий код:
Как получать события
После успешной установки, воркер активируется. Следующий шаг — возврат кэшированных ответов. Для этого можно использовать следующий кусок кода:
Здесь определяется событие fetch и создается обещание caches.match. При запросе метод пытается найти любой закэшированный воркером ресурс. Если не получится, то будет сделан обычный запрос к серверу.
Поддержание актуальности
В этой статье разобрано только начало работы работы с сервис-воркерами. Для длительной автономной работы сервис-воркеров необходимо периодически обновлять. Узнать больше об этом можно здесь.
Советы по кэшированию
Способ реализации Service workers зависит от архитектуры веб-приложения. Вот несколько советов, которые помогут вам:
Потоковые ответы
Если большинство ваших страниц содержат статическую шапку и подвал, лучше всего обрабатывать навигационные запросы с помощью потокового ответа, состоящего из отдельно кэшированных подресурсов. Потоки позволяют приложению отвечать на запросы навигации кэшированными фрагментами HTML.
В некоторых ситуациях, например, когда HTML-код зависит от данных из CMS, связь с сетью неизбежна. Тем не менее, внедрение сервис-воркеров и потоковых ответов улучшает пользовательский опыт, так как часть страницы будет отображена сразу, пока остальной код еще не загрузился.
Кэширование статического HTML-кода
Если веб-приложение состоит из статических HTML-документов, можно вовсе обойтись без связи с сетью.
Вам просто нужно создать service worker, который возвращает кэшированный HTML. Конечно, необходима некоторая неблокирующая логика для поддержания HTML в актуальном состоянии при внесении изменений. Для этого используется политика stale-while-revalidate:
Как вариант, вы можете использовать Workbox для создания воркера, способного кэшировать ваши статические ресурсы, обслуживать их и поддерживать в актуальном состоянии.
Одностраничные приложения
Интеграция сервис-воркера в архитектуру App Shell позволяет одностраничным приложениям с одной страницей не обращаться к сети при обработке навигационных запросов. После установки и активации обработчиков добавьте этот код для кэширования и обновления app-shell.html:
Теперь все навигационные запросы должны возвращать кэшированную копию HTML-документа, содержащего основные элементы приложения. Приведенный выше код также включает логику маршрутизации на стороне клиента для отображения содержимого на основе URL-адреса.
Измерение увеличения производительности
Конечно, точная количественная оценка производительности должна основываться на реальных данных. Инженер Google опубликовал тематическое исследование о том, как создатели веб-приложения Google I/O измеряли влияние сервис-воркеров на производительность с помощью Google Analytics.
Разработчики начали с перечисления вопросов, на которые должны были ответить собранные данные. Во-первых, они хотели знать, является ли кэширование с помощью воркеров более эффективным, чем дефолтное HTTP-кэширование. При повторном посещении пользователи ожидают, что страницы будут загружаться быстрее, поэтому важно знать, действительно ли воркеры ускоряют работу приложения.
Затем нужно было решить, какие показатели лучше всего характеризуют скорость. «Время загрузки страницы» не отражает момент, после которого со страницей можно взаимодействовать. Гораздо полезнее такие метрики как первая значимая отрисовка и первое взаимодействие, они отражают восприятие пользователей. После определения правильных вопросов и нужных показателей можно оценить необходимость и возможность оптимизации.
Резюме
Сервис-воркеры не только повышают производительность сети. Например, они могут использоваться для реализации push-уведомлений, что особенно полезно в мобильных приложения. В будущем сервис-воркеры смогут делать еще много полезных вещей, например, осуществлять геозонирование. Другими словами, пора начинать экспериментировать с воркерами, потому что в ближайшее время они точно не исчезнут.
Service Workers. Инструкция по применению
Количество выходов в интернет с мобильных устройств ежегодно растёт на 2-4% в год. Качество связи не успевает за такими темпами. Как итог, даже самое лучшее веб-приложение обеспечит ужасный опыт, если пользователь не сможет его загрузить.
Проблема в том, что до сих пор нет хорошего механизма управления кэшем ресурсов и результатов сетевых запросов. В своей статье я хочу рассказать как Service Worker (SW) может помочь в решении этой задачи. Объясню в формате рецептов — какие элементы и в какой пропорции смешать, чтобы получить нужный результат, исходя из задачи и требований.
До появления SW проблему работы в offline-режиме решал другой API — AppCache. Однако наряду с подводными камнями AppCache фигурировал факт, что он отлично работает в single-page приложениях, но не очень хорошо подходит для многостраничных сайтов. SW разрабатывались, чтобы избежать этих проблем.
Что такое Service Worker?
Во-первых, это скрипт, который браузер запускает в фоновом режиме, отдельно от страницы, открывая дверь для возможностей, не требующих веб-страницы или взаимодействия с пользователем. Сегодня они выполняют такие функции как push-уведомления и фоновая синхронизация, в будущем SW будут поддерживать и другие вещи. Ключевая их особенность — это возможность перехватывать и обрабатывать сетевые запросы, включая программное управление кэшированием ответов.
Во-вторых, SW запускается в worker контексте, поэтому он не имеет доступа к DOM и работает в потоке, отдельном от основного потока JavaScript, управляющего вашим приложением, а следовательно — не блокирует его. Он призван быть полностью асинхронным, поэтому использовать синхронные API (XHR и LocalStorage) в SW нельзя.
В-третьих, из соображений безопасности SW работают только по HTTPS, так как давать посторонним людям возможность изменять сетевые запросы крайне опасно.
Что нужно кэшировать?
Для того чтобы приложение стало более отзывчивым, нам нужно кэшировать все статичные файлы:
Почему мы не можем использовать LocalStorage для подобной ситуации?
Всё очень просто. LocalStorage — синхронный API, имеет ограничение в 5MB и позволяет хранить только строки.
У SW с этим всё лучше: он асинхронный, является прокси для запросов, что позволяет обрабатывать и кэшировать любой запрос и согласно статье Offline Storage for Progressive Web Apps от Эдди Османи:
Мне уже нравится Service Worker. Как его использовать?
Ниже я расскажу про рецепты приготовления SW для создания отзывчивых и понятных приложений.
Заготовки для приготовления Service Workers
Для написания своего собственного SW нам понадобятся:
В файле sw.js нам нужно лишь определить базовые события, на которые будет реагировать SW.
Подробности про lifecycle для SW вы можете узнать из данной статьи.
Рецепт №1 — Network or cache
Подходит для медийных сайтов, где очень много медиа-контента. Картинки и видео могут отдаваться долго, наша задача закэшировать их. При последующих запросах на сервер мы будем отдавать данные из кэша. Имеем в виду, что данные могут быть уже неактуальными, для нас главное здесь — избавить пользователя от ожидания загрузки файлов.
Решение
Данный вариант подойдёт, если скорость загрузки контента для вас приоритетна, но хотелось бы показать наиболее актуальные данные.
Механизм работы следующий: идёт запрос на ресурс с ограничением по времени, например 400ms, если данные не были получены в течении этого времени, мы отдаём их из кэша.
SW в этом рецепте пытается получить самый актуальный контент из сети, но если запрос занимает слишком много времени, то данные будут взяты из кэша. Эту проблему можно решить путём выставления timeout’а на запрос.
Рецепт №2 — Cache only
Идеальный рецепт для лендингов, задача которых — продемонстрировать пользователю продукт и тем самым задержать его внимание на сайте. Медленная загрузка контента при плохом соединении в данном случае просто неприемлема, поэтому приоритет данного рецепта — отдача данных из кэша при любом соединении. Исключение — первый запрос и чистка кэша. Минус способа в том, что если вы измените контент, то у пользователей перемена произойдет после того, как кэш станет невалидным. По умолчанию SW делают перерегистрацию через 24 часа после установки.
Решение
Всё, что мы делаем, это при регистрации SW складываем в кэш все наши статичные ресурсы; при последующих обращениях к ресурсам SW всегда будет отвечать данными из кэша.
Рецепт №3 — Cache and update
Данный рецепт решает проблему актуальности данных, чего не было в рецепте №2.
Иными словами мы получим обновлённый контент, но с задержкой до следующей загрузки страницы.
Решение
Как и в предыдущем варианте, в данном рецепте SW сначала отвечает из кэша, чтобы доставить быстрые ответы, но при этом обновляет данные кэша из сети.
Рецепт №4 — Cache, update and refresh
Расширение рецепта №3. В данном решении мы обновляем контент в фоне, но всегда можем указать пользователю, что данные на странице поменялись. Примером может служить создание приложений, в которых происходит редактирование контента в фоне. Так, вы читаете статью на новостом сайте и получаете уведомление о том, что данные на странице обновились и появилась более свежая информация.
Решение
Рецепт позволяет SW отвечать из кэша, чтобы отдавать быстрые ответы, а также обновлять данные в кэше из сети. Когда запрос выполнится успешно, пользовательский интерфейс будет обновлён автоматически или посредством UI-контрола.
Используйте содержимые данные из кэша, но в то же время выполняйте запрос на обновление записи кэша и информируйте UI о новый данных.
Рецепт №5 — Embedded fallback
Существует проблема, когда браузер по умолчанию выдаёт вам сообщение о том, что вы офлайн. Я называю это проблемой, так как:
Решение
Нужно отдать fallback-данные, если нет доступа к ресурсам (сеть и кэш).
Данные подготавливаются заранее и кладутся как статичные ресурсы, доступные SW.
Заключение
Выше мы рассмотрели базовые рецепты применения SW для приложений.
Они описаны по мере усложнения. Если у вас простой лендинг — не нужно лезть в дебри, просто используйте Cache only или Network or cache. Для более сложных приложений используйте остальные рецепты.
Статья задумывалась начальной в серии статей о SW API. Хочется понять, насколько тема интересна и полезна. Жду ваших комментариев и пожеланий.
Кто ты такой, Service Worker?
Service Worker: Я программируемый сетевой проксификатор.
Service Worker звучит круто, но я не очень то понимаю что это
В июле 2015 я участвовала в конференции по JavaScript, проходившей в городе Остин, штат Техас. На сцене — Джейк Арчибальд, которого тогда я знала как забавного британского парня, любителя пошутить на “туалетную тему” 🚽. Уже потом я поняла, что он вполне себе “важный чувак” и является одним из разработчиков спецификации Service Worker’ов.
И вот по ходу истории об UX-откровении, настигнувшем его в общественном туалете, Джейк рассказал залу о новой штуке, названной Service Worker. Штуке, позволяющей вашему веб-сайту вести себя как нативное приложение (по крайней мере тогда я поняла его именно так).
То, о чем он говорил, звучало невероятно, и мне захотелось попробовать технологию на своем проекте. Сначала было немного трудно понять что это… Это не библиотека, не новый HTML элемент и даже не новый JavaScript синтаксис, а такие термины как “кэш” или “прокси” всегда приводили меня в замешательство. Пытаясь разобраться в принципах работы Service Worker’а, я делала пометки на бумаге, и мне в голову пришла идея сравнить его с “пришельцем, которого вы приглашаете пожить в вашем браузере”. Звучит странно? Тогда давайте попробуем разобраться.
S ervice Worker — пришелец во вселенной веб-браузера.
Представьте: ваш браузер — это планета (наподобие Земли), частица большой галактики вашего компьютера. Люди на этой планете разговаривают на своих языках, таких как HTML, CSS и JavaScript, благодаря которым они формируют сообщества — веб страницы.
И если вы веб-разработчик, вы должны хорошо разбираться как функционируют эти сообщества: начиная от их разнообразных элементов и DOM дерева и заканчивая режимами обновления данных на вашем сайте.
На этой планете (в браузере) был придуман способ общения с внешним миром, который позволил запрашивать информацию из других галактик (серверов). Его назвали Hyper Text Transfer Protocol. Именно так ваша планета-браузер превратилась в копилку милых картинок с котятами и ненужных твитов. И именно так она смогла привлечь к себе миллионы постоянных пользователей.
HTTP похож на невероятную волшебную вещицу, однако, чтобы она работала, вам нужен Интернет. Представим его как длинный многоколенчатый трубопровод. Интернет обеспечивает нам необходимое сообщение с удаленными серверами-галактиками. Длина такого трубопровода зависит от того, сколько вы платите обслуживающей организации (интернет-провайдеру), и от качества инфраструктуры в вашем регионе. Если ваша труба узкая или слишком длинная, то и данные из других галактик поступают на вашу планету дольше.
Но дело в том, что Интернет порой оказывается и вовсе недоступным для вашего браузера. В такие периоды ваша планета возвращается в доисторическую эпоху, и никакие из современных вещей вам не доступны, а ваш браузер показывает картинки динозавров, как напоминание о “старых добрых”.
Но подождите! Service Worker уже здесь, чтобы помочь!
Три вещи, которые следует знать о вашем новом приятеле.
Итак, какого типа работу может выполнить для вас Service Worker?
1. Взаимодействие с кэшем
Вы можете попросить Service Worker отслеживать fetch events и сохранять определенные ресурсы в кэше. Позже, когда эти ресурсы понадобятся, он передаст их вашему сайту, а делать внешний HTTP-запрос будет уже не нужно. Таким образом, если необходимые данные предварительно закэшированы, браузер сможет показывать контент веб-страниц даже при отсутствии интернет-подключения.
2. Push-уведомления
Благодаря магии, по которой Service Worker работает даже при выключенном браузере, вы можете всегда быть в курсе, получая push-уведомления.
3. Фоновая синхронизация
Активность при закрытом браузере означает еще и то, что Service Worker будет работать, не отвлекая внимания пользователя на текущие процессы. Скажем, вы используете веб-страницу, будучи offline, но вам необходимо отправить файл. Так вот, Service Worker сам отправит файл на сервер, когда интернет станет доступен снова.
Service Worker API
Service worker фактически выполняет роль прокси-сервера, находящегося между веб-приложением и браузером, а также сетью (если доступна). Он позволяет (кроме прочего) описывать корректное поведение веб-приложения в режиме офлайн, перехватывать запросы сети и принимать соответствующие меры, основываясь на доступности сети, и обновлять данные, находящиеся на сервере при доступе к нему. Также они имеют доступ к push-уведомлениям и API для фоновой синхронизации.
Концепция и использование Service Worker
Service worker — это событийно-управляемый worker, регистрируемый на уровне источника и пути. Он представляет собой JavaScript-файл, который может контролировать веб-страницу/сайт, с которым он ассоциируется, перехватывать и модифицировать запросы навигации и ресурсов, очень гибко кешировать ресурсы, для того чтобы предоставить вам полный контроль над тем, как приложение ведёт себя в определённых ситуациях (например, когда сеть не доступна).
Service worker запускается в контексте воркеров, поэтому он не имеет доступа к DOM и работает в потоке отдельном от основного потока JavaScript, управляющего вашим приложением, а следовательно — не блокирует его. Он призван быть полностью асинхронным; как следствие, синхронные API, такие как XHR и localStorage, в Service Worker’е использовать нельзя.
Из соображений безопасности service worker’ы работают только по HTTPS (либо, в целях разработки, на localhost ). Давать сторонним людям возможность изменять сетевые запросы крайне опасно. Кроме того, Service Worker API недоступен в режиме приватного просмотра браузера Firefox.
Примечание: Service Worker’ы выигрывают у предыдущих решений, таких как AppCache, потому что не делают предположений о том, что вы пытаетесь сделать, и не ломаются, в случаях если их предположения не оказываются верными; вы имеете полный контроль над всем.
Примечание: Service worker’ы широко используют промисы (Promises). В общем случае они будут ждать ответа, после которого вернутся с успешным или неудачным завершением. Архитектура на промисах для этого подходит идеально.
Регистрация
Загрузка, установка и активация
Service Worker будет следовать следующему жизненному циклу:
После этого он будет загружаться каждые 24 часа или около того. Он может загружаться и чаще, но он должен загружаться как минимум каждые 24 часа, чтобы предотвратить использование старой версии кода клиентом.
Установка производится в случае если загружаемый файл признается новым — либо отличным от уже установленного service worker (определяется через побайтовое сравнение), либо первым устанавливаемым service воркером для этой страницы/сайта.
Если это первый раз, когда service worker оказался доступен, будет проведена установка, а после успешного её завершения — активация.
Вы можете подписаться на InstallEvent (en-US) ; для того чтобы подготовить ваш service worker к использованию, к примеру, чтобы создать кеш при помощи встроенного API хранилища и разместить внутри него данные, которые вам необходимы в вашем приложении для работы офлайн.
Для полного руководства по созданию рабочего примера читайте Использование Service Worker.
Другие варианты использования
Service worker’ы также предназначены для таких вещей, как:
В будущем service worker’ы будут способны на многие другие полезные вещи для веб-платформ, приближая их к нативным приложениям. Примечательно, что другие спецификации могут и будут использовать контекст service worker, к примеру для:
Интерфейс
SyncEvent представляет синхронное действие, которое отправляется ServiceWorkerGlobalScope (en-US) ServiceWorker.
SyncManager (en-US) Обеспечивает интерфейс регистрации и перечисления синхронных регистрации. WindowClient Представляет область видимости клиентского service worker’а, представленного в виде документа в контакте браузера, контролируемого активным воркером. Это особый тип объекта Client (en-US) с некоторыми дополнительными методами и свойствами.
Спецификации (характеристики)
| Спецификации | Статус | Комментарий |
|---|---|---|
| Service Workers | Рабочий черновик | Изначальное определение. |