Это 8-й пост из серии, посвященной изучению JavaScript и его компонентов. В процессе определения и описания основных элементов мы также делимся некоторыми передовыми практиками, которые мы используем при создании SessionStack, приложения JavaScript, которое должно быть надежным и высокопроизводительным, чтобы точно в реальном времени показывать вам, как работают ваши пользователи. в техническую проблему или проблему UX в вашем веб-приложении.

Если вы пропустили предыдущие главы, вы можете найти их здесь:

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

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

В этом посте мы подробно рассмотрим сервис-воркеров: как они работают и о чем вам следует заботиться. В конце мы также перечисляем несколько уникальных преимуществ Service Workers, которыми вы должны воспользоваться, и делимся опытом нашей собственной команды здесь, в SessionStack.

Обзор

Если вы хотите понять все о Service Workers, вам следует начать с чтения нашего сообщения в блоге Web Workers.

По сути, Service Worker - это тип Web Worker, а точнее, Shared Worker:

  • Service Worker работает в собственном глобальном контексте сценария.
  • Он не привязан к определенной веб-странице
  • Он не может получить доступ к DOM

Одна из основных причин, по которой Service Worker API так интересен, заключается в том, что он позволяет вашим веб-приложениям поддерживать работу в автономном режиме, предоставляя разработчикам полный контроль над потоком.

Жизненный цикл обслуживающего работника

Жизненный цикл сервис-воркера полностью отделен от жизненного цикла вашей веб-страницы. Он состоит из следующих этапов:

  • Скачать
  • Установка
  • Активация

Скачать

Это когда браузер загружает .js файл, содержащий Service Worker.

Установка

Чтобы установить Service Worker для вашего веб-приложения, вы должны сначала зарегистрировать его, что вы можете сделать в своем коде JavaScript. Когда Service Worker зарегистрирован, он предлагает браузеру запустить шаг установки Service Worker в фоновом режиме.

Регистрируя Service Worker, вы сообщаете браузеру, где находится ваш JavaScript-файл Service Worker. Давайте посмотрим на следующий код:

Код проверяет, поддерживается ли Service Worker API в текущей среде. Если это так, /sw.js Service Worker зарегистрирован.

Вы можете без проблем вызывать метод register() каждый раз при загрузке страницы - браузер определит, был ли уже зарегистрирован сервисный воркер, и обработает его должным образом.

Важной деталью метода register() является расположение файла сервис-воркера. В этом случае вы можете видеть, что файл сервис-воркера находится в корне домена. Это означает, что сфера действия сервис-воркера будет всем источником. Другими словами, этот сервис-воркер будет получать fetch событий (о которых мы поговорим позже) для всего в этом домене. Если мы зарегистрируем файл сервис-воркера в /example/sw.js, тогда сервис-воркер будет видеть только fetch события для страниц, URL-адреса которых начинаются с /example/ (т. Е. /example/page1/, /example/page2/).

На этапе установки лучше всего загрузить и кэшировать некоторые статические ресурсы. После успешного кэширования ресурсов установка Service Worker будет завершена. Если нет (загрузка не удалась) - Service Worker выполнит повторную попытку. После успешной установки вы будете знать, что статические ресурсы находятся в кеше.

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

Почему так? Рассмотрим первое посещение пользователем вашего веб-приложения. Пока нет сервис-воркера, и браузер не может заранее узнать, будет ли сервис-воркер, который в конечном итоге будет установлен. Если Service Worker будет установлен, браузеру потребуется потратить дополнительный процессор и память для этого дополнительного потока, которые в противном случае браузер будет тратить на визуализацию веб-страницы.

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

Учтите, что это важно только для первого посещения страницы. Установка Service Worker не влияет на последующие посещения страницы. После активации Service Worker при первом посещении страницы он может обрабатывать события загрузки / кеширования для последующих посещений вашего веб-приложения. Все это имеет смысл, потому что он должен быть готов к работе с ограниченным сетевым подключением.

Активация

После установки Service Worker следующим шагом будет его активация. Этот шаг - прекрасная возможность управлять предыдущими кешами.

После активации Service Worker начнет контролировать все страницы, которые подпадают под его действие. Интересный факт: страница, на которой зарегистрирован Service Worker впервые, не будет контролироваться, пока эта страница не загрузится снова. Как только Service Worker перейдет под контроль, он будет в одном из следующих состояний:

  • Он будет обрабатывать события выборки и сообщения, которые происходят, когда сетевой запрос или сообщение отправляются со страницы.
  • Он будет прекращен для экономии памяти

Вот как будет выглядеть жизненный цикл:

Обработка установки внутри Service Worker

После того, как страница запустит процесс регистрации, давайте посмотрим, что происходит внутри сценария Service Worker, который обрабатывает событие install, добавляя прослушиватель событий к экземпляру Service Worker.

Вот шаги, которые необходимо предпринять при обработке события install:

  • Открыть кеш
  • Кешируйте наши файлы
  • Убедитесь, что все необходимые ресурсы кэшированы

Вот как может выглядеть простая установка внутри Service Worker:

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

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

Кеширование запросов во время выполнения

Эта часть настоящая. Здесь вы увидите, как перехватывать запросы и возвращать созданные кеши (и создавать новые).

