Что такое service workers для чайников

Кто ты такой, 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 Workers

Предисловие

Сервис-воркеры (Service Workers, да простят меня читатели) сегодня являются полезным дополнением к основной функциональности сайта: тут и работа в оффлайне, и фоновая синхронизация данных, и модные пуш-уведомления.

Однако большое количество статей про сервис-воркеры выглядят достаточно сжато и описывают простые примеры. Я попробую обратить внимание на некоторые особенности работы сервис-воркеров, так что требуются какие-то базовые знания. Отправной точкой может быть эта статья (перевод) или чуть более подробная статья.

Несколько сервис-воркеров на одном домене

У регистрации (registration) конкретного сервис-воркера есть такое понятие, как scope. Оно определяет, какие страницы на определённом домене будут подпадать под её контроль. При этом можно регистрировать несколько сервис-воркеров на одном домене, но с разными scope. Если попробовать зарегистрировать их с разными именами, но одним scope, то установленный позднее воркер будет «замещать» своего более раннего брата.

Кстати, для того, чтобы файл по указанному пути можно было установить в качестве сервис-воркера по пути выше (такое поведение запрещено по умолчанию, увеличивать путь можно, уменьшать — нет), то для этого можно использовать http-заголовок Service-Worker-Allowed.

Метод getRegistration() без параметров возвращает подходящую для текущей страницы регистрацию сервис-воркера, возможно, неактивную. Это также значит то, что по вложенному пути мы будем получать ту же самую регистрацию, если нет более подходящей. Это может приводить к неожиданностям, если ожидается работа нескольких сервис-воркеров на одном домене.

Рассмотрим пример: у нас есть установленный сервис-воркер со scope /. Пусть это будет новостной сайт и мы предоставляем оффлайновые версии текстов. Также есть панель управления по пути /admin/ со своим собственным сервис-воркером. Если второй сервис-воркер ещё не попытались установить, то getRegistaration() будет возвращать регистрацию первого сервис-воркера и это может приводить к ошибкам (например, мы будем слать нотификации из панели администратора в сервис-воркер, не готовый к ним вовсе).

getRegistration имеет опциональный параметр — scope. Если его указать, то метод вернёт регистрацию, наиболее подходящую (не обязательно равную) переданному scope. Тем самым мы можем отписываться от сервис-воркеров на вложенных страницах или получать вообще любые регистрации с текущего домена, нужно лишь знать подходящие scope.

А если мы не знаем все scope, то есть метод getRegistrations(), который просто возвращает все регистрации с текущего домена в виде массива. Требуется Firefox или Chrome 45+.

Связь между страницей и сервис-воркером

Возможность обмена данными между сервис-воркером и подчинённой страницей может привести довольно к оригинальным схемам работы. Например, можно сразу присылать данные из кеша, параллельно запрашивая новые; как только будут новые данные — положить их в кеш и прислать на страницу.

Пример на serviceworke.rs показывает простой способ общения с сервис-воркером:

Здесь controller — сервис-воркер, контролирующий страницу. В свежих браузерах (все версии Firefox и Chrome 51+) можно достаточно просто ответить на такой запрос:

В более старых версиях приходилось обходить все вкладки и находить нужную, а то и создавать руками MessageChannel. Также теперь у нас есть возможность отправлять сообщение вкладке из события fetch. Всё это описано в статье, разве что современное апи у нас уже есть.

Другой момент — хранение данных в сервис-воркере. Люди, уже опробовавшие сервис-воркеры, могли заметить, что LocalStorage там нет. Всё потому, что в сервис-воркерах был взят курс на полностью асинхронное апи (за исключением, пожалуй, importScripts). Но внутри всё ещё остаются доступны:

Или как-то так, но тогда нужно будет иметь в одном месте полный список возможных кешей.

Но при всём этом стоит помнить, что никто не гарантирует 100% сохранность данных в хранилищах. Браузер может автоматически чистить CacheStorage и indexedDB при нехватке места на диске, да и пользователь может сделать это сам.

Кроссдоменные запросы и прочее взаимодействие с другими доменами

С введением fetch ситуация могла показаться немного запутанной (там есть разные режимы запроса/ответа), а с сервис-воркерами всё становится в два раза сложнее: один fetch на стороне клиента, второй — на стороне сервис-воркера.

Самое простое понимание, к которому можно придти: «обмануть» CORS и получить доступ к контенту с другого домена без заголовков не получится. Важно разделять два вида использования: с доступом со стороны javascript и без него. Например, подменить одну картинку другой можно без проблем: достаточно указать в fetch сервис-воркера mode: ‘no-cors’ и не важно, какие там заголовки. Если не использовать ‘no-cors’, fetch будет ожидать CORS заголовки и в случае их отсутствия всё окончится ошибкой.

Если говорить более строго, то любой запрос (Request) со страницы имеет mode. Например, запрос картинки — ‘no-cors’, а запрос картинки с атрибутом crossOrigin (anonymous или use-credentials) — уже ‘cors’. Запросы через XMLHttpRequest всегда в режиме ‘cors’. А fetch позволяет задавать режим напрямую.

