Улучшение опыта разработки сервисных работников

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

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

Исключения для местного развития

Как правило, API-интерфейсы сервис-воркеров доступны только на страницах, обслуживаемых через HTTPS, но из этого правила есть исключения, когда они могут быть доступны через HTTP. Одним заметным исключением являются страницы, обслуживаемые через localhost , что хорошо подходит для локальной разработки.

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

Более удобный обходной путь — указать браузеру создавать исключения для тестирования Service Worker. В Chrome перейдите по адресу chrome://flags/#unsafely-treat-insecure-origin-as-secure и укажите небезопасные источники, которые следует рассматривать как безопасные. Firefox предлагает способ протестировать сервис-воркеров на небезопасных источниках с помощью параметра devtools.serviceWorkers.testing.enabled в about:config .

Средства разработки сервисных работников

Локальная разработка с участием сервисного работника может привести к, казалось бы, неожиданному поведению. Например, предположим, что для неверсионных статических ресурсов используется стратегия только кэширования или предварительно кэшированная страница «вы не в сети», которая, как ожидается, будет обновляться при перезагрузке после внесения изменений. Поскольку устаревшие версии этих ресурсов всегда обслуживаются из экземпляра Cache , они, похоже, никогда не обновляются! Как бы это ни разочаровывало, сервис-воркер делает только то, для чего он был создан, но есть несколько способов упростить тестирование.

Безусловно, самый эффективный способ протестировать сервис-воркера — использовать окна приватного просмотра , такие как окна инкогнито в Chrome или функцию приватного просмотра в Firefox. Каждый раз, когда вы открываете окно приватного просмотра, вы начинаете все сначала. Нет активных сервис-воркеров и открытых экземпляров Cache . Порядок проведения такого рода испытаний следующий:

1. Откройте окно приватного просмотра.
2. Перейдите на страницу, на которой регистрируется сервисный работник.
3. Убедитесь, что сервисный работник ведет себя так, как вы ожидаете.
4. Закройте окно инкогнито.
5. Повторить.

С помощью этого процесса вы точно имитируете жизненный цикл сервис-воркера.

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

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

1. Offline имитирует автономные условия. Это помогает при проверке того, обслуживает ли активный сервисный работник автономный контент.
2. Обновление при перезагрузке : при переключении повторно извлекает и заменяет текущего работника службы каждый раз, когда страница перезагружается.
3. Обход сети при включении обходит любой код в событии fetch сервис-воркера и всегда извлекает контент из сети.

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

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

Сдвиг и перезагрузка

При локальной разработке с активным сервисным работником без необходимости использования функций обновления при обновлении или обхода сети также полезно удерживать клавишу Shift и нажимать кнопку обновления.

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

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

Проверка содержимого кэша

Трудно сказать, работает ли стратегия кэширования должным образом, если кеш нельзя проверить. Конечно, кеш можно проверить в коде, но это процесс, включающий отладчики и/или операторы console , тогда как визуальный инструмент лучше подходит для этой задачи. Панель приложений в Chrome DevTools предлагает подпанель для проверки содержимого экземпляров Cache .

Эта подпанель упрощает разработку сервисных работников, предлагая такие функции, как:

• Просмотрите имена экземпляров Cache .
• Возможность проверять тело ответа кэшированных ресурсов и связанные с ними заголовки ответов.
• Исключите один или несколько элементов из кеша или даже удалите целые экземпляры Cache .

Этот графический интерфейс пользователя упрощает проверку кэшей Service Worker, чтобы увидеть, были ли элементы добавлены, обновлены или полностью удалены из кэша Service Worker. Firefox предлагает собственную программу просмотра кэша с аналогичной функциональностью , хотя она находится на отдельной панели «Хранилище» .

Имитация квоты хранилища

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

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

На панели «Приложение» в Chrome DevTools есть подпанель «Хранилище» , которая предлагает информацию о том, какая часть текущей квоты хранилища используется страницей. Он также позволяет указать пользовательскую квоту в мегабайтах. Когда это вступит в силу, Chrome будет применять специальную квоту хранилища, чтобы ее можно было протестировать.

Кстати, эта подпанель также содержит кнопку «Очистить данные сайта» и целый набор связанных с ней флажков для того, что должно быть очищено при нажатии кнопки. Среди этих элементов — любые открытые экземпляры Cache , а также возможность отменить регистрацию любых активных сервисных работников, контролирующих страницу.

Упрощение разработки, повышение производительности

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