После того, как Service Worker установлен и пользователь перейдет на другую страницу или обновит страницу, на которой он находится, Service Worker получит события выборки. Вот пример, демонстрирующий, как вернуть кэшированные активы или выполнить новый запрос, а затем кэшировать результат:

Вот что вкратце происходит:

  • event.respondWith() определит, как мы будем реагировать на fetch событие. Мы передаем обещание от caches.match(), которое просматривает запрос и определяет, есть ли какие-либо кешированные результаты из любого из созданных кешей.
  • Если есть кеш, будет получен ответ.
  • В противном случае будет выполнено fetch.
  • Проверьте, имеет ли статус 200. Мы также проверяем, является ли тип ответа базовым, что указывает на то, что это запрос от нашего источника. Запросы к сторонним ресурсам в этом случае не кэшируются.
  • Ответ добавлен в кеш.

Запросы и ответы нужно клонировать, потому что они потоки. Тело потока можно съесть только один раз. И поскольку мы хотим их потреблять, мы хотим их клонировать, потому что браузер тоже должен их потреблять.

Обновление Service Worker

Когда пользователь посещает ваше веб-приложение, браузер пытается повторно загрузить .js файл, содержащий ваш код Service Worker. Это происходит в фоновом режиме.

Если в загруженном сейчас файле Service Worker есть хотя бы одно байтовое различие по сравнению с текущим файлом Service Worker, браузер предположит, что произошли изменения и нужно запустить нового Service Worker.

Новый Service Worker будет запущен, и будет запущено событие установки. Однако на этом этапе старый Service Worker все еще контролирует страницы вашего веб-приложения, а это означает, что новый Service Worker перейдет в состояние waiting.

Как только открытые в данный момент страницы вашего веб-приложения будут закрыты, старый Service Worker будет убит браузером, а новый Service Worker получит полный контроль. Именно тогда будет запущено его событие активации.

Зачем все это нужно? Чтобы избежать проблемы одновременного запуска двух версий веб-приложения на разных вкладках - что на самом деле очень распространено в Интернете и может создавать действительно плохие ошибки (например, в случаях, когда у вас другая схема при локальном хранении данных в браузере ).

Удаление данных из кеша

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

Вот пример того, как вы можете удалить некоторые файлы из кеша, которые не внесены в белый список (в данном случае, имея page-1 или page-2 под своими именами):

Требование HTTPS

Когда вы создаете свое веб-приложение, вы сможете использовать Service Workers через localhost, но как только вы развернете его в производственной среде, вам понадобится готовый HTTPS (и это последняя причина, по которой вы используете HTTPS).

Используя Service Worker, вы можете перехватывать соединения и подделывать ответы. Если вы не используете HTTP, ваше веб-приложение становится уязвимым для атак злоумышленник посередине.

Для большей безопасности вам необходимо зарегистрировать Service Workers на страницах, обслуживаемых через HTTPS, чтобы вы знали, что Service Worker, получаемый браузером, не был изменен во время перемещения по сети.

Поддержка браузера

Браузерная поддержка Service Workers становится лучше:

Вы можете следить за прогрессом всех браузеров здесь - https://jakearchibald.github.io/isserviceworkerready/.

Сервисные работники открывают двери для замечательных функций

Некоторые уникальные функции, которые предоставляет Service Worker:

  • Push-уведомления - позволяют пользователям получать своевременные обновления из веб-приложений.
  • Фоновая синхронизация - позволяет отложить действия до тех пор, пока у пользователя не будет стабильного подключения. Таким образом, вы можете быть уверены, что все, что пользователь хочет отправить, действительно отправлено.
  • Периодическая синхронизация (в будущем) - API, который предоставляет функции для управления периодической фоновой синхронизацией.
  • Геозоны (в будущем) - вы можете определить параметры, также называемые геозонами, которые окружают интересующие области. Веб-приложение получает уведомление, когда устройство пересекает географическую зону, что позволяет вам предоставлять полезные возможности в зависимости от географии пользователя.

Каждый из них будет подробно обсуждаться в следующих статьях блога этой серии.

Мы постоянно работаем над тем, чтобы сделать UX SessionStack как можно более плавным, оптимизируя загрузку страниц и время отклика.

Когда вы воспроизводите сеанс пользователя в SessionStack (или смотрите его в режиме реального времени), интерфейс SessionStack будет постоянно извлекать данные с наших серверов, чтобы беспрепятственно создавать для вас опыт, подобный буферизации. Чтобы дать вам немного предыстории: как только вы интегрируете библиотеку SessionStack в свое веб-приложение, оно будет непрерывно собирать данные, такие как изменения DOM, взаимодействия пользователей, сетевые запросы, необработанные исключения и сообщения отладки.

Когда сеанс воспроизводится или транслируется в режиме реального времени, SessionStack обслуживает все данные, позволяя вам видеть все, что пользователь испытал в своем собственном браузере (как визуально, так и технически). Все это должно происходить очень быстро, поскольку мы не хотим заставлять пользователей ждать.

Поскольку данные извлекаются нашим интерфейсом, это отличное место, где Service Workers могут быть задействованы для обработки таких ситуаций, как перезагрузка нашего плеера и необходимость повторной потоковой передачи всего. Обработка медленных сетевых подключений также очень важна.

Есть бесплатный план, если вы хотите попробовать SessionStack.

Ресурсы