Гарантирует ли активация sw-preache нового сервис-воркера очистку кеша?

Я использую sw-precache вместе с sw-toolbox, чтобы разрешить автономный просмотр кэшированных страниц приложения Angular.

Приложение обслуживается через экспресс-сервер node.

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

В результате у пользователей остается устаревший index.html, который пытается загрузить уже не существующий ресурс с версией в данном случае /scripts/a387fbeb.modules.js.

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

В одном браузере устаревший (проблемный) Index.html

(кешируется с хешем 2cdd5371d1201f857054a716570c1564) включает:

<script src="scripts/a387fbeb.modules.js"></script>

по своему содержанию. (этого файла больше нет в кеше или на удаленном компьютере).

В другом браузере обновил (хорошо) index.html

(кэшируется с тем же 2cdd5371d1201f857054a716570c1564) включает:

<script src="scripts/cec2b711.modules.js"></script>

У этих двух одинаковый кеш, хотя контент, возвращаемый браузерам, отличается!

Что мне делать с этим? Означает ли это, что sw-precache не гарантирует сброс атомарного кеша при активации нового ПО? Как от этого защититься?

Если это помогает, то это сгенерированный файл service-worker.js из sw-precache.

Примечание. Я понимаю, что могу использовать remoteFirst стратегию (по крайней мере, index.html), чтобы избежать этого. Но я все же хотел бы понять и выяснить, как использовать cacheFirst стратегию, чтобы получить максимальную отдачу от производительности.

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

Примечание 3: обратите внимание, что даже если я сильно перезагружу браузер, где веб-сайт не работает. Сайт будет работать, потому что он пропустит кеш сервис-воркера, но кеш все равно будет неправильным - сервис-воркер, похоже, не активируется - я предполагаю, потому что этот конкретный SW был уже активирован, но не смог правильно очистить кеш. При последующих посещениях без жесткого обновления по-прежнему будет отображаться неработающий index.html.


javascript service-worker offline-caching sw-precache sw-toolbox
person mkhatib    schedule 24.02.2016    source источник
comment
Я столкнулся с той же проблемой. Вы нашли способ решить эту проблему без использования remoteFirst?   -  person Gustavo Preciado    schedule 27.06.2017

Ответы (1)


arrow_upward
2
arrow_downward

(Здесь ответы относятся к sw-precache библиотеке. Эти сведения не относятся к работникам службы поддержки в общие, но концепции обслуживания кеша могут по-прежнему применяться к более широкой аудитории.)

Если содержимое index.html динамически генерируется сервером и зависит от других ресурсов, которые либо встроены, либо указаны через теги <script> или <link>, тогда вам необходимо указать эти зависимости с помощью параметра dynamicUrlToDependencies. Вот пример из app-shell-demo < / a>, который входит в состав библиотеки:

dynamicUrlToDependencies: {
  '/shell': [
    ...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`),
    ...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`),
    `${SRC_DIR}/views/index.handlebars`
  ]
}

(/shell используется там вместо /index.html, поскольку этот URL-адрес используется для доступа к кэшированной оболочке приложения.)

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

Если ваш index.html не генерируется сервером динамически, а вместо этого обновляется во время сборки, используя что-то вроде этот подход, то важно убедиться, что шаг в процессе сборки, который запускает sw-precache, происходит после того, как были произведены все другие модификации и замены. Это означает использование чего-то вроде run-sequence, чтобы гарантировать, что генерация сервис-воркера не выполняется параллельно. с другими задачами.

Если приведенная выше информация вам не помогает, смело отправьте сообщение об ошибке с более подробной информацией. , включая URL-адрес вашего сайта.

person Jeff Posnick    schedule 24.02.2016
comment
Не думаю, что это ответ на мой вопрос. Index.html создается в процессе сборки, и, как вы предполагаете, это последняя задача, которую я выполняю - после того, как доработка уже произошла (задачи Grunt). Во всяком случае, я подумал, что попрошу посмотреть, не происходит ли что-то очевидное, чтобы попытаться решить эту проблему. Я перехожу к gulp -flow и посмотрю, увидят ли люди после развертывания нового сервис-воркера ту же проблему или нет. Если это все еще произойдет, я могу просто вернуться к подходу remoteFirst - хотя это может нарушить автономную поддержку до тех пор, пока не будет развернут новый сервис-воркер. - person mkhatib; 25.02.2016
comment
Если вы уже делаете правильные вещи с точки зрения времени выполнения sw-precache, то я не думаю, что наблюдаемое вами поведение является ожидаемым. Обновления кеша должны выполняться по принципу «все или ничего», и вы не должны попадать в несогласованное состояние. Не могли бы вы сообщить об ошибке на странице github.com/GoogleChrome/sw-precache/issues и мы там будем исследовать? - person Jeff Posnick; 25.02.2016