Ответ (Response) имеет свойство type. Запросы на текущий домен — ‘basic’. Иначе, если режим запроса — ‘cors’, то type ответа тоже будет ‘cors’, при наличии необходимых заголовков. Режим ответа ‘opaque’ можно получить на запрос в режиме ‘no-cors’, в нём нельзя получить доступ к каким-либо данным ответа.

Здесь описаны не все возможные виды режимов запросов, но этого должно быть достаточно для общего понимания. Больше информации можно почерпнуть из статьи с описанием fetch.

Теперь попробуем всё скомбинировать. Со страницы уходит запрос, его перехватывает сервис-воркер и делает свой fetch, получает ответ. До текущего момента ситуация разобрана, но теперь будет нюанс: при передаче ответа с типом ‘opaque’ в ответ на запрос страницы. который был сделан не с режимом ‘no-cors’, мы получим ошибку.

Помимо просто запросов, мы можем установить сервис-воркер на другой домен. Нет, мы не получим контроль за другой страницей через наш сервис-воркер — условия на сервис-воркер остаются теми же (сам скрипт должен быть на том же домене, на который регистрируется воркер). Для этого можно использовать iframe с нужного домена — разрешений от пользователя не требуется и iframe можно сделать просто невидимым.

Другая интересная возможность, которая сейчас находится в своей ранней версии — Foreign Fetch. Если обычный сервис-воркер контролирует запросы со страницы в своём scope (страница в scope, а не запросы), то foreign fetch позволяет контролировать запросы на свой домен. Допустим, обычное событие fetch будет срабатывать при запросе за библиотекой на CDN, а foreignFetch будет срабатывать при всех запросах за этой библиотекой на любых сайтах! Это любопытная возможность может быть использована, например, службами аналитики.

Тестирование

С написанием тестов на сервис-воркеры есть определённые сложности. Составление теста не так просто: если мы хотим проверить оффлайновый режим, то нужно как-то эмулиовать ошибки сети, если хотим проверить обновление — нужно подменять файл новым и тому подобное.

Дополнительные проблемы также состоят в том, что в текущий момент «безголовые» браузеры не поддерживают сервис-воркеры, а значит, нужны настоящие.

Есть стоящая статья на тему тестирования сервис-воркеров. В ней есть ссылки и на пару инструментов: sw-unit-test-sample и platinum-sw (элемент для Polymer, в нём есть также пара тестов). В статье также описан интересный приём: создание ифрейма для того, чтобы он контролировался тестируемым сервис-воркером. Вообще говоря, у элементов iframe и object есть другая особенность: запросы за ними и их содержимым идут в обход текущего сервис-воркера страницы, используя собственные сервис-воркеры.

То, что caches доступно на самой странице, может быть полезно при тестировании для очистки и проверки содержимого кеша.

Важный нюанс при работе автотестов — определение момента, когда сервис-воркер контролирует страницу и может перехватывать запросы. Простой navigator.serviceWorker.ready не всегда является верным решением — ready срабатывает в момент активации сервис воркера, но до того, как закончится выполнение clients.claim(). Более подробно описано здесь, как одно из решений — слушать событие controllerchange.

Обновление сервис-воркера

Есть несколько нюансов при обновлении сервис-воркеров, на которые стоит обратить внимание.

Несмотря на поддержку кеширующих заголовков при запросе скрипта сервис-воркера, браузеры уменьшают время жизни кеша до 24 часов. Сделано это для того, чтобы случайно не оставить сайт у пользователя в убитом состоянии на большой промежуток времени. Вот хороший ответ на StackOverflow про кеширование.

Другой нюанс: обновление срабатывает, только если сам скрипт сервис-воркера обновился, и определение этого происходит побайтово. Из этого следует, что обновление файлов, которые подключены через importScripts, не приведёт к обновлению самого сервис-воркера.

При обновлении часто добавляются в кеш из сети какие-то файлы. Но при этом работает браузерный кеш! Как и при вызовах fetch внутри сервис-воркера. Нужно либо быть уверенным, что файлы не поменялись (например, включать версию/хеш в название файла), либо загружать ресурсы в обход кеша. Чтобы загружать ресурсы в обход кеша, можно или руками звать fetch и потом добавлять ответ в кеш (не забывая проверять response.ok, например), или использовать опцию cache: ‘no-cache’ Request’а (пока работает только в Firefox Nightly). И то и то описано в статье Jake Archibald.

Также стоит упомянуть, что запрос за скриптом сервис-воркера при обновлении идёт в обход обработчика события fetch текущего сервис-воркера.

Источник

Service Workers

В этой статье я хотел бы поговорить о Service Workers (SW). SW позволяют нам сделать наше приложение готовым к работе в автономном режиме, чтобы оно работало, даже если у нас нет подключения к Интернету. Они также позволяют нам использовать множество других расширенных функций, таких как push-уведомления или фоновая синхронизация. SW продолжает работать даже после закрытия браузера, то есть Service Workers продолжают работать. Это фоновый процесс. Итак, давайте зарегистрируем нашего первого Service Worker’a.

(В этой статье я реализую функциональность, связанную с SW, на простом JS, поскольку код написан на простом JS, мы можем интегрировать в любые JS-фреймворки, такие как Angular, React или Vue)

В качестве первого шага добавим файл sw.js в корневую папку проекта. В app.js мы должны проверить, доступен ли SW в навигаторе, то есть поддерживаются ли SW данным браузером. Теперь, когда мы знаем, что SW доступны, мы можем выполнить метод navigator.serviceWorker.register (), указывая путь к файлу, в котором находится наш SW, чтобы его зарегистрировать. Этот метод фактически возвращает Promise. Итак, чтобы получить информацию, как только это будет сделано, мы можем присоединиться к нему.

Поскольку мы зарегистрировали нашего первого SW, давайте добавим наш первый прослушиватель событий. Как я уже сказал, SW работают в фоновом режиме. Но я не упомянул одну вещь, что все они связаны с обработкой событий. Чтобы прикрепить слушателей событий к SW, мы, прежде всего, должны обратиться к нему с помощью ключевого слова self, что в основном означает «предоставь мне доступ к SW», а затем мы можем выполнить метод addEventListener (). SW надают доступ к специальному набору событий, например, к событию установки, которое запускается, когда браузер устанавливает Service Worker’a. Здесь мы выполняем функцию и получаем объект события, который автоматически передается в функцию браузером, и этот объект предоставляет нам информацию о событии установки. Как мы видим, наш Service Worker успешно установлен.

Теперь посмотрим, действительно ли эти файлы загружены в кеш-память.

Выражение event.respondWith () позволяет нам перезаписывать данные, которые отправляются обратно. Вы можете думать о Service Worker’е как о сетевом прокси, по крайней мере, если мы используем здесь событие fetch. Таким образом, каждый исходящий запрос на выборку проходит через Service Worker, как и каждый ответ. То есть, если мы ничего не делаем, ответ просто не передается. Выражение cashes.match () позволяет нам проверить, кэширован ли уже данный запрос. Если это так, он вернет кешированный ответ. Мы не делаем сетевой запрос, мы перехватываем запрос и не выдаем новый, вместо этого мы просто смотрим на то, что мы хотели запросить, и видим, есть ли оно в кеше и если есть, мы возвращаем его обратно. С другой стороны, если мы не находим его в кеше, мы хотим вернуть запрос на выборку там, где мы обращаемся или где мы просто продолжаем исходный запрос, поэтому вертаем fetch (event.request). После всех этих изменений мы наконец можем использовать наше веб-приложение в автономном режиме.

Как видите, наше веб-приложение содержит диаграмму с некоторыми статическими данными, и при нажатии кнопки «ПОЛУЧИТЬ ДАННЫЕ» ничего не происходит. Теперь я хочу сделать так, чтобы нажав эту кнопку, мы получили некоторые статистические данные, отобразили их на диаграмме и сохранили эти данные в кеше. Таким образом, мы реализуем динамическое кеширование. Итак, приступим. Допустим, у нас есть эндпоинт, который возвращает статистические данные о том, сколько пользователей посетили наш сайт. Итак, теперь мы должны взять эти данные и отобразить их на графике.

Как и раньше, я добавлю решение, а затем объясню, как оно работает.

Сначала нам нужно проверить тег события. Затем я использую event.waitUntil (), как и раньше, это просто позволяет мне убедиться, что событие не завершилось преждевременно. Затем мы получаем данные, которые хранятся в indexedDB (используя вспомогательную функцию из utility.js), перебираем их, отправляем post запрос для каждого из сохраняемых фрагментов данных, а затем удаляем их из indexedDB, если мы успешно отправили их на сервер. Вот и все. Давайте теперь попробуем это. Чтобы проверить эту функциональность, мы должны перейти в автономный режим в нашем браузере, нажать кнопку «POST DATA» и затем снова выйти в онлайн.

После нажатия кнопки «POST DATA», когда мы не в сети, ничего не происходит, но когда подключение восстанавливается, мы видим, что синхронизация была выполнена.

И чтобы подтвердить, что данные действительно были отправлены на сервер, нам сначала нужно удалить наш запрос на получение из динамического кеша и нажать кнопку «ПОЛУЧИТЬ ДАННЫЕ».

Источник

Что такое сервис-воркеры и как они помогают повысить производительность

Сервис-воркеры позволяют разработчикам эффективнее управлять кэшированием ресурсов, чтобы пользователи могли продолжать использовать приложение даже при разрыве интернет-соединения. В этой статье разберем, как сервис-воркер может вывести производительность на новый уровень.

Что такое сервис-воркеры

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-уведомлений, что особенно полезно в мобильных приложения. В будущем сервис-воркеры смогут делать еще много полезных вещей, например, осуществлять геозонирование. Другими словами, пора начинать экспериментировать с воркерами, потому что в ближайшее время они точно не исчезнут.

Источник