Одной из особенностей сервис-воркеров является возможность сохранять файлы в кэше при установке сервис-воркеров. Это называется «предварительным кэшированием». Предварительное кэширование позволяет передавать кэшированные файлы браузеру без подключения к сети. Используйте предварительное кэширование для важных ресурсов, которые нужны вашему сайту даже в автономном режиме: главная страница, стили, резервное изображение и основные скрипты.
Почему вам следует использовать Workbox?
Использование Workbox для предварительного кэширования не является обязательным. Вы можете написать собственный код для предварительного кэширования критически важных ресурсов во время установки сервис-воркера . Основным преимуществом использования Workbox является встроенный контроль версий. У вас возникнет гораздо меньше проблем с обновлением предварительно кэшированных ресурсов с помощью Workbox, чем если бы вам приходилось управлять версиями и обновлением этих файлов самостоятельно.
Предварительное кэширование манифестов
Предварительное кэширование управляется списком URL-адресов и соответствующей информацией о версиях для каждого URL-адреса. В совокупности эта информация известна как манифест прекэша . Манифест — это «источник истины» о состоянии всего, что должно находиться в предварительном кэше для данной версии веб-приложения. Манифест предварительного кэширования в формате, используемом Workbox , выглядит примерно так:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Когда сервис-воркер установлен, в хранилище кэша создаются три записи кэша для каждого из трех перечисленных URL-адресов. Информация о версии первого актива уже включена в его URL-адрес ( app — это фактическое имя файла, а .abcd1234 содержит информацию о версии непосредственно перед расширением файла .js ). Инструменты сборки Workbox могут обнаружить это и исключить поле редакции. Два других ресурса не содержат никакой информации о версии в своих URL-адресах, поэтому инструменты сборки Workbox создают отдельное поле revision , содержащее хэш содержимого локального файла.
Обслуживание предварительно кэшированных ресурсов
Добавление ресурсов в кеш — это лишь одна часть процесса предварительного кэширования: как только ресурсы кэшируются, им необходимо отвечать на исходящие запросы. Для этого в вашем сервис-воркере требуется прослушиватель событий fetch , который может проверять, какие URL-адреса были предварительно кэшированы, и надежно возвращать эти кэшированные ответы, минуя при этом сеть. Поскольку сервис-воркер проверяет кэш на наличие ответов (и использует их до сети), это называется стратегией кэширования .
Эффективные обновления
Манифест предварительного кэширования обеспечивает точное представление ожидаемого состояния кэша; Если комбинация URL-адреса и версии в манифесте изменится, работник службы узнает , что предыдущая запись в кэше больше не действительна и ее необходимо обновить. Чтобы определить, какие предварительно кэшированные URL-адреса необходимо обновить, требуется всего один сетевой запрос, автоматически сделанный браузером в рамках проверки обновлений сервис-воркера.
Обновления предварительно кэшированных ресурсов
По мере того, как вы со временем выпускаете новые версии своего веб-приложения, вам необходимо поддерживать ранее предварительно кэшированные URL-адреса в актуальном состоянии, предварительно кэшировать новые ресурсы и удалять устаревшие записи. Пока вы продолжаете генерировать полный манифест предварительного кэширования каждый раз, когда перестраиваете свой сайт, этот манифест служит «источником истины» для вашего состояния предварительного кэширования в любой момент времени.
Если существует существующий URL-адрес с новым полем редакции или какие-либо URL-адреса были добавлены или удалены из манифеста, это знак для вашего сервисного работника, что необходимо выполнить обновления в рамках install и activate обработчиков событий. Например, если вы внесли некоторые изменения в свой сайт и перестроили его, ваш последний манифест предварительного кэширования мог претерпеть следующие изменения:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Каждое из этих изменений сообщает вашему сервисному работнику, что необходимо сделать новые запросы для обновления ранее кэшированных записей ( 'offline.svg' и 'index.html' ) и кэширования новых URL-адресов ( 'app.ffaa4455.js' ), а также удаления для очистки URL-адресов, которые больше не используются ( 'app.abcd1234.js' ).
Настоящий опыт установки из магазина приложений
Еще одним преимуществом предварительного кэширования является то, что вы можете предоставить своим пользователям такие возможности, которых в противном случае было бы трудно достичь за пределами установки «магазина приложений». Как только пользователь впервые посещает любую страницу вашего веб-приложения, вы потенциально можете заранее предварительно кэшировать все URL-адреса, необходимые для отображения любого из представлений вашего веб-приложения, не дожидаясь, пока он посетит каждое отдельное представление.
Когда пользователь устанавливает приложение, он ожидает, что каждая его часть будет быстро отображаться, а не только те представления, которые он посещал раньше. Предварительное кэширование приносит тот же опыт и в веб-приложения.
Какие из ваших ресурсов следует предварительно кэшировать?
Вернитесь к руководству «Определите, что загружается» , чтобы получить четкое представление о том, какие URL-адреса имеет смысл предварительно кэшировать. Общее правило заключается в предварительном кэшировании любого HTML, JavaScript или CSS, которые загружаются на ранней стадии и имеют решающее значение для отображения базовой структуры данной страницы.
Предпочтительно избегать предварительного кэширования мультимедиа или других ресурсов, которые загружаются позже (если это не важно для функциональности вашего веб-приложения). Вместо этого используйте стратегию кэширования во время выполнения, чтобы обеспечить постоянное кэширование этих ресурсов.
Всегда помните, что предварительное кэширование предполагает использование пропускной способности сети и хранилища на устройстве пользователя (точно так же, как при установке приложения из магазина приложений). Вы, как разработчик, должны разумно осуществлять предварительное кэширование и избегать раздутого манифеста предварительного кэширования.
Инструменты сборки Workbox помогают сообщать вам количество элементов в манифесте предварительного кэширования, а также общий размер полезных данных предварительного кэширования.
Повторные посетители вашего веб-приложения в долгосрочной перспективе получают выгоду от первоначальных затрат на предварительное кэширование, поскольку возможность, которую оно предлагает, чтобы избежать сети, быстро окупается за счет экономии полосы пропускания с течением времени.