Визуализация работы сервис-воркеров
Доброго времени суток, друзья!
Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры (Service Workers), которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).
Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»
В данной статье мы рассмотрим несколько практических примеров использования сервис-воркеров, что впоследствии, смею надеяться, сделает счастливыми ваших пользователей.
Полагаю, прежде чем разбирать практические примеры, необходимо хотя бы в общих чертах рассмотреть теоретические основы работы сервис-воркеров. Для начинающих разработчиков это послужит хорошим подспорьем в дальнейших начинаниях.
Что есть сервис-воркер?
Серсис воркер — это скрипт, запускаемый браузером в фоновом процессе. Помните, что сервис-воркер совершенно не зависит от страницы, с которой он взаимодействует или которой он служит (to serve — служить).
По сути, сервис-воркер представляет собой прокси сервер между веб-приложением, браузером и сетью.
Сервис-воркеры позволяют веб-приложениям работать подобно нативным приложениям.
Несколько фактов о сервис-воркерах
Как сервис-воркеры работают? Беглый взгляд
Сервис-воркеры позволяют перехватывать запросы к серверу и кешировать эти запросы с целью повышения производительности приложений. Таким образом, повышение производительности обеспечивается благодаря кешированию всего контента.
Но лучше один раз увидеть, так что вот вам изображение, показывающее работу сервис-воркера:
Жизненный цикл сервис-воркера
Как я упоминал ранее, сервис-воркеры работают независимо от управляющей страницы. Если вы хотите установить сервис-воркер в своем приложении, первым делом нужно его зарегистрировать.
После этого браузер, запустивший установку сервис-воркера, переходит в фоновый режим:
Самые распространенные случаи использования
Теперь, когда мы знаем, как работают сервис-воркеры, настало время поговорить о том, где они используются.
Кеширование
Как отмечалось выше, сервис-воркеры могут использоваться для кеширования. Вот некоторые примеры:
Веб-пуш (Web Push)
Веб-пуш позволяет приложениям отправлять пуш-уведомления и отображать контент, получаемый в ответ на эти уведомления.
Более сложные примеры использования
API аналитики
У меня есть приложение. И я хочу добавить в него возможность следить за использованием приложения. Для этого я беру синхронное API для обновления собранных данных время от времени.
Балансировщик загрузки
Допустим, вы хотите иметь возможность выбирать лучшего провайдера контента, опираясь на показатели работы сервера. В этом случае вам нужен сервис-воркер для перехвата запросов и осуществления выбора.
Я настоятельно рекомендую вам посетить ServiceWorke.rs для более подробного изучения сервис-воркеров.
Отрабатываем навыки
Как я всегда говорю: «Хочешь научиться плавать — лезь в воду». Изучение теории — вещь замечательная, но пока не испачкаешь руки, ничему не научишься.
Регистрация сервис-воркера
Если мы вновь обратимся к иллюстрации жизненного цикла сервис-воркера, то увидим, что перво-наперво нам необходимо его установить. Чтобы это сделать нам нужно его зарегистрировать.
В работе сервис-воркера можно убедиться, перейдя по адресу: Chrome://inspect/#service-workers.
Что дальше?
Теперь нам нужно закешировать все файлы. Мы можем выбирать файлы для кеширования. Вот как это выглядит:
Вот что здесь происходит:
Удаляем неиспользуемый кеш
Далее нам необходимо удалить старые версии кеша:
Получение ответа
Ничто из приведенного выше не имеет смысла, если у нас нет возможности получить закешированный контент.
Его можно получить с помощью обработчика события «fetch»:
Как работает JS: веб-воркеры и пять сценариев их использования
Публикуем перевод седьмой части часть серии материалов об особенностях работы различных механизмов JavaScript. Наша сегодняшняя тема — веб-воркеры. В частности, речь пойдёт о различных типах веб-воркеров, о том, как организована совместная работа тех частей, из которых они состоят, а также об их возможностях и об ограничениях, с которыми можно столкнуться в разных сценариях их использования. Здесь же будет показано 5 вариантов практического применения веб-воркеров.
Ограничения асинхронного программирования
Прежде чем мы начнём говорить о веб-воркерах, стоит вспомнить о том, что JavaScript — это однопоточный язык, однако, он поддерживает и возможности асинхронного выполнения кода.
Асинхронному программированию и вариантам его применения в JS-проектах был посвящён один из предыдущих материалов этой серии.
Асинхронное выполнение кода позволяет пользовательскому интерфейсу веб-приложений нормально функционировать, реагировать на команды пользователя. Система «планирует» нагрузку на цикл событий таким образом, чтобы в первую очередь выполнялись операции, связанные с пользовательским интерфейсом.
Хороший пример использования асинхронных методов программирования демонстрирует техника выполнения AJAX-запросов. Так как ожидание ответа способно занять много времени, запросы можно делать асинхронно, при этом, пока клиент ожидает ответа, может выполняться код, не относящийся к запросу.
Такой подход, однако, демонстрирует следующую проблему: запросы обрабатываются WEB API браузера. Нас же интересует возможность асинхронного выполнения произвольного кода. Скажем, как быть, если код внутри функции обратного вызова интенсивно использует ресурсы процессора?
Если функция performCPUIntensiveCalculation — это не нечто вроде асинхронно выполняемого HTTP-запроса, а код, блокирующий главный поток (скажем, огромный и тяжёлый цикл for ), то при однопоточном подходе к JS-разработке у нас нет способа освободить цикл событий и разблокировать интерфейс браузера. Как результат, пользователь не сможет с ним нормально работать.
Это означает, что асинхронные функции смягчают лишь небольшую часть ограничений, связанных с однопоточностью JS.
Взглянем на простую функцию, которая вычисляет среднее значение для числового массива.
Этот код можно переписать так, чтобы он «эмулировал» асинхронное выполнение:
Веб-воркеры
HTML5 дал нам множество замечательных возможностей, среди которых можно отметить следующие:
Это поистине замечательная возможность. Система понятий JavaScript основана на идее однопоточного окружения, а теперь перед нами технология, которая (частично) снимает это ограничение.
Веб-воркеры позволяют разработчику размещать задачи, для выполнения которых требуются длительные и сложные вычисления, интенсивно задействующие процессор, в фоновых потоках, без блокировки пользовательского интерфейса, что позволяет приложениям оперативно реагировать на воздействия пользователя. Более того, нам больше не нужны обходные пути, вроде рассмотренного выше трюка с setTimeout для того, чтобы найти приемлемый способ взаимодействия с циклом событий.
Вот простой пример, который демонстрирует разницу между сортировкой массива с помощью веб-воркера и без него.
▍Обзор веб-воркеров
Веб-воркеры позволяют выполнять тяжёлые в вычислительном плане и длительные задачи без блокировки потока пользовательского интерфейса. На самом деле, при их использовании вычисления выполняются параллельно. Перед нами настоящая многопоточность.
Возможно, вы вспомните о том, что JavaScript — это однопоточный язык программирования. Пожалуй, тут вы должны осознать, что JS — это язык, который не определяет модель потоков. Веб-воркеры не являются частью JavaScript. Они представляют собой возможность браузера, к которой можно получить доступ посредством JavaScript. Большинство браузеров исторически были однопоточными (эта ситуация, конечно, изменилась), и большинство реализаций JavaScript создано для браузеров.
Веб-воркеры не реализованы в Node.js — там есть концепция «кластеров» или «дочерних процессов», а это уже немного другое.
Стоит отметить, что спецификация упоминает три типа веб-воркеров:
▍Выделенные воркеры
Экземпляры выделенных веб-воркеров создаются главным процессом. Обмениваться данными с ними может только он.
Поддержка выделенных воркеров в браузерах
▍Разделяемые воркеры
Поддержка разделяемых воркеров в браузерах
▍Сервис-воркеры
Сервис-воркеры — это воркеры, управляемые событиями, зарегистрированные с использованием источника их происхождения и пути. Они могут контролировать веб-страницу, с которой связаны, перехватывая и модифицируя команды навигации и запросы ресурсов, и выполняя кэширование данных, которым можно очень точно управлять. Всё это даёт нам отличные средства управления поведением приложения в определённой ситуации (например, когда сеть недоступна).
Поддержка сервис-воркеров в браузерах
Надо отметить, что в этом материале мы будем заниматься выделенными воркерами, именно их мы будем иметь в виду, говоря о «веб-воркерах» или о «воркерах».
Как работают веб-воркеры
Воркеры используют механизмы передачи сообщений, характерные для технологий, которые применяются для организации взаимодействия потоков, что позволяет организовать их параллельное выполнение. Они отлично подходят для того, чтобы выполнять тяжёлые вычислительные операции, не замедляя работу пользовательского интерфейса.
Веб-воркеры выполняются в изолированных потоках в браузере. Как результат, код, который они выполняют, должен быть включён в отдельный файл. Это важно запомнить.
Вот как создают веб-воркеры:
Если файл task.js существует и к нему есть доступ, браузер создаст новый поток, который асинхронно загрузит этот файл. После того, как загрузка будет завершена, начнётся выполнение кода воркера. Если при попытке загрузки файла браузер получит сообщение об ошибке 404, файл загружен не будет, при этом сообщения об ошибках не выводятся.
Для запуска только что созданного воркера нужно вызвать его метод postMessage :
Обмен данными с веб-воркером
▍Метод postMessage
Посмотрим на пример того, как страница, создавшая воркер, может обмениваться с ним данными, используя JSON-объект. При передаче строки выглядит всё практически точно так же.
Вот часть HTML-страницы:
Вот содержимое файла с кодом воркера:
Когда воркер получает сообщение и понимает, чего от него хотят, он будет выполнять вычисления самостоятельно, не блокируя цикл событий. То, чем занимается воркер, выглядит как стандартная JS-функция. Когда вычисления завершены, их результаты передаются главной странице.
▍Широковещательный канал передачи данных
Объект BroadcastChannel представляет собой более универсальное API для передачи данных. Он позволяет передавать сообщения, которые можно принять во всех контекстах, имеющих один и тот же источник. Все вкладки браузера, iframe или воркеры, относящиеся к одному источнику, могут передавать и принимать широковещательные сообщения:
Вот как выглядит схема взаимодействия различных сущностей с использованием широковещательного канала обмена сообщениями:
Обмен данными с использованием широковещательного канала передачи сообщений
Однако тут стоит отметить, что объект BroadcastChannel пока имеет довольно ограниченную поддержку в браузерах.
Поддержка BroadcastChannel в браузерах
Способы отправки сообщений веб-воркерам
Есть два способа отправки сообщений веб-воркерам. Первый заключается в копировании данных, второй — в передаче данных от источника к приёмнику без их копирования. Рассмотрим эти способы работы с сообщениями:
Возможности, доступные веб-воркерам
Веб-воркерам, из-за их многопоточной сущности, доступен лишь ограниченный набор возможностей JavaScript. Вот эти возможности:
Ограничения веб-воркеров
К сожалению, у веб-воркеров нет доступа к некоторым весьма важным возможностям JavaScript. Среди них следующие:
Обработка ошибок
Сценарии использования веб-воркеров
Мы рассказали о сильных и слабых сторонах веб-воркеров. Теперь рассмотрим несколько сценариев их использования.
Итоги
В этом материале мы рассказали о веб-воркерах — сравнительно новой возможности, доступной веб-разработчикам в большинстве современных браузеров. Веб-воркеры позволяют выносить в отдельные потоки выполнение ресурсоёмких операций, что позволяет не нагружать главный поток, который может спокойно обрабатывать всё, что связано с пользовательским интерфейсом.
Предыдущие части цикла статей:
Уважаемые читатели! Используете ли вы веб-воркеры в своих проектах?
Использование Web Workers
Web Worker-ы предоставляют простое средство для запуска скриптов в фоновом потоке. Поток Worker’а может выполнять задачи без вмешательства в пользовательский интерфейс. К тому же, они могут осуществлять ввод/вывод, используя XMLHttpRequest (хотя атрибуты responseXML и channel всегда будут равны null). Существующий Worker может отсылать сообщения JavaScript коду-создателю через обработчик событий, указанный этим кодом (и наоборот). Эта статья даёт детальную инструкцию по использованию Web Workers.
Web Workers API
Контекст Worker’а представлен объектом DedicatedWorkerGlobalScope (en-US) в случае выделенных Workers (обычные Workers используются одним скриптом; совместные Workers используют объект SharedWorkerGlobalScope (en-US) ). Выделенный Worker доступен только из скрипта-родителя, в то время как совместные Workers могут быть доступны из нескольких сценариев.
Примечание: Смотрите страницу Web Workers API для справки по Workers и прочие руководства.
Данные передаются между worker-ами и главным потоком через систему сообщений — обе стороны передают свои сообщения, используя метод postMessage() и отвечают на сообщения при помощи обработчика событий onmessage (сообщение хранится в атрибуте data события Message ). Данные при этом копируются, а не делятся.
Выделенные Workers
Как уже упоминалось выше, выделенный Worker доступен только для скрипта, который его вызвал. В этом разделе речь пойдёт о JavaScript, который можно найти в нашем основном примере выделенного Worker (запустить скрипт): этот пример позволяет ввести два числа для умножения. Эти числа отправляются в Worker, перемножаются, а результат возвращается на страницу и отображается.
Этот пример достаточно тривиален, но для ознакомления с базовыми концепциями worker-ов мы решили его упростить. Более продвинутые детали описаны далее в статье.
Определение поддержки Worker
Для большего контроля над ошибками и обратной совместимости, рекомендуется обернуть ваш код доступа к worker-у в следующий (main.js):
Создание выделенного worker
Передача сообщений в и из выделенного worker
В приведённом фрагменте кода мы имеем два элемента, представленных переменными first и second ; когда значение любой из переменных изменяется, myWorker.postMessage([first.value,second.value]) используется для отправки обоих значений, представленных в виде массива, в worker. Посредством аргумента message возможна передача практически любых данных в worker.
Внутри worker-a мы можем обрабатывать сообщения и отвечать на них при помощи добавления обработчика события onmessage подобным образом (worker.js):
Возвращаясь в основной поток, мы используем onmessage снова, чтобы отреагировать на сообщение, отправленное нам назад из worker-а:
В примере выше мы берём данные из события сообщения и ставим их как textContent у результирующего абзаца, чтобы показать пользователю результат этой калькуляции.
Примечание: Обратите внимание, что onmessage() и postmessage() должны вызываться из экземпляра Worker в главном потоке, но не в потоке worker-а. Это связано с тем, что внутри потока worker-а, worker выступает в качестве глобального объекта.
Примечание: При передаче сообщения между основным потоком и потоком worker-а, оно копируется или «передаётся» (перемещается), не делится между потоками. Читайте Transferring data to and from workers: further details для более подробного объяснения.
Завершение работы worker-а
Прекращение работы worker-а главного потока достигается методом terminate :
Поток worker-а немедленно уничтожается.
Обработка ошибок
Событие не всплывает и его можно отменить. Для отмены действия по умолчанию, worker может вызвать метод preventDefault() в обработчике события ошибки.
У события ошибки есть три поля, которые представляют интерес:
message Сообщение об ошибке в читаемом виде. filename Имя файла со скриптом, в котором ошибка произошла. lineno Номер строки в файле, в котором произошла ошибка.
Создание subworkers
Worker-ы могут запускать другие worker-ы. Так называемые sub-worker’ы должны быть того же происхождения (same-origin), что и родительский документ. Кроме того, URI для subworker-ов рассчитываются относительно родительского worker’а, а не родительского документа. Это позволяет worker-ам проще следить за тем, где находятся их зависимости.
Импорт скриптов и библиотек
Разделяемые worker-ы (Shared workers)
Разделяемый worker доступен нескольким разным скриптам — даже если они находятся в разных окнах, фреймах или даже worker-ах. В этом разделе мы обсудим JavaScript, который можно найти в нашем базовом примере разделяемых worker-ов (запустить разделяемый worker): Он очень похож на базовый пример выделенных worker-ов, за исключением двух функций, которые доступны из разных скриптовых файлов: умножение двух чисел или возведение числа в степень. Оба скрипта используют один и тот же worker для необходимых вычислений.
Здесь мы сосредоточимся на разнице между выделенными и разделёнными worker-ами. Обратите внимание, что в данном примере есть две HTML страницы с JavaScript-кодом, которые используют один и тот же файл worker-а.
Примечание: Если разделяемый worker может быть доступен из нескольких контекстов просмотра, то все они должны иметь одно и то же происхождение (одни и те же протокол, хост и порт).
Примечание: В Firefox разделяемый worker не может быть использован совместно документами в приватном и неприватном окне (баг 1177621).
Создание разделяемого worker-а
Запуск разделяемого worker-а очень похож на запуск выделенного worker-а, но используется другой конструктор (см. index.html и index2.html) — в каждом документе необходимо поднять worker, для этого следует написать такой код:
Большая разница заключается в том, что с разделяемым worker-ом необходимо взаимодействовать через объект port — явно открыв порт, с помощью которого скрипты могут взаимодействовать с worker-ом (в случае выделенного worker-а это происходит неявно).
Примечание: Когда используется метод start() чтобы открыть соединение с портом, его необходимо вызывать и в родительском потоке и в потоке worker-а, если необходима двухсторонняя коммуникация.
Передача сообщений в/из разделяемого worker-а
Теперь сообщения могут быть отправлены worker-у, как и прежде, но метод postMessage() должен вызываться из объекта port (ещё раз, вы можете увидеть схожие конструкции в multiply.js и square.js):
Теперь на стороне worker-а. Здесь код немного сложнее (worker.js):
Второй этап — это обработчик события message на сохранённом порту. Он нужен для подсчёта и вывода результата вычисления в основной поток. Установка обработчика message в потоке worker-а также открывает подключение к родительскому потоку, поэтому вызов на port.start() на самом деле не нужен (см. код обработчика onconnect ).
Последний этап — возвращение в основной поток и обработка сообщения от worker‑а (ещё раз, вы можете увидеть схожие конструкции в multiply.js и square.js):
Когда сообщение приходит через порт от worker-а, мы проверяем тип результата вычислений и затем вставляем его в соответствующий абзац.
О потоковой безопасности
Интерфейс Worker создаёт настоящие потоки на уровне операционной системы, что может смутить опытных программистов и навести их на мысли о проблемах, связанных с конфликтом доступа к общим объектам.
На самом деле создать такие проблемы достаточно сложно, так как worker-ы жёстко контролируются. У них нет доступа к непотокобезопасным объектам DOM, а все данные между потоками передаются в качестве сериализованных объектов. Придётся очень постараться, чтобы вызывать проблемы потокобезопасности в вашем коде.
Передача данных в и из worker-ов: другие детали
Передача данных между главной страницей и worker-ом происходит путём копирования, а не передачи по ссылке. Объекты сериализуются при передаче и затем десериализуются на другом конце. Страница и worker не используют совместно одни и те же экземпляры, для каждого создаётся свой. Большинство браузеров реализуют это структурированным клонированием (structured cloning).
example.html: (главная страница):
my_task.js (worker):
Алгоритм структурированного клонирования может принять JSON и некоторые вещи, которые JSON не может принять, например, циклические ссылки.
Примеры передачи данных
Пример #1: Расширенная передача JSON данных и создание системы коммутации
Если вам нужно передать сложные данные и вызвать множество различных функций как на главной странице, так и в worker-е, вы можете создать следующую систему.
В первую очередь мы создаём класс QueryableWorker, который принимает url worker-а, стандартный обработчик событий (defaultListener) и обработчик ошибок. Этот класс будет отслеживать всех обработчиков и поможет нам общаться с воркером.
Затем мы добавляем методы добавления/удаления обработчиков.
Здесь мы создадим у worker-а два простых события для примера: получение разницы двух чисел и создание оповещения через три секунды. Но сначала нам нужно реализовать метод sendQuery, который проверит есть ли вообще у worker-а обработчик, который мы собираемся вызвать.
Теперь к самому worker-у. Сначала следует определить эти два простых метода:
Полный код примера:
example.html (основная страница):
my_task.js (код worker-а):
Передача данных с помощью передачи владения (передаваемые объекты)
Google Chrome 17+ and Firefox 18+ имеют дополнительную возможность передачи определённых типов объектов (передаваемые объекты реализующие Transferable интерфейс) к или из worker-а с высокой производительностью. Эти объекты передаются из одного контекста в другой без операций копирования, что приводит к значительному повышению производительности при отправке больших наборов данных. Думайте об этом как о передаче по ссылке в мире C/C++. Однако в отличии от передачи по ссылке, «версия» из вызывающего контекста больше недоступна после передачи. Владельцем становится новый контекст. Для примера, после передачи ArrayBuffer из главной страницы к worker-у, исходный ArrayBuffer очищается и более недоступен для использования. Его содержание (в буквальном смысле) переносится в рабочий контекст.
Примечание: Для дополнительной информации о передаваемых объектах, производительности и поддержки для этого метода, читайте Transferable Objects: Lightning Fast! на HTML5 Rocks.
Встроенные worker-ы
Не существует утверждённого способа встроить код worker-а в рамках веб-страницы, как элемент
Что такое сервис-воркеры и как они помогают повысить производительность
Сервис-воркеры позволяют разработчикам эффективнее управлять кэшированием ресурсов, чтобы пользователи могли продолжать использовать приложение даже при разрыве интернет-соединения. В этой статье разберем, как сервис-воркер может вывести производительность на новый уровень.
Что такое сервис-воркеры
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-уведомлений, что особенно полезно в мобильных приложения. В будущем сервис-воркеры смогут делать еще много полезных вещей, например, осуществлять геозонирование. Другими словами, пора начинать экспериментировать с воркерами, потому что в ближайшее время они точно не исчезнут.