Ожидания относительно развертывания сервисных работников

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

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

Подводные камни предварительного кэширования

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

Поскольку по умолчанию workbox-webpack-plugin дает указание сервисному работнику автоматически предварительно кэшировать сгенерированные ресурсы, это может быть проблематичным, и его легко пропустить, поскольку барьер для внедрения низок.

Терминальный выход.
Вывод терминала из workbox-webpack-plugin. В этом примере в текущем проекте предварительно кэшируется 14 ресурсов общим объемом 352 килобайта по умолчанию.

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

Все дело во времени

Если сервисный работник что-либо предварительно кэширует, то время регистрации имеет значение. Сервис-воркеры часто регистрируются с использованием встроенных элементов <script> . Это означает, что анализаторы HTML могут обнаружить код регистрации сервисного работника до загрузки критически важных ресурсов страницы.

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

Будьте внимательны к использованию данных

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

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

Запуск сервисного работника может задерживать сетевые запросы

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

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

Эта проблема была решена с помощью Navigation Preload , но она пока поддерживается не во всех браузерах . Тем не менее, его использование заслуживает внимания, и оно рассматривается далее в этой документации .

Стратегии, ориентированные на кэширование, могут иметь неприятные последствия

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

Кэширование неверсионных статических ресурсов во время выполнения

Сборщики обычно создают версии статических ресурсов с хешем на основе содержимого в имени файла (например, styles.a4edf38c.css ). У сервисных работников, которые используют стратегии кэширования, которые сначала обращаются к кешу на предмет статических ресурсов, и используют сетевую стратегию для разметки страниц, не должно быть проблем с кэшированием, поскольку на обновленные ресурсы ссылаются в разметке, которая всегда извлекается из сети.

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

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

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

Квоты хранения разума

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

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

Workbox хорошо справляется с решением этих проблем, но квоты хранилища все равно могут быть превышены. Добиться более точного управления кэшами можно с помощью модуля workbox-expiration .

Не бойтесь